Hallo Leute hat jemand eine Idee, wie ich die Auslastung eines µC bestimmen kann? Konkret geht es bei mir um einen XMega192A3, der einen Motor steuern und Daten über 2 USARTs empfangen / senden soll (mit DMA). Ich bin mir nicht sicher ob ich dem µC das alles zumuten kann oder ob ich lieber auf 2 Prozessoren setzen sollte. Gerade die Motorsteuerung ist schon sehr zeitkritisch. Ich bin hier im Forum schon auf den Beitrag [Beitrag "AVR Videogenerator, 40x25 Zeichen, nur 60% CPU Auslastung !"] gestossen, habe es aber nicht verstanden. Wäre super wenn mir da jemand einen Hinweis geben könnte! Grüße lexman
> der einen Motor steuern Was genau ist darunter zu verstehen? > Ich bin mir nicht sicher ob ich dem µC das alles zumuten kann > oder ob ich lieber auf 2 Prozessoren setzen sollte. Und du denkst, die dann notwendige Kommunikation zwischen den Prozessoren macht sich mit links? UART ist normalerweise überhaupt kein Thema, was Prozessorauslastung angeht. > Gerade die Motorsteuerung ist schon sehr zeitkritisch. Was verstehst du unter zeitkritisch? So ein Motor ist ein Ding das sich dreht und das eine träge Masse hat. Ehe ein Motor seine Umdrehungsgeschwindigkeit auch nur um ein paar Prozentpunkte verändern kann, hat dein µC viele Tausend Befehle durchgehechelt.
Alex Spielberg schrieb: > hat jemand eine Idee, wie ich die Auslastung eines µC bestimmen kann? Schalte einen Pin immer dann auf High, wenn Du was tust, schalte ihn auf Low, wenn Du nichts tust. Miss dann einfach die Spannung des Pins - eventuell mit einem Tiefpass dahinter.
Wie wäre es immer einen Pin-Ausgang zu setzen wenn er gerade etwas macht und ihn im IDLE-State wieder zurück zu setzen? Dann könnte man über die mittlere Spannung auf die Auslastung schließen!? Grüße
kommt ein bisschen auf dein "Betriebssystem" an. Wenn Du Deine Tasks abarbeitest und danach nur noch auf den Timer wartest, bis der zum Beispiel die nächste 1ms meldet, dann kann man in dieser Wartezeit einfach einen Port auf LOW setzen, und während der Rechenzeit und in den Interrupts auf High. Analoger Zeigerinstrument mit 5V Vollausschlag an den Port und Du kannst die CPU Last schön ablesen.
@Frank @Hugo @74xxx Ich lese den Text der Frage so, dass das System noch nicht existiert, sondern eine Abschätzung benötigt wird, ob man mit 1 XMega durchkommt oder ob man besser 2 nehmen sollte.
Karl Heinz Buchegger schrieb: > Ich lese den Text der Frage so, dass das System noch nicht existiert, > sondern eine Abschätzung benötigt wird, ob man mit 1 XMega durchkommt > oder ob man besser 2 nehmen sollte. Jopp...so könnte man es wirklich lesen. Denke mal das ist richtiger :-D
Karl Heinz Buchegger schrieb: > Ich lese den Text der Frage so, dass das System noch nicht existiert, > sondern eine Abschätzung benötigt wird, ob man mit 1 XMega durchkommt > oder ob man besser 2 nehmen sollte. Da hast Du wohl recht, wenn ich es nochmal genau lese :-) Zur Frage: Ich vermute mal, dass sich die Motorsteuerung gar nicht sinnvoll auf 2 µCs aufteilen lassen kann - jedenfalls nicht, ohne jede Menge Daten hin- und herzuschaufeln. Bleibt nur der USART-IO übrig, den man auf einen 2. µC auslagern könnte. Diesen auf einen anderen µC zu schieben ist jedoch genausowenig sinnvoll, weil man dann ja vom 1. µC die I/O-Daten erstmal auf den 2. µC bekommen müsste. Der I/O bleibt also dem 1. µC gar nicht erspart - so oder so. Also muss/kann er diese Aufgabe dann auch direkt erledigen. Ich glaube auch, dass das mit einem µC machbar ist. Gruß, Frank
Hi, der ATXMega192A3 hat für genau diesen Zweck dezidierte Hardware integriert, die einen Großteil der zeitkritischen Aufgaben übernimmt:
1 | The Advanced Waveform Extension (AWEX) provides extra features to the Timer/Counter in |
2 | Waveform Generation (WG) modes. The AWEX enables easy and safe implementation of for |
3 | example, advanced motor control (AC, BLDC, SR, and Stepper) and power control applications. |
http://www.atmel.com/dyn/resources/prod_documents/doc8068.pdf (Seite 33) Ich denke nicht dass der µC Probleme mit der gestellten Aufgabe haben wird. Gruß, Reinhard
>Gerade die Motorsteuerung ist schon sehr zeitkritisch. Dann kann es ja sein, dass der AVR es gar nicht hinkriegt. Also hat sich dann das Problem schon erledigt. (Also zuerst die Motorsteuerung 'sicher' machen). Wenn er's hinkriegt, wird er wohl für ein paar INTs aus'm UART noch Zeit haben.
Du musst in jedem Fall mehre Messungen mit unterschiedlichen Debug-Aktionen machen, um ein Gleichungssystem zu bekommen, dass die Dauer der Debugaktivitäten wegrechnen kann. Z.B. ZeitA + 340 x pin toggle = Zeit1 für 100 Durchläufe ZeitA + 750 x pin toggle = Zeit2 für 100 Durchläufe
Die XMegas haben auch ein Eventsystem das Eigenständig Daten von A nach B über eine mehlagiege Busmatrix transportieren (unabhängig von DMA und IRQ). Aber ich würde auch erst mal gucken ob der AVR dafür geeignet ist. Oder doch lieber nen DSP bzw. DSC.
Ich warte eigentlich immer noch auf die kritischen Informationen * was für ein Motor ist das * was ist unter 'ein Motor muss gesteuert werden' zu verstehen * was ist unter 'zeitkritisch' zu verstehen. Ehe diese Dinge nicht geklärt sind, hat es keinen Sinn zu spekulieren. Mit diesen Informationen steht und fällt alles. Diese Beschreibung passt auf einen Rolladenmotor genausogut (und in dem Fall hat der µC massig Zeit um nebenbei sich die Zeit mit dem Lösen von quadratischen Gleichungen zu vertreiben), wie sie auf die Steuerung eines Brushlessmotors passen würde (und in dem Fall wird es dann schon enger mit den quadratischen Gleichungen).
Wau mensch Leute, ihr geht ja ab. Ich hab auf die kurze Zeit gar nicht mit so viel Resonanz gerechnet. Also erst mal VIELEN DANK euch allen!! Nun zu den Fragen. Das System existiert schon! Ich habe einen Motor, den ich durch PWM steuere und dafür das AWEX nutze. Der Motor ist ein einfacher BLDC. Außerdem mache ich Wegmessungen, zähle also die Interrupts, die von den Hallsensoren kommen. Je nach Weg und wie viel Last auf dem Motor ist, steuere ich das PWM. Die Last auf dem Motor wird über einen externen Sensor gemessen, der die Daten über die USART an den XMega schickt. Weiterhin will ich diese Lastdaten und den gefahrenen Weg über die 2te USART an den PC schicken. Das alles sollte eben möglichst "gleichzeitig" ablaufen. Das heißt, das Senden / Empfangen der Daten über die USARTs sollte nicht die Berechnung und das neu setzen des neuen PWM Wert beeinflussen. Der µC läuft übrigens mit 36MHz (ext. 12MHZ, PLLx3) falls das relevant ist. Also die Hinweise mit Pin setzen wenn ich was tue, zurücksetzen wenn ich nix tue machen schon Sinn. Aber wie realisiere ich das genau? Wann weiß ich denn wann er nix tut? Bzw, springt der da in eine Sleep-Funktion oder so was ähnliches? Danke für eure Hilfe. Gruß lexman
Alex Spielberg schrieb: > Das System existiert schon! Ich habe einen Motor, den ich durch PWM > steuere und dafür das AWEX nutze. Der Motor ist ein einfacher BLDC. d.h. die eigentliche Motoransteuerung läuft sowieso schon in Hardware > Außerdem mache ich Wegmessungen, zähle also die Interrupts, die von den > Hallsensoren kommen. Je nach Weg und wie viel Last auf dem Motor ist, > steuere ich das PWM. Die Last auf dem Motor wird über einen externen > Sensor gemessen, der die Daten über die USART an den XMega schickt. Kein Problem. Die paar µs pro übertragenem Byte hat der XMEGA allemal. Die eigentliche Übertragung eines Byte erledigt ja die UART Hardware des XMEGA. Du musst nur das fertig empfange Byte, nach Interrupt Benachrichtigung durch die UART-Hardware irgendwo zwischenspeichern. Das ist noch nicht einmal zeitkiritsch, denn bis das nächste Byte komplett von der UART empfangen wurde, hast du genügend Zeit um zwischendurch wichtigeres zuerst fertig zu stellen. > Weiterhin will ich diese Lastdaten und den gefahrenen Weg über die 2te > USART an den PC schicken. Auch kein Thema. AUch das kann die Hardware mit ein paar µs unterstützung locker erledigen. > Das alles sollte eben möglichst "gleichzeitig" ablaufen. Das heißt, das > Senden / Empfangen der Daten über die USARTs sollte nicht die Berechnung > und das neu setzen des neuen PWM Wert beeinflussen. Wenn du es richtig machst, dann tut es das auch nicht nennenswert. > Also die Hinweise mit Pin setzen wenn ich was tue, zurücksetzen wenn ich > nix tue machen schon Sinn. Aber wie realisiere ich das genau? Wann weiß > ich denn wann er nix tut? Du schreibst das Programm. Also musst du wissen, wann dein Programm nix mehr zu tun hat. > Bzw, springt der da in eine Sleep-Funktion > oder so was ähnliches? Wenn du das nicht programmierst, dann passiert es auch nicht.
Wenn Du Dir mal anschaust dass diese Balancing Robots die es zu haufen gibt, 2 Motoren (Gut...sind meist normale DC Motoren) ansteuern, zusätzlich noch einen 4-5 State-Kalmanfilter berechnen, zusätzlich noch auslesen von mind. 4-5 Sensoren (sei es über ADC, SPI oder I2C), dann evtl. noch eine Steuerung über Bluetooth o.ä. realisieren, die Regelung nicht zu vergessen....und das alles mit einem 8 Bit uC der von mir aus 16MIPS hat, keine FPU und kein DMA...dann sollte Dein Vorhaben bei vernünftiger Programmierung (Nutzung von Interrupts, DMA und evtl. Festkommaarithmetik(falls Dein uC keine FPU hat) auf jeden Fall machbar sein. Grüße Hugo
Karl Heinz Buchegger schrieb: >> Bzw, springt der da in eine Sleep-Funktion >> oder so was ähnliches? > > Wenn du das nicht programmierst, dann passiert es auch nicht. Hallo Karl, danke erst mal für deine Erläuterungen! Nun zu dem Sleep. Hast du ein Beispiel, wie man so was programmiert? Im Moment habe ich es so, dass alle Funktionen in der Haupt-while(1) Schleife abgearbeitet werden. Interrupts quetschen sich wie gehabt dazwischen. Also eigentlich ist es doch dann so, dass der Prozessor ständig arbeitet oder? Sobald Befehle in der while(1) rennt der µC doch ständig da durch, oder verstehe ich da was falsch. Ist das dann nicht Volllast? Sollte man in der while(1) sleep Funktionen einbauen um den µC zu entlasten (geht aber auf die Abarbeitungszeit)? Gibts da ein generelles Vorgehen? Gruß lexman
Mit 36MHz bist du außerhalb dessen was der xmega nach Datenblatt kann, das ist dir bewust?
Wenn es geht kannst Du Timerbasiert eine Statemachine machen die in der Main-While-Schleife abgearbeitet wird. Immer wenn dann der durch den Timer ausgelöste, nächste Schritt abgearbeitet wurde, legt sich der uC schlafen und wacht mit dem nächsten Timerinterrupt wieder auf. Grüße
ich schrieb: > Mit 36MHz bist du außerhalb dessen was der xmega nach Datenblatt kann, > das ist dir bewust? Das ist mir schon bewusst. Allerdings läuft er ohne Probleme auch übertaktet mit 4MHZ mehr :) Oder sieht da jemand Probleme? Er wird auch nicht mal warm.
Alex Spielberg schrieb: > Karl Heinz Buchegger schrieb: >>> Bzw, springt der da in eine Sleep-Funktion >>> oder so was ähnliches? >> >> Wenn du das nicht programmierst, dann passiert es auch nicht. > > Hallo Karl, > > danke erst mal für deine Erläuterungen! > > Nun zu dem Sleep. Wozu willst du einen Sleep? Dich interessiert doch wieviele Rechenzeit für die Regelschleife übrig bleibt. Also setzt du einen Pin zb auf 1 wenn die Regelschleife läuft. Interrupts sind Störungen dieses Regelkreises. Tritt also ein Interrupt auf, dann setzt du als erstes den Pin auf 0 und bei Fertigstellung des Interrupts wieder zurück auf 1. Genauso bei allen anderen Dingen, die nicht zur Regelschleife gehören. Mit einem Oszi kannst du dir dann ansehen, wieviele Unterbrechungen der Regelschleife es gab und wie lang die sind. > oder verstehe ich da was falsch. Ist das dann nicht Volllast? Sollte man > in der while(1) sleep Funktionen einbauen um den µC zu entlasten (geht > aber auf die Abarbeitungszeit)? Du gehst mir da ein bischen zu wortwörtlich an die Sache ran. Je nach Situation kann "nichts zu tun" auch "nicht am eigentlichen Hauptproblem arbeiten" bedeuten.
Alex Spielberg schrieb: > Das ist mir schon bewusst. Allerdings läuft er ohne Probleme auch > übertaktet mit 4MHZ mehr :) > Oder sieht da jemand Probleme? Er wird auch nicht mal warm. Würd ich nicht machen. Mir scheint, du machst dir keine oder falsche Vorstellungen davon, welche Rechenpower du da überhaupt zur Verfügung hast. Bis jetzt hab ich da in deiner Beschreibung noch nichts gesehen, was der µC nicht mit links aus dem Handgelenk im Vorübergehen erledigen könnte.
Karl Heinz Buchegger schrieb: > Alex Spielberg schrieb: > >> Das ist mir schon bewusst. Allerdings läuft er ohne Probleme auch >> übertaktet mit 4MHZ mehr :) >> Oder sieht da jemand Probleme? Er wird auch nicht mal warm. > > Würd ich nicht machen. > Mir scheint, du machst dir keine oder falsche Vorstellungen davon, > welche Rechenpower du da überhaupt zur Verfügung hast. Bis jetzt hab ich > da in deiner Beschreibung noch nichts gesehen, was der µC nicht mit > links aus dem Handgelenk im Vorübergehen erledigen könnte. Ok, das wusste ich ja eben nicht, was der Prozessor schafft. Und warum sollte ich ihn nicht auf das Maximum einstellen? Ich arbeite zum ersten mal mit XMega und kann mich da nur an eure Erfahrungen halten. Im Moment läuft er ja wie er soll und zeigt keine Aussetzer und stößt auch an keine Grenzen. Mich hat eben mal interessiert, wie stark ich ihn auslaste. Wenn ihr meint, dass der Prozessor das alles locker schafft, dann glaub ich das mal. Wär eben schön das auch messen zu können und zu sehen. Ich werde eure Tipps mal ausprobieren. Danke an alle! PS. Karl, warum würdest du ihn nicht auf 36MHz einstellen? Die 4MHz mehr äußern sich doch nur in mehr Rechenleistung und höhere Wärmeentwicklung oder?
Alex Spielberg schrieb: > Und warum sollte ich ihn nicht auf das Maximum einstellen? AUF das Maximum JA....ÜBER das Maximum NEIN! Alex Spielberg schrieb: > P.S. Karl, warum würdest du ihn nicht auf 36MHz einstellen? Die 4MHz mehr > äußern sich doch nur in mehr Rechenleistung und höhere Wärmeentwicklung > oder? Momentan scheint es zu funktionieren (bist Du Dir wirklich sicher dass ALLES gerade funktioniert?) Wenn es aber morgen 10 Grad wärmer ist...funktioniert es dann trotzdem noch? Wenn Deine Spannung etwas höher ist...funktioniert es dann immernoch? Das ist das Problem. Du kannst nicht davon ausgehen, dass wenn Du ihn Übertaktest dass er immer funktinoiert. Oder das ein anderer uC vom gleichen Typ auch mit der Übertaktung klar kommt. Des Weiteren reicht der in den Spezifikationen angegebene Takt warhscheinlich sowieso aus. Die 4 MHz reisen das auch nicht raus! Grüße
Ok, das seh ich schon ein. Dann denke ich werde ich mal mit 24MHZ (PLLx2) arbeiten. Noch eine Frage. Es gibt ja auch die internen 32MHz. Ich habe nur etwas bedenken, dass die u.U. etwas ungenauer sind als extern einen Quarz zu verwenden. Der µC generiert den Takt ja intern. Sind die Bedenken gerechtfertigt?
Alex Spielberg schrieb: > PS. Karl, warum würdest du ihn nicht auf 36MHz einstellen? Weil die Leute bei Atmel keine Trottel sind. Wenn die den Prozessor auf max 32Mhz spezifizieren, dann werden die wohl wissen was sie tun. Schliesslich kennen die das Innenleben des µC am besten und wissen wo dann das Timing knapp werden könnte. Wenn es für den µC kein wie auch immer geartetes Problem wäre mit 36Mhz zu laufen, dann würden sie ihn auch mit dieser Zahl verkaufen. Ist ja schliesslich auch ein Verkaufsargument.
Karl Heinz Buchegger schrieb: > Weil die Leute bei Atmel keine Trottel sind. Wenn die den Prozessor auf > max 32Mhz spezifizieren, dann werden die wohl wissen was sie tun. > Schliesslich kennen die das Innenleben des µC am besten. > Wenn es für den µC kein wie auch immer geartetes Problem wäre mit 36Mhz > zu laufen, dann würden sie ihn auch mit dieser Zahl verkaufen. Ist ja > schliesslich auch ein Verkaufsargument. Naja sie könnten ja auch sehen, dass er super mit 38,2345MHZ funktioniert, geben dann aber lieber eine gerade Zahl an. Oder eben um auf Nummer sicher zu gehen, weiß man ja nicht .. Mir geht es auch gar nicht um die 4 MHZ mehr. Das hat sich nur ergeben, weil ich einen 12MHz Quarz dran hab und den PLLx3 genommen hab. Und anstatt 24Mhz hab ich ihn eben etwas übertaktet.
Normalerweise ist die interne Taktquelle ein RC Oszilator. Hier scheinbar auch. Im Datenblatt (wenn ich das richtig sehe) geben die Schwankungen von 0,7% an. Ein normaler Quarz hat so um die 30 ppm. 0,7% = 7.000ppm Also ist der Quarz um den Faktor 230 besser. Grüße
Alex Spielberg schrieb: > Karl Heinz Buchegger schrieb: >> Weil die Leute bei Atmel keine Trottel sind. Wenn die den Prozessor auf >> max 32Mhz spezifizieren, dann werden die wohl wissen was sie tun. >> Schliesslich kennen die das Innenleben des µC am besten. >> Wenn es für den µC kein wie auch immer geartetes Problem wäre mit 36Mhz >> zu laufen, dann würden sie ihn auch mit dieser Zahl verkaufen. Ist ja >> schliesslich auch ein Verkaufsargument. > > Naja sie könnten ja auch sehen, dass er super mit 38,2345MHZ > funktioniert, Und du hast jede Komponente deines µC getestet, ob sie auch wirklich zuverlässig funktioniert? Wenn der XMega ein EEPROM hat, hast du getestet ob das fehlerfrei geschrieben und gelesen werden kann? Hast du den ADC getestet? Hast du alle PWM Modi durchproviert? Alle Timer? Mit allen Vorteilern? Hast du .... Du hast auch mit 24Mhz noch haufenweise Rechenzeit übrig.
Karl Heinz Buchegger schrieb: >>> Weil die Leute bei Atmel keine Trottel sind. Wenn die den Prozessor auf >>> max 32Mhz spezifizieren, dann werden die wohl wissen was sie tun. >>> Schliesslich kennen die das Innenleben des µC am besten. >>> Wenn es für den µC kein wie auch immer geartetes Problem wäre mit 36Mhz >>> zu laufen, dann würden sie ihn auch mit dieser Zahl verkaufen. Ist ja >>> schliesslich auch ein Verkaufsargument. >> >> Naja sie könnten ja auch sehen, dass er super mit 38,2345MHZ >> funktioniert, > > Und du hast jede Komponente deines µC getestet, ob sie auch wirklich > zuverlässig funktioniert? > Wenn der XMega ein EEPROM hat, hast du getestet ob das fehlerfrei > geschrieben und gelesen werden kann? > Hast du den ADC getestet? > Hast du alle PWM Modi durchproviert? Alle Timer? Mit allen Vorteilern? > Hast du .... Mir geht es ja gar nicht drum ihn schneller laufen zu lassen. Es hat sich halt so mit meinen 12Mhz und Pllx3 so ergeben. Auf 32Mhz komme ich so ja nicht sonst hätte ich ihn auch auf 32Mhz eingestellt. Und natürlich weiß ich nicht, ob er 100% richtig funktioniert. Er tut eben noch das was ich erwarte. Und da sah ich jetzt keine Notwendigkeit ihn runterzudrehen .. Aber noch ein Wort zu internen 32Mhz <-> externe 32Mhz? (mein Beitrag weiter oben) Danke Gruß lexman
Alex Spielberg schrieb: > Aber noch ein Wort zu internen 32Mhz <-> externe 32Mhz? (mein Beitrag > weiter oben) Dann lese mal die geposteten Beiträge, da steht schon was dazu.
Hugo W. schrieb: > Dann lese mal die geposteten Beiträge, da steht schon was dazu. Sorry Hugo, hatte ich übersehen. Danke für deine Antwort. Gruß lexman
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.