Seiten: [1] 2 3 
|
 |
|
Autor
|
Thema: CPU Auslastungs-Anzeige über USB (Gelesen 48571 mal)
|
hackspider
Wakü-Poseidon
Karma: +4/-0
 Offline
Geschlecht: 
Beiträge: 412
|
Hi,
da ich hier vermehrt den Wunsch gelesen habe, dass einige die CPU Auslastungsanzeige via USB unter Vista betreiben möchten und ich mich sowieso im Moment mit USB Programmierung auf AVRs auseinander setzte habe ich mir gedacht ich mache den Vista Benutzer eine Freude.
USB CPU Load Indicator WinXP x86/x64 und Vista x86/x64 Ready
Die Schaltung basiert auf einem Atmega48 von Atmel, der die USB mittels V-USB (früher AVR-USB) implementiert wurde (so wie das USB-LCD von Ast). Die Schaltung ist benötigt USB-Seitig nicht viel: vier Widerstände, 2 Z-Dioden und eine USB-Buchse. Dazu kommt noch die "Grundversorgung" für jeden AVR mit einem Quarz, Anschwingkondensatoren und Reset Pull-Up. Im Moment werden die LEDs direkt an den Ports des AVRs betrieben, das ist nicht gesund für den Mikrocontroller. Mann kann dazu den 74HC373 verwenden wie im Klassischen Tutorial oder wenns etwas stärker sein darf auch einen uln2801.
Mikrocontrollerseitig ist die Software so simple wie möglich gehalten worden. Außer USB-Messages empfangen und das Value-Word des USB-Requestes auf die Ports mappen, macht der AVR nichts weiter (alles kein Hexenwerk).
Das Programm PC seitig wurde in C# geschrieben (Hauptsächlich weil ich das letzte halbe Jahr C# programmieren musste). Das macht das Programm nicht unbedingt Resourcensparend (ca 10 - 15MB RAM ) dafür funktioniert alles so wie es soll. Ich kann das Programm ggf. nochmal in C++ neu schreiben. Es wird auch hier lediglich die CPU Load der Kerne ausgelesen via USB an den Mikrocontroller geschickt.
So und weil Text alleine langweilig ist hier mal ein Bild im Betrieb:
Rechts sind die LEDs für den Kern0 meinen QuadCores und Links sind die LEDs für Kern1.
Für mehr als zwei Kerne reichen die IO-Pins des Mikrocontrollers nicht aus, allerdings würde ich auf Wunsch eine Quad-Variante mittels Schieberegister (74HC595) anbieten.
Soo und jetzt zum interesannten Teil: Der Treiber für die Betriebssysteme.
Der Mikrocontroller braucht auf dem PC die LibUSB, die es sowhol für Linux als auch Windows gibt. Unter WinXP (egal ob x86 oder x64) ist es relativ einfach, man nimmt den LibUSB Win32 Installer installiert den Treiber und tut.
Durch Recherche als ich mich mit V-USB beschäftigte, bin ich auf ein Youtube Video gestossen, indem erklärt wird wie man die LibUSB unter Vista zum laufen bringt:
Als erstest wird das mitgelieferte *.sys file mit dem "Add Hardware" Dialog installiert, die Geräte erscheinen jetzt mit einem Ausrufezeichen im Geräte-Manager, da die Treiber nicht signiert sind. Als nächstes installiert man wie unter WinXP LibUSB Win32, allerdings im WindowsXP SP2 Kompatibilitätsmodus. Das Gerät funktioniert nur dann wenn das tolle "Sicherheitsfeature" "Erzwungene Treibersignierung" abgeschaltet wird. Das "Feature" wird abgeschaltet, indem man während des Bootvorgangs F8 drückt und auswählt, dass man ohne "Treibersignierung" starten will. Wem das jedes mal zu stressig ist, kann auf Tools wie ReadyDriver zurückgreifen, die das dann automatisch machen.
Getestet wurde das ganze unter WinXP x64 und Vista x64.
Hier noch ein Video (für Leute die es Bilnken Seh wollen  )
Video
und noch ein Paar Links:
V-USB
YouTube Video
LibUSB Win32
Bis jetzt war das alles eigentlich für mich nur so ein Einstig in die USB<->AVR Programmierung. Doch wenn Interesse besteht, dann würde ich anfangen für euch Schaltpläne, Layout und Beschreibung für Singel, Dual und Quad-Variante machen und den SourceCode (sowohl PC als auch AVR seitig) aufräumen und veröffentlichen.
So dann wär mal Zeit fürn bisschen Feedback, Verbesserungen und Kritik sind bei mir immer erwünscht.
Gruß hackspider
|
|
|
|
|
Gespeichert
|
|
|
|
StarGoose
Modding Urgestein
Karma: +5/-0
Offline
Geschlecht:
Beiträge: 2014
selber suchen tut nicht weh!
|
Respekt nicht Schlecht
was mir nur Grundsätzlich hier auffällt ist die Win xp Kompatibilitätsmodus und unsignierte Treiber Geschichte
schließlich steht windows 7 vor der türe keine ahnung ob das dort immernoch so klappt
eine "echte" lösung des treiberprobems für die usb sachen unter vista/win7 wäre wohl mal der große wurf
mit dem "riesen" avr kann man sicherlich auchnoch andere sachen veranstalten... lüfter regeln, spannungen messen noch viel mehr leds rumblinken lassen, ein display ansteuern.. naja es klemmt wohl immernich grundsätzlich an der treibergeschichte
|
|
|
|
|
Gespeichert
|
|
|
|
mak
Modder der Apokalypse
Karma: +3/-0
Offline
Geschlecht:
Beiträge: 1147
M/A/K
|
eine "echte" lösung des treiberprobems für die usb sachen unter vista/win7 wäre wohl mal der große wurf
Da ich Win7-RC1-User bin interessiert mich das auch brennend. Ich würde mich natürlich fürs Testen zur Verfügung stellen. Aber ein kleiner Tipp: Kleinerer AVR und standardmässig Schieberegister. Die Software sendet so viele Daten wies Kerne hat zum AVR, der AVR sendet dann alles was er erhält ans Register.
Vorteil dieser Methode wäre einerseits, dass man einen zeitlichen Verlauf sehr einfach darstellen könnte (Verkettung von Schieberegistern), andererseits könnte man eine Unabhängigkeit von den Anzahl Kernen und verwendeten Registern erzielen. Wenn man also von einem Dualcore-System auf ein Quadcore-System aufrüstet kann man die alte Anzeige weiterverwenden. Am besten die Kerne absteigend senden, dann bleiben z.B. bei 2 Registern nur die Kerne 0 und 1, was zumindest mir sinvoller erscheint, Stichwort Gamen. Möglich wäre auch noch eine Checkbox "Average", sodass nur der Durchschnitt aller Kerne übermittelt wird, dies macht natürlich nur bei einem Register Sinn.
Noch eine Frage: Wie hoch ist die Updatefrequenz? Eine Sekunde? Oder einstellbar?
|
|
|
|
|
Gespeichert
|
M/A/K hat gesprochen! Athlon X2 6400 + Xigmatek Achilles / 2x 2 GB RAM / 64 GB SSD / ATI 5850 / C433 / Windows-Rating: 6.3 |
|
|
hackspider
Wakü-Poseidon
Karma: +4/-0
Offline
Geschlecht:
Beiträge: 412
|
Hi nochmal,
@StarGoose
Hab das ganze auch schon aufm Win7 RC1 getestet, da funktioniert alles bis auf die Sache mit dem ReadyDriver, d.h. man muss bei jedem Start den Trick mit der F8 Taste machen.
Solange M$ keine Möglichkeit bietet, Treiber kostenlos zu signieren, bzw. keine Möglichkeit anbietet die Treibersignierungsprüfung abzuschalten, siehts ziehmlich schlecht aus für Bastel-USB.
Ich bin überhaupt kein Freund von Vista und von Windows 7 bin ich auch nicht wirklich überzeugt. Die Treiberproblematik hat mir fast schon wieder den Rest gegeben, hab für die Vista-User dann doch ne alte HDD ausm Schrank gekramt und meine msdnaa-Lizenz mal installiert. Da muss noch einiges passieren bis ich das produktiv einsetzten kann.
BTW:
Der AVR kann natürlich noch ne Menge mehr: (Von mir getestet)
- Lüfter regeln PWM -> gläten -> OP -> PFET (NoDrop2 Prinzip)
- Mittels NTC Temperatur messen
- Drezahlmesser -> ICP
Könnte man ne lustige digitale Lüftersteuerung machen, gibts aber ja schon einige
@mak
Der einzige Grund warum so ein "großer" AVR benuzt wurde ist, dass es die letzten waren die ich da hatte  .
Dein Vorschlag gefällt mir gut, super geeignet für die Multicore Unterstützung werde ich genau so weiterverfolgen. Allerdings fehlen mir im Moment die Schieberegister um einen Versuch aufzubauen. Elektronisch und Programmiertechnisch dürfte da nichts im Weg stehn.
PC seitig is dem Ganzen keine Grenzen gestezt: ob man das Ganze dann als Lauflicht, Blinklicht, RAM, HDD, VU, oder klassisch als CPU Auslastungsanzeige verwendet ist dann jedem selber überlassen.
Im Moment, kann ich mir aussuchen, ob ich einzelne Kerne, oder den "Total Load" (der angesprochene Average) anzeigen will.
Zu deiner Frage: Die Updatefrequenz is im Moment fix im Code mit 100ms drin, diese ist aber auf jeden Fall einstellbar geplant. Es wird 10 mal pro Sek neue Werte geholt und beim einer Veränderung an den AVR gesendet.
Gruß hackspider
|
|
|
|
|
Gespeichert
|
|
|
|
|
|
TzA
Modder der Apokalypse
Karma: +10/-0
Offline
Geschlecht:
Beiträge: 1166
|
Tante Google meint dass das hier auch unter Win7 die Installation unsignierter Treiber erlauben sollte, funzt aber nur ohne UAC (vermutlich muss sich das Tool halt andauernd Dinge tun, die root-Rechte brauchen).
Ich bin mal optimistisch, dass mit der fortschreitenden Verbreitung von Win7 sich da noch was finden wird.
Ansonsten ist das schonmal sehr schön dass sich wer die Mühe macht und immerhin für Vista eine gute Lösung gefunden hat.
Sofern das alles sauber läuft und getestet ist, würde ich ja vorschlagen da ein Tutorial für die Hauptseite draus zu machen.
Abgesehen von einer Umstellung auf Schieberegister, die dann auch die CPU-Auslastung eines Core i7 mit seinen 8 Kernen problemlos anzeigen können sollte, wäre evtl noch ein Umbau des USB-Protokolls sinnvoll.
So wie ich das verstanden habe, "denkt" der AVR momentan nur in CPU-Auslastungen und legt einfach alles was er an Daten bekommt auf seine Ausgänge.
Wenn so eine fertige USB-Plattform mit passendem PC-Programm aber erstmal vorhanden ist, dürfte es durchaus Interessenten geben, die da noch selber was dazuprogrammieren möchten.
Deswegen sollte man die Übertragung nach Möglichkeit auf mehrere verschiedenen Nachrichtentypen auslegen, USB ist ja schnell genug dass der Overhead nicht stören sollte.
|
|
|
|
|
Gespeichert
|
You need only two tools. WD-40 and duct tape. If it doesn't move and it should, use WD-40. If it moves and shouldn't, use the tape |
|
|
hackspider
Wakü-Poseidon
Karma: +4/-0
Offline
Geschlecht:
Beiträge: 412
|
Hi,
diese Tool hatte ich auch eine kurze Zeit ausprobiert, aber eine Abschaltung der UAC war mir doch zu riskant für den Dauereinsatz.
Ich seh das genauso wie du, dass sich da mit der Zeit noch eine richtige Lösung finden wird.
Der AVR denkt im Moment nicht einmal (und das würde ich gerne auch so belassen), er bekommt in der aktuellen Fassung zwei Bytes zugesendet, die er ohne Bearbeitung an die IO-Pins weitergibt. Das Abbilden der CPU Auslastung auf ein Byte übernimmt das Programm auf dem Computer also zwischen 0 und 12,5% ist das Byte=1, zwischen 12,5 und 25% ist das Byte=3 usw.
In der Version an der ich gerade arbeite, wird dem AVR ein Byte[] (Buffer) gesendet, der dann über die Schieberegister einfach rausgeschoben wird.
Damit entnehme ich dem AVR jede Logik, sodass man bei der Integration von neuen Features, keine neue Firmware flashen muss.
PC seitig wird es eine Pluginstruktur geben (die ich aus einem meiner aktuellen Projekte übernommen habe), diese erlaubt es dann zusätzlich Blinklicht,Lauflicht,RAM,HDD,VU-Meter Plugins zu schreiben.
Was mir heute Nachmittag noch so kam war, das man das ganze auch als Multi-CLCD Ansteuerung via USB nutzbar machen könnte. Ist halt nur die Frage, ob die Schieberegister/AVR Combi schnell genug ist.
Gruß hackspider
|
|
|
|
« Letzte Änderung: Juni 23, 2009, 00:42:11 von hackspider »
|
Gespeichert
|
|
|
|
mak
Modder der Apokalypse
Karma: +3/-0
Offline
Geschlecht:
Beiträge: 1147
M/A/K
|
Da die LCDs "vorher" per LPT angesteuert wurden, sollte die Geschwindigkeit des USB-Ports ausreichen, der ist ja viel schneller.
Ich überlege mir gerade, ob es von Vorteil wäre, mehrere Kanäle (sprich Schieberegisterreihen) zu implementieren. Also jeweils einen Kanal für CPUs, einen für RAM, HDD, VU, usw, jeder mit einstellbarer Geschwindigkeit. Will man das Ganze nicht zu kompliziert machen, würde ich 2 Kanäle empfehlen. Einer mit hoher Aktualisierungsgeschwindigkeit für CPU & VU-Meter und einen mit tiefer Aktualisierungsgeschwindigkeit für RAM, HDD, Beleuchtung.
Für die Konfigurationsseite noch eine Idee:
Am besten mit Drag-&-Drop-System, wenn das zu aufwändig ist wären Dropdownlisten in den Feldern gute Alernativen.
|
|
|
|
|
Gespeichert
|
M/A/K hat gesprochen! Athlon X2 6400 + Xigmatek Achilles / 2x 2 GB RAM / 64 GB SSD / ATI 5850 / C433 / Windows-Rating: 6.3 |
|
|
|
|
hackspider
Wakü-Poseidon
Karma: +4/-0
Offline
Geschlecht:
Beiträge: 412
|
Hi,
eigentlich hatte ich mir das so gedacht: ein Timer der alle 20 oder 50ms checkt ob sich Daten geändert haben, wenn ja wird eine USB-Message erzeugt und die neuen Daten an den AVR gesendet. Dieser Intervall soll vom Benutzer NICHT verändert werden können. Jetzt bekommt jedes Plugin einen einstellbaren Timer bei dem man einstellen kann, wie oft die Daten aktualisiert werden (Bissel verwirrend).
Timer USB (20ms) ---> Byte[] (aktuelle Daten) <--- Plugins (100ms bis 10sek)
Man kann sich das ganze wie ein SharedMemory Bereich vorstellen, bei dem die Plugins Daten ablegen, und der USB Timer bei änderungen der Daten diese losschickt.
Ob Leser/Schreiber Probleme auftreten und inwiefern das gehandhabt werden muss ist noch zu testen.
Vorteil dieser Lösung ist, man braucht nur eine Schieberegisterkanal und kann dennoch für jedes Element des Kanales eine "fast" belibig kleine oder große Aktualisierung erreichen.
GUI technisch hab ich mir noch nicht wirklich Gedanken gemacht, allerdings sollte Drag&Drop mit WindowsForms und C# eigetlich keine Probleme machen (unter Vorbehalt).
Gruß hackspider
|
|
|
|
|
Gespeichert
|
|
|
|
|
|
hackspider
Wakü-Poseidon
Karma: +4/-0
Offline
Geschlecht:
Beiträge: 412
|
Hi,
find ich gut, dass sich hier noch andere darüber Gedanken machen  .
Die Abschätzung von 20 bis 50ms war nur grob, da kann man ruhig auf die 50ms (20Hz) gehen. Mehr lohnt sich wirklich nicht. Eine Idee die mir heute Nachmittag noch gekommen ist: Man könnte den kleinsten eingestellten Plugintimer für die Aktualisierung des AVRs verwenden. Dass wäre dann wirklich die maximale Updaterate die man Verwenden kann und die am ressourcensparendste Lösung. Bis jetzt hab ich keine Messungen, wie ressourcenfressend Zugriffe auf USB sind, wäre interesannt zu wissen.
Der Lösungsansatz, mit 2 Kanälen ist eigentlich, keine falsche Idee, da CPU, HDD Zugriffe sich viel schneller ändern als z.B. der Füllstatus einer Partition, aber der Vorteil gegenüber einer Einkanallösung seh ich leider nicht wirklich. Wir reden beim Payload über 1 Byte pro Schieberegister, da ist es dann egal ob man 1 Byte oder 8 Bytes sendet, der Overhead der durch das USB-Protokoll auftritt dürfte um einiges größer sein.
Für die Synchronistation könnte man durchaus einen intelligenten Algorithmus schreiben, der Plugins mit gleicher Updaterate auf einen gemeinsamen Timer mappt.
Ich habe kommende Woche Abgabe zweier Projekte die im Moment meine Freizeit in Anspruch nehmen, werd aber schauen ob ich das ein oder andere schonmal Umsetzten kann. Hab erstmal heute bei meinem Elektroniker meines Vertrauens Schieberegister gekauft, leider nicht die 74HC595, die ich aufgrund ihres Ausgangsregister gerne eingesetzt hätte, sondern nur die 74HC164er. Zum testen sind auch die in Ordnung, in der finalen Lösung hätte ich aber doch gerne die 595er. Die ersten Test mit dem Schieberegister sehen ziehmlich gut aus, denke darauf kann man ausetzten.
Gruß hackspider
|
|
|
|
|
Gespeichert
|
|
|
|
mak
Modder der Apokalypse
Karma: +3/-0
Offline
Geschlecht:
Beiträge: 1147
M/A/K
|
Ich hab mal ausgerechnet, wie lange eine Aktualisierung überhaupt dauert, gesetzt der Fall, dass der AVR die Bytes so schnell auf die Schieberegister schreibt wie sie ankommen. (Trifft dies überhaupt zu?)
Da das Schieberegister mit bis zu 55 MHz arbeiten kann, scheidet wohl USB 2.0 (480 Mbit/s) aus, doch werden bei USB 1.1 (12 MBit/s) für ein Byte nur 5.333 Mikrosekunden benötigt. Da das menschliche Auge viel zu langsam ist, frage ich mich, ob simple Schieberegister ohne Puffer nicht den gleichen Zweck erfüllen würden, zumindest bringen die anderen keinen Vorteil.
Deine Argumentation bezüglich dem Protokoll Overhead hat mich überzeugt, auch wenn ich nicht weiss, wie gross der Overhead tatsächlich ist.
|
|
|
|
|
Gespeichert
|
M/A/K hat gesprochen! Athlon X2 6400 + Xigmatek Achilles / 2x 2 GB RAM / 64 GB SSD / ATI 5850 / C433 / Windows-Rating: 6.3 |
|
|
hackspider
Wakü-Poseidon
Karma: +4/-0
Offline
Geschlecht:
Beiträge: 412
|
Hi,
der relevante Takt, mit dem die Bits auf die Schieberegister geshoben werden, sind die 12MHz des AVRs. Das sind 3*83,3ns=250ns (3x : 1x Pin setzten 0/1 1x CLK auf High und wieder auf Low) pro Bit. Um ein ganzes Schieberegister (8bit) zu shiften sind das dann 8x250ns = 2000ns = 2µS. Da müssen schon ne ganze Menge Schieberegister dranhängen bis das Auge das sieht. D.h. Sorgen wegen der Geschwindigkeit, müssen wir uns an einer Anderen stelle machen  .
Der Grund für die Schieberegister mit Ausgangspuffer, war der Gedanke auch LCDs damit ansteuern zu können. Da kann man nicht mehr kontrollieren was mit dem LCD geschieht wenn andauernt etwas über den Enable Pin geshiftet wird.
Für eine reine LED Variante ist es egal, ob das Schieberegister einen Ausgangspuffer hat oder nicht.
Wie die Geschwindigkeit am USB Aussieht, konnte ich nicht wirklich in Erfahrung bringen, die Implementierung von VUSB ist jedenfalls ein USB 1.1 low speed device (1.5 Mbit/Sek). Allerdings schweigt sich die VUSB Homepage auch über jegliche Datentransferrate aus und für genaue Messungen hatte ich bis jetzt keine Zeit.
Was mich noch interessiert ist wie oft und wie schnell Daten an ein LCD gesendet werden müssen, damit man auch einen VU-Meter noch betreiben könnte, das wäre dann wirklich der absulute maximum Faktor was die Schaltung können müsste.
Gruß hackspider
EDIT: Reichelt Bestellung ist raus, bis dahin heißt es warten 
EDIT2: Reichelt ist zwar da, aber im Moment häng ich hier grad in mitten der Klausuren, dannach gehts hier weiter
|
|
|
|
« Letzte Änderung: Juli 15, 2009, 12:25:28 von hackspider »
|
Gespeichert
|
|
|
|
nobody44
Modding-Noob
Karma: +0/-0
Offline
Beiträge: 18
Ich liebe dieses Forum!
|
Hallo,
Da hier viele Bedenken haben wegen der Treibersignierung mal ein kleiner Vorschlag von mir:
Überlege dir eventuell auf die serielle Schnittstelle umzusteigen. Es gibt einen IC, der quasi als USB-RS232-Übersetzer (bzw. UART) fungiert. In Windows ist diese Schnittstelle entweder direkt ansprechbar oder über die serielle Schnittstelle, die bei der Installation der Treiber erstellt wird.
Ich hatte mal ein Testboard mit diesem IC und es lief sehr gut (ich hatte es auch für größere Geschwindigkeiten getestet und es lief gut). Allerdings kann ich mich nicht mehr an die Installation der Treiber erinnern und weiß also nicht, ob die Treiber signiert sind, aber auf der Homepage steht: "Microsoft WHQL certified."
Homepage des Herstellers des ICs: Link
Name des ICs: FT232R (ich weiß leider nicht mehr, welchen genau ich habe, da gibt es mehrere!)
Der größte Nachteil für Bastler: Die Chips sind nur in SMD-Bauweise vorhanden. Mir fiel der Umstieg schwer, aber ich würde jetzt bei SMD bleiben...
|
|
|
|
|
Gespeichert
|
|
|
|
Seiten: [1] 2 3 
|
|
|
|
|
