Sowohl System.IO.Compression.* als auch dein Link basieren auf dem Deflate-Algorithmus.
Da würde mir spontan zlib als "Referenzimplemtierung" einfallen.
Du hast vermutlich auch den Device-Treiber in Verwendung. Ob das Auslesen aller VIDs&PIDs mit dem Device-Treiber funktioniert kann ich nicht sagen, bezweifle es aber.
Nur setzt der Device-Treiber eben ein eigenes USB-Device voraus, um installiert werden zu können. Da buzz_lightzyear nichts von einem eigenen Device schreibt, gehe ich davon aus, dass buzz_lightzyear den Filter-Treiber verwenden muss.
ist zwar nicht über WMI, jedoch ein einfacher Weg, der leicht implementierbar ist: SharpUsbLib
Meines Wissens nach brauchst die SharpUSBLib zum AUslesen aller VIDs&PIDs einen installierten libusb Filter-Treiber. Von dessen produktiven Einsatz rät die libusb Seite ab.
Für welche Geräteklasse willst du die VID & PID auslesen?
USBView z.B., sendet eigene Control-Transfers, über den Host-Controller-Treiber an die angeschlossenen USB-Devices, um an die Deskriptoren zu kommen. Die Sourcen findest du im aktuellen WDK.
Du könntest auch versuchen statt raw Ethernet Paketen UDP Pakete zu verschicken und somit auf WinPcap verzichten. Dafür ist der TCP/IP Stack ausgelegt und ich könnte mir gut vorstellen, dass sich der Datendurchsatz erhöht.
IP & UDP kannst du ja relativ statisch in deinem Ethernet Frame unterbringen, dies sollte auch mit einem FPGA noch relativ einfach realisierbar sein.
Ohne einen Puffer auf der FPGA Seite - und BRAM wird hier nicht reichen - wirst du immer wieder Pakete verlieren, sei es durch Übertragungsfehler oder weil WinPCap die Daten nicht schnell genug speichern kann.
Hast du auf der FPGA-Seite einen Puffer für die Daten?
Ich habe bisher zwar noch nie Ethernet für soetwas verwendet, jedoch habe ich bei anderen Bussystemen, wie USB und PCIe immer einen Puffer von ~100ms gebraucht um keine Daten zu verlieren.
Falls dass nicht hilft, kannst du ja mit einer anderen Anwendung Daten erzeugen und rausfinden, ob die Netzwerkkarte, WinPCap oder deine Anwendung der Flaschenhals ist.
Warum tut ihr euch den Aufwand mit Ethernet überhaupt an? bei ~240MBit/s reicht doch auch USB.
Die Namen sowie weitere Eigenschaften kannst du mit Hilfe der SetupAPI rausfinden. Ich würde dir aber trotzdem raten, die ganzen USB<->Seriel Wandler nicht mehr zu verwenden, sondern einen eigen µC mit USB. Dies bedeutet zwar am Anfang Mehraufwand, zahlt sich aber bald aus.
Doch es sind Binärdateien. Huffman, Deflate arbeiten mit Binärdateien und nicht mit Strings.
Ich würde hier weder SortedList, noch Dictionary verwenden, sondern ein simples Array mit 256 Elementen. Für jedes Byte ein Element.
Die Datei komplett einzulesen funktioniert nur bei kleinen Dateien, bei größeren Dateien bekommst du ein Problem.
Verwende einen FileStream und ließ die Daten Blockweise, mit einer Blockgröße von z.B.: 64KB, ein. Dann läufst du mit einer for-Schleife über den Block und berechnest die Häufigkeiten.
Evtl. ist ein bool-Array der Größe 10.000.001, bei der der Wert als Index verwendet wird und der bool Wert angibt, ob der Wert in der Liste enthalten ist, noch ein bisschen schneller.
Für so etwas würde ich her die BitArray-Klasse verwenden.
Bei mir hat Eclipse in einer Endlosschleife immer weiter verschachtelte Ordner angelegt. Wenn ich versucht habe das über den Explorer zu löschen kam eine ähnliche Fehlermeldung.
Seit Vista oder W7 unterstützt auch der Windows Explorer lange Dateipfade. Spät aber doch...
Das geht schon, nur unterstützt es das .Net Framework nicht. Du musst "\\?\" an den Pfad voranstellen, dann kann der Pfad bis zu 32K Unicode Zeichen enthalten.
Es gibt aber sicherlich bereits .Net Komponenten die mit langen Dateipfaden arbeiten können. =>google
Gibt es keine bereits verfügbaren Simulatoren für eure CPU? Je nach Komplexität der Plattform und euren Anforderungen(z.B. Cycle genau) kann so ein Simulator sehr aufwendig werden.
Auch ich würde hier eher nicht C# verwenden, sondern SystemC verwenden.
sicher könnte man den Installationspfad "von Hand" in die Registry schreiben, aber ich denke gerade für den Installationspfad sollte es bei den normalen Setup-Generatoren eine automatische/standardmäßige Unterstützung geben...
Es gibt das ARPINSTALLLOCATION Property um den Pfad zu speichern und automatisch zu setzen. Allerdings wird dieses zumindest von VS2005 nicht verwendet. Abgesehen davon, hat dieses Property bei einigen älteren Windwos Installer Versionen bei mir nicht zuverlässig funktioniert.
Zitat
Hab jetzt so ziemlich alle möglichkeiten aus der Command-Line MSDN ausprobiert ...
1) Während der Installation den Installationspfad in die Registry zu schreiben und bei einem Update von dort wieder auszulesen ist die einfachste Möglichkeit.
Grundsätzlich kannst du eine Scriptsprache deiner Wahl (Ruby bzw. Phyton sind gerade in) nehmen und diese durch eigene Module (Scriptcode sowie externe DLLs) erweitern. Dies hat den Vorteil, dass du bereits bestehende Entwicklungsumgebungen für die Scriptsprache nutzen kannst. Der Nachteil dieser Lösung ist, wenn du mehr als nur Skripte ausführen willst. Z.B. Spezielles User-Interface, etc.
Die andere Möglichkeit wäre die Scriptsprache in dein Programm zu integrieren. Hier würde sich z.B. die DLR mit IronRuby/IronPhyton anbieten. Dadurch bist du flexibler was die GUI und die weitere Funktionalität deines Programmes betrifft, musst allerdings Dinge wie IntelliSense, Debugger u. ä. selber entwickeln.
Ich setzte IronPhyton und IronRuby bereits in einigen meiner Projekte ein. Die Integration und Erweiterung durch eigenen Methoden bzw. Klassen geht sehr leicht. Dafür fehlt es der DLR noch an einigen Features wie Debugging, Abbrechen von Skripten und Fehlerbehandlung.