Wenn das CF aussterben soll, warum bring MS weiterhin laufend CE / Compact Versionen an den Markt?
Weil MS nur das Betriebssystem liefert, das Gerät aber von einem anderen Anbieter ist. Der hat das Gerät irgend wann für CE entwickelt und kann nicht den Entwicklungszyklus von ca. 2 Jahren einen komplette neue Version auf den Markt bringen. Mit W10 soll ja mal wieder alles anders und besser werden - glaube nicht daran. $BELIEBIGEFIRMA verdient nur wenn der alte Kram bewusst nicht mehr unterstützt wird.
Zitat von trib
Bei Windows Embedded Compact 7 kann ich VS2008 auch nicht mehr richtig verwenden. (Auf Gerät kompillieren oder Debuggen ist nicht mehr möglich)
Mit der Trial-Version kann ich wunderbar arbeiten. Gut, er kompiliert nicht auf dem Gerät (nur lokal) aber dafür kann ich super remote debuggen, was mit SharpDevelop nicht funktioniert (oder ich habe es noch nicht gefunden)
ich suche genau das was im Titel angegeben wurde. Problem ist das ich Software für Win 7 Compact, also .NET 3.5 Compact schreiben muss. Ab 2010 hat ja MS das ja rausgeschmissen. Für das kleine Projekt würde ich ungern noch 1000€ für eine neue Lizenz ausgeben wollen.
Wenn Du einen Broadcast absetzt nimmt .NET irgend eine Netzwerkschnittstelle. Wenn Du (wie im Normalfall) nur eine Netzwerkkarte drinnen hast, das passt das auch. Wenn Du aber mind. 2 Netzwerkkarten drinnen (DVB-Karte/VPN/...) wird der Boradcast zwar über alle Netzwerkschnittstelle geschickt - aber mit dem falschen Absender. Unter 1.1 hat er bei mir immer die IP von der DVB Karte genommen.
@OP
Liste der Netzwerkkarten abrufen
auf jeder Netzwerkkarte einen Socket einrichten
Broadcast über jeden Socket absetzen
hand, mogel
btw: 255.255.255.255 funktioniert nur wenn es im Gateway frei geschaltet ist
Um dies zu "lösen" müsste also jede Nachricht sofort in die Datei geschrieben werden. Das ging bisher jedoch nur auf Kosten der Performance. 100.000 Einträge dauerten somit ca. 15 Sekunden.
Da Du keinen Quelltext postest, vermute ich mal:
log() - Aufruf
Log-Datei öffnen
Seek an das Ende
Meldung schreiben
Datei schließen
Das kostet richtig Ressourcen. Richtig wäre: Log-Datei am Programm Anfang öffnen, und nach jeder Meldung gleich flushen, Log-Datei nie schließen. Läuft bei mir nach diesem Prinzip seit Jahren.
ich vermute Gaus & Co. hast Du weg gelassen, da die Bilder schon perfekt sind
Zitat von gfoidl
Bei N logischen Kernen* können wirklich gleichzeitig auch nur N Threads ausgeführt werden.
bei X Threads die immer rechnen würde ich eher auf X ≤ N - 1 gehen, um dem BS und anderen Programmen auch etwas Platz zu gönnen
Zitat von gfoidl
Zitat
Ist es möglich mit einem Thread einen bestimmten CPU Kern anzusteuern?
[...]Dabei pfuschst du aber dem Scheduler vom Betriebssystem ins Handwerk und es ergibt sich oft ein eher nachteiliges Ergebnis.
bei der Aufgabe würde ich eher sagen macht es beim Prozessor Sinn. Das Ganze ist eine Mischung aus "wie arbeitet mein Programm" und "wie groß sind L1/L2/L3". Wenn der Cache nicht groß ist um 2 Bilder gleichzeitig vorzuhalten, dann ist es eher Sinnlos den Kern fest zunageln. Da sonst eh der Cache aus dem RAM jedesmal neu gefüllt wird, es also keine Geschwindigkeitsvorteile bringt.
Zitat von Abt
Somit dürfte ein GetPixel - sofern Du das nutzt - nicht Thread-Safe sein.
so lange er nur liest ist das egal - aber - GetPixel ist schrecklich langsam (genau wie SetPixel). Das gesamte Bild muss in Rohdaten vorliegen um halbwegs in Zeit die Bilder verarbeiten zu können. Aber da er ja den Screenshot abgreift, hat OP ja schon ide Rohdaten (außer er hat in der Tat ein BMP draus gemacht).
hand, mogel
Zitat von gfoidl
im Computer sind physische Kerne verbaut, diese können aber durch Techniken wie Hyperthreading als doppelt soviele logische Kerne verfügbar gemacht werden.
setzte den entsprechenden Handler um das Event abzufangen
fülle im Event einen temporären Puffer mit dem Byte
wenn das entsprechende Paket voll ist, dann erzeuge ein eigenes Event und kopierst dabei die Werte aus dem temporären Puffer
Dann siehst Du zumindest schon mal ob überhaupt was zurück kommt. Wenn Du Dich auf des NewLine verlässt, siehst Du erst was wenn das NewLine gesendet wurde (wenn es überhaupt gesendet wird).
Wieso teilst Du dem Gerät mit das Du von ihm nichts empfangen willst, sendest dann was und sagst dem Gerät jetzt will ich was von Dir empfangen? Das ist eine eigenwillige Herangehensweise. Die beiden Steuerbefehle brauchst Du nur senden wenn Dein Puffer voll läuft. Ich glaube aber nicht das Du irgend wann auf der PC-Seite Probleme mit einem voll laufenden Puffer hast :) Das Problemkind ist eher die andere Seite - und der sagt Dir dann mittels Xon/Xoff ob er noch was von Dir empfangen will.
Ich weis jetzt nicht wie die SerialPort-Implementierung an der Stelle genau aussieht. Ob der SerialPort diese ankommenden Befehle entsprechend selber verarbeitet und Du Dich um nichts kümmern musst. Oder ob die Bytes durch gereicht werden. In letzterem Fall siehst Du bei der Verwendung von "NewLine" aber erstmal nichts. Bis der Xoff Befehl bei Dir angekommen ist, kann es sein das die Gegenseite zu gemacht hat, weil der Empfangspuffer voll ist.
Hänge parallel einen weiteren Rechner an die Datenleitungen und liest die reinen Daten aus. Also Baud & Co müssen passen, aber kein Handshake (weder Soft- noch Hardware!). Anzeigen lassen kannst Du Dir die Daten z.B. mit Term95. Allerdings musst Du aufpassen, Du kannst nur die Daten in einer Richtung sehen. Wenn Du die andere Richtung sehen willst, dann musst Du am parallelen Rechner Rx unt Tx tauschen (oder nimm einen weiteren Rechner/COM-Port ^^).
Was für eine Klasse BestThread ist, wissen wir nicht. Vermutlich enthält sie die Verarbeitungslogik. Es wird also wohl nicht ein Thread aus einem Thread heraus gestartet, sondern die Verarbeitungslogik aus einem Thread heraus. Das ist das gewünschte. Über den Klassennamen kann man natürlich streiten.
es hat etwas gedauert, aber Du könntest recht haben. Der Klassenname und der Methodenname lies mich in der Tat annehmen hier wird von Thread geerbt. Sollte das der Fall sein, werden 2 Threads gestartet. Ansonsten nur einer.
Zitat
Bei mir würden die Alarmglocken schrillen, wenn jemand schreiben würde, dass er seine Threads nicht synchronisiert. Synchronisieren bedeutet ja in diesem Kontext nicht "hintereinander ausführen", sondern "thread-safe machen".
doch - "thread-safe" kann aber dummerweise auch zu einem "hintereinander ausführen" führen. ThreadA hat BM, ThreadB wartet. ThreadA gibt BM frei, ThreadB fängt an und lockt BM, ThreadA wartet sofort wieder auf BM. Genau deshalb die "Alarmglocken". Genau deshalb erstmal prüfen ob sich das Problem überhaupt parallelisieren lässt.
Application.DoEvents ist eine Behelfskrücke für Leute die sich nicht mit Threads auseinander setzen wollen. Nutze doch bitte Thread::Join() wenn Du auf das Ende der Threads warten willst.
Du startest einen Thread um einen Thread zu starten. Wozu??
Dann Schreibst du irgendwo das Du deine Thread synchronisierst. Da schrillen doch die Alarmglocken. Wenn du die Threads untereinander synchronisierst ist jeder Thread sinnlos. Prüfe doch bitte ob sich Dein Problem überhaupt parallelisieren lässt. Um wenn ja wie. Wenn es sich nicht parallelisieren lässt, dann kannst du noch so viele Kerne und Threads Haben, es wird aber nicht schneller.
Der Keep-Alive Timeout ist afaik auf einen sinnlos hohen Wert gesetzt. Musst mal in den Tiefen der RFC suchen.
Wenn garantiert ist das du immer im Sekundentakt etwas bekommst, dann reicht es wenn du nach drei Sekunden nichts die Verbindung für gescheitert erklärst. Ich mach das im Moment mit meiner RS485 Verbindung genau so.
Alternativ selber Ping-Pong spielen und den Keep-Alive simulieren.
Ein kleines Ferngesteuertes Auto mit einer CAM soll anhand des Video gesteuert werden können
Da Du an der Stelle eigentlich kein Zeitversatz gebrauchen kannst (Buffering), wird Dir nichts anderes übrig bleiben die Paket selber über UDP zu verschicken. Dabei musst Du dann jedoch damit leben das Paket (somit Teile des Bildes verloren gehen). Wenn Du die Größe der UDP-Pakete kleiner als MTU-Größe wählst ist das nicht tragisch.
Das Problem ist, dass die Clientseite so schnell schickt, dass der Reveiver Thread, obwohl er nur die receiveMethode ausführt nicht hinter her kommt und dadurch packete verloeren gehen.
Ich weiß das es an der Performance dieses Threads liegt, da ich schon auf der Clientseite mit einem sleep(...), dass ganze etwas gedrosselt habe und siehe da, alles kommt an wie es ankommen sollte.
Wer sagt das der Server zu langsam ist? Evt. könnte es auch an Deinem lokalen Netzwerk liegen. UDP Pakete werden verworfen weil etwas bei der Übertragung nicht stimmt bzw. etwas schief gelaufen ist. Das kann bei einem ausgelastetem Netzwerk auch eine simple Kollision auf der Leitung sein. Wenn Du die sende-Frequenz drosselst, dann reduzierst Du automatisch die Kollisionen. Kann auch sein das Dein WLAN-Router selber nicht die Datenmenge verarbeiten kann. (1)
Zitat
Gibt es vielleicht eine Möglichkeit den UDP-Thread auf ein Kern legen und die restlichen Threads auf den anderen. Habe aber dafür noch keine praktische Lösung gefunden.
Mit Thread-Prioritäten und Kernen rumzuspielen macht nur an zwei Stellen Sinn. Dein Problem gehört weder zum Thema Gameserver oder Bild/Daten-Verarbeitung.
Zitat
Wie machen es die Könner :) bei ihren Video-oder Audiostreamings?
Lösungen wurden schon genannt
-> Leben das Pakete verloren gehen
-> RTP Streaming verwenden und Bilder Zeitversetzt sehen
-> TCP verwenden (ist aber vom Hauptproblem abhängig)
Da du nicht genau schreibst was Du am Client mit den Bildern genau machen willst, gibt es auch keine besseren Lösungsvorschläge.
hand, mogel
(1) nur weil ein Protokoll behauptet das man damit 300MBit/Sekunde übertragen kann, muss das noch lange nicht vom Gerät unterstützt werden. Aktuelles Beispiel: RS485 kann lt. Spezifikation 12MBit - mein Gerät schafft aber nur 115kBit. Mehr ist technisch nicht machbar. Ergo -> auch ein WLAN-Router schafft nicht immer alles.
evt. wäre ein FileSystemWatcher der auf Änderung der Datei überwacht besser, als alle 100ms zu pollen ob sich die Datei geändert hat. Wenn es unbedingt Pollen sein muss dann ist ggf. 1000ms besser, da in der Zeit eh kaum ein Mensch was lesen kann.
Hat sich nun selbst geklärt... War meine eigene Dummheit, der Code soweit war aber korrekt.
Wäre schön wenn Du andere Suchende (die das gleiche Problem haben) an Deinem Erfolg teilhaben lassen könntest. Aber ich vermute Du hast java.exe durch javaw.exe erstezt.
Ansonsten kann man evt. eine Buildumgebung wie NAnt verwenden. Zur Not macht es auch eine Batch-Datei. Da kann man dann selber die Abhängigkeiten - auch von Dritten - explizit angeben.
versuch mal ein ContexMenü. Das Menü nimmt ToolStripItems entgegen. ToolStripItem erbt (direkt) von Component. Label, ProgressBar und PictureBox erben von Control, welches wiederum von Component erbt. Somit sollte das ContextMenü die entsprechenden Element selber enthalten können.
Quasi ein Control mit ein paar Label, ein Bild und einem ProgressBar (für die Kapazität). Und das Control dann dem ContextMenü hinzufügen.
Was ich gefunden habe, waren sog. Telnet-Befehle: GA (Go Ahead), etc.
was aber seltsame Effekte ausgelöst hat, weil ich da noch nicht ganz durchsteige.
Das heißt im Klartext: Ich möchte auf Knopfdruck einmal alle Geräte im WiFi-Netzwerk suchen,
Da gibt es keine gescheite Lösung, weil Du theoretisch für jeden herstelle entsprechend was programmieren müsstest. Das einzige was halbwegs zuverlässig funktioniert (abgesehen von Firewall) ist ein Ping. Also alle IP im Netzwerk testen..............
Zitat
und über einen Socket einen Ping ins gesamte Netzwerk zu broadcasten, ähnlich, wie es mit dem Magic Packet geschieht, hat sich ebenfalls als nicht umsetzbar erwiesen.
ja - weil das in jedem Netzwerk deaktiviert ist (Smurf-Attacke)
Ich habe ein externes Projekt E. Dies stellt mir eine DLL mit verschiedenen Interfaces bereite (E-I) und eine DLL mit diversen Funktionen (E-F). Dann gibt es zu diesem Projekt Plugins (E-P1, E-P2, ... [E-Px]). Diese benötigen nur E-I.
Dann habe ich mein Hauptprojekt H, welches E-I und E-F benötigt. Die Plugins selber liegen in einem Unterverzeichnis von H. E-F reicht mir die Plugins E-Px die ich benötige durch und kümmert sich um die Instanzierung etc.
Problem
Das Problem ist das nach dem Build die Plugins E-Px in das entsprechende Unterverzeichnis von H kopiert werden müssen. Da aber nicht sichergestellt ist das E-Px vor H compiliert werden, kann ich in H das Post-Build-Event nicht verwenden. Sicher ist nur das E-I, dann E-F als Erstes (und Zweites) compiliert werden. Da H die Plugins E-Px auf Grund der Architektur gar nicht kennen darf, wird beim Build auch nichts kopiert.
Unter MonoDevelop kann ich im entsprechenden Pre-Run-Event ein Bash-Script starten das mir die DLL in das entsprechende Unterverzeichnis vor dem Programm start kopiert. Eben jenes Event fehlt mir für C# (oder ich finde es nicht). C++ hat noch einen "benutzerdefinierten Buildschritt", welcher eben genau das ist was ich für C# benötige.
Von einer 32Bit-Anwendung auf den 64Bit-Teil zuzugreifen ist in meinen Augen zwar nicht die feine englische Art, [...]
der Sinn, wieso MS in der Registry zwischen 32 Bit und 64 Bit trennt, erschließt sich mir nicht ganz. Ich habe die Registry bisher als Datenbank des System betratchtet wo alle relevanten Informationen drinnen sind. Und Informationen sind nicht an die "Bit-Breite" des OS gekoppelt - zumidnest in meinem wirren Kopf.
Ich vermute mal, dass das ein Problem mit 64bit-Systemen ist:
Ich denke, dass der Registrypfad
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion
ist und nicht
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
das vermute ich auch. Wenn ich da mit regedit rein schaue, dann fehlen da ein paar Werte - inkl. DigitalProductId.
Zitat
Was du aber gegen diese Änderung tun kannst, weiß ich nicht?
Ich mache erstmal Ketchup auf die Tischplatte und beiße da rein.
Zitat von Abt
Warum willst Du das direkt über die Registry machen?
Weil google bei "c# windows key" nur Registry-Tricks ausspuckte.
Zitat
Je nachdem welche Werte Du genau willst kannst Du das ganze auch über WMI oder direkt über C# machen, sodass Du hier etwas unabhängiger bist.
Dann bin ich ganz Ohr - ich brauche einfach nur den Windows-Key der Installation.
ich versuche gerade meinen Windows-Key auszulesen. Mit Google wird man auch schnell fündig. Allerdings funktionierte das Snippet nicht bei mir. Weil genau der Value "DigitalProductId" nicht gefunden wird:
RegistryKey rKey = Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\Windows NT\CurrentVersion");
foreach (String name in rKey.GetValueNames()) Logging.info("-> RKN: " + name);
byte[] rpk = (byte[])rKey.GetValue("DigitalProductId4", new byte[] { 0xde, 0xad, 0xbe, 0xff });
rpk enthält am Ende eben das Steak statt den Windows-Key. Mit etwas Googeln lässt sich auch eine Lösung finden, statt "x86" muss das Ding bei mir auf "AnyCPU" oder "x64" stehen. Und schon lässt sich der Key auslesen. Das Problem ist aber das ich "x86" benötige, da ich auf eine DLL zugreifen muss die nur in 32 Bit vorliegt.
Nun interessiert mich wieso ich von "x86" nicht auf alle Werte in der Registry zugreifen kann?!
hand, mogel
BTW: auch mit Adminrechten und x86 ist dies nicht möglich. Zumal das auch nicht sinnvoll ist, da es ein Benutzerprogramm ist und Adminrechte nicht benötigt werden.
Es gibt ca 5000 Tiles die geladen werden. Auf der Platte sind das im Gesamten ca 2,5 MB. Und sie werden zwei mal geladen. Das kommt mir etwas viel vor.
sind die Tiles komprimiert oder als RAW-Datei auf der Festplatte? ... und wieso werden die Tiles 2 mal geladen - reicht einmal nicht aus?
Zitat
Gibt es denn keine möglichkeit den Stream von dem Imgae abzutrennen? (Oder auf anderem Weg Bilder ohne Stream zu verarbeiten)
ja - in dem Du das Bild auf Bild zeichnest und das Bild zerstörst (entwirren darfst Du) ... dann kannst Du den Stream zerstören ... alternativ kannst Du die Bild daten auch in einen MemoryStream stecken und von da das Bild erzeugen