Hallo Community, ich habe eine Frage zu der Taktfrequenz meines Mikrocontrollers. Ich arbeite zur Zeit mit einem 32-bit ARM Cortex-M3 mit 96MHz und 512KB FLASH & 32KB RAM. Ich habe ein Programm geschrieben in dem der µC alle 0,131 ms (131µs) einen Wert von einer Textdatei einließt und via CAN-Bus ausgibt. Wie kann man nachweisen, dass die 96MHz vom Mikrocontroller dafür ausreichend sind? Gibt es da eine Formel oder so? Vielen Dank, Jim
@ Jim Street (jimstreet) >Wie kann man nachweisen, dass die 96MHz vom Mikrocontroller dafür >ausreichend sind? Gibt es da eine Formel oder so? Simulation, der Simulator kann Takte bzw. die Ausführungszeit messen. Reale Messung. Am Anfang der Funktion ein IO-Pin auf HIGH setzen, am Ende auf LOW. Das kann man mit dem Oszi messen. Ich würde die 2. Variante wählen, ist einfacher und meist aussagekräftiger.
Einfacher. In der Main Loop, bei welcher schliesslich auf irgendwelche Ereignisse gewartet wird, pulst man einen freien Pin. Auf dem Oszilloskop kann man dann zuschauen wie sich diese Wartezeit ueber die Zeit verhaelt.
alle 131µS ein neues Frame? Was für nen CAN hast du, wieviele Daten überträgst du..? Bist du sicher, dass dir die Zeit überhaupt zur übertragung reicht..? Ansonsten: ansatz 2 von Falk. Zur verifikation der Plausibilität instruktionen im disassembly zählen und ausführungszeit berechnen, aber das geht nur näherungsweise..
Vielen Dank schon mal. Gibt es denn auch eine Möglichkeit um das Theoretisch zu errechnen. Also angenommen ich hätte noch keinen µC gekauft und möchte jetzt wissen ob ein 96MHz ausreichend ist. @dunno: Ja alle 131µs einen Frame bestehend aus ID, DLC und 8byte Daten. Verwende Highspeed-CAN, sollte eig klappen.
gut, 11bit Id, 1m? dann wirds wohl klappen. Also der einzige theoretische ansatz den ich kenne ist, die Assembler-instruktionen des fraglichen codes zu zählen, und mit den takten/instruction des µC zu multiplizieren (achtung, je nach instruktion unterschiedlich)... das ganze ist natürlich bei nem pipelinenden core nicht mehr wirklich exakt... eine worst case-näherung sollte aber dennoch möglich sein. exakt wirds nur mit messen, und auch nur dann wenn du keine interrupts oder sowas hast, dann fängts nämlich an zu jittern, und du kannst wieder nur mittelwerte bilden.. ;)
Der CPU-Takt ist nicht der Flaschenhals. Wie lange dauert es, das Medium zu lesen, wo das Filesystem und die Textdatei drauf ist? Der CAN-Bus kann max 1MHz und braucht dann etwa 130µs für 8 Byte. Da ist keine Luft mehr, wenn mal die Arbitration verloren geht.
Beim Atmel-Studio gab es eine Möglichkeit, einen Taktzähler zurückzusetzen, um dann am nächsten Brake-Point nachzusehen, wie viele Ticks benötigt wurden. Ob Deine Umgebung das zulässt weis ich aber nicht. Bedenke aber, dass es oft Verzweigungen gibt, die eine variable Laufzeit bewirken. Kann insbesondere, wenn die Fließkommabibliothek ins Spiel kommt, große Unterschiede ausmachen.
Peter Dannegger schrieb: > Der CAN-Bus kann max 1MHz und braucht dann etwa 130µs für 8 Byte. Da ist > keine Luft mehr, wenn mal die Arbitration verloren geht. Peter, aus reinem interesse: wie hast du das berechnet? ich habe einfach nur die bit-zeiten der kleinstmöglichen bitanzahl (bin auf 52 bit gekommen, das wären dann 52µS ohne interframe spacing etc bei 1Mhz?) Was das filesystem angeht, hat peter natürlich recht..
Jim Street schrieb: > Wie kann man nachweisen, dass die 96MHz vom Mikrocontroller dafür > ausreichend sind? Gibt es da eine Formel oder so? Eine einfache Formel gibt's zwar net, aber Ansätze zur Bestimmung von Laufzeitschranken gibt's schon. Google mal nach WCET-Analyse.
dunno.. schrieb: > Peter Dannegger schrieb: >> Der CAN-Bus kann max 1MHz und braucht dann etwa 130µs für 8 Byte. Da ist >> keine Luft mehr, wenn mal die Arbitration verloren geht. > > Peter, aus reinem interesse: wie hast du das berechnet? ich habe einfach > nur die bit-zeiten der kleinstmöglichen bitanzahl (bin auf 52 bit > gekommen, das wären dann 52µS ohne interframe spacing etc bei 1Mhz?) > > Was das filesystem angeht, hat peter natürlich recht.. okay, entschuldige, ich habe mit 1 byte daten gerechnet. dann sinds natürlich 52 + 56 = 108bit.. aber wie kommst du auf den rest..? ists ein rule of thumb wert, oder gibts da genauere faktoren für?
dunno.. schrieb: > dann sinds natürlich 52 + 56 = 108bit Start of Frame sind auch nochmal mindestens 12 Bit. Mehr als 120 kann ich aber auch nicht finden.
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.