Hi, ich habe hier ein kleines Board mit dem LPC1768 das auf 96 MHz läuft. Aktuell habe ich in meiner Firmware eine Interrupt-Routine, die alle 10 usec aufgerufen wird und die ich zukünftig gerne alle 2 oder sogar alle 1 usec ausführen lassen will. Da ergibt sich nun natürlich die Frage, ob da noch Luft drin ist, oder ob der restliche Code dann durch die ISR-Dauerbelastung stehenbleibt. Also habe ich einfach mal die Anzahl if, else, switch/case, Additionen, Subtraktionen, 32-Bit-Wertzuweisungen, Schiebeoperationen, Funktionsaufrufe etc. gezählt und bin auf unter 100 gekommen. Da keinerlei Multiplikationen, Divisionen oder sonstiges noch komplizierteres Mathematisches Gedöns vorkommt, sollte ich diesen so ermittelten Wert doch - weil RISC-CPU - etwa 1:1 auf Taktzyklen umrechnen können, oder? D.h. für eine Verzehnfachung der Aufrufhäufigkeit sollte im Prinzip noch mehr als genügend Luft sein!?
Zooom schrieb: > sollte ich diesen so > ermittelten Wert doch - weil RISC-CPU - etwa 1:1 auf Taktzyklen > umrechnen können, oder? Nein. Nicht jede C Operation ergibgt einen Assembler-Befehl und nicht jeder Assembler-Befehl braucht nur einen Takt. Und dazu kommen ggf. Waitstates beim Zugriff aufs ROM und der Overhead der ISR. > D.h. für eine Verzehnfachung der Aufrufhäufigkeit sollte im Prinzip noch > mehr als genügend Luft sein!? Das geht doch schon mit deiner eigenen Rechnung nicht. Diese 100 Takte in 96 Takten so ausführen, dass noch Luft für das unterbrochene Programm bleibt.
> Das geht doch schon mit deiner eigenen Rechnung nicht. Diese 100 Takte > in 96 Takten so ausführen, dass noch Luft für das unterbrochene Programm > bleibt. 100 Takte in 96 Takten? 10 usec sind 100 kHz, nicht 10 MHz!
Sorry...jetzt fehlt bei mir auch eine Null, ich meinte natürlich 100 MHz
Zooom schrieb: >> Das geht doch schon mit deiner eigenen Rechnung nicht. Diese 100 Takte >> in 96 Takten so ausführen, dass noch Luft für das unterbrochene Programm >> bleibt. > > 100 Takte in 96 Takten? 10 usec sind 100 kHz, nicht 10 MHz! Die ISR wird derzeit alle 10µs ausgeführt. Das sind 960 Takte. Wenn sie 10x so schnell ausgeführt werden soll, also alle 1µs, dann bleiben 96 Takte, all inclusive. Für ISR-Aktionen alle 1µs brauchst du einen völlig anderen Ansatz. Keinen Universalcontroller wie ARM, sondern eine Lösung, die für solche Zeitbedingungen gebaut ist. Wäre natürlich erst einmal die Frage, was das eigentlich werden soll. Und ob Interrupts der richtige Ansatz sind.
A. K. schrieb: > Für ISR-Aktionen alle 1µs brauchst du einen völlig anderen Ansatz. > Keinen Universalcontroller wie ARM, sondern eine Lösung, die für solche > Zeitbedingungen gebaut ist. Wäre natürlich erst einmal die Frage, was > das eigentlich werden soll. Und ob Interrupts der richtige Ansatz sind. Es soll ein PWM-signal erzeugt werden und ein paar Daten per IO rausgeschubst werden. Die 100 Taktzyklen sind dabei der worst case, d.h. egal wie oft die ISR augerufen wird, das passiert in jedem Fall nur alle 10 usec. Die Erzeugung des PWM-Singals benötigt entsprechend deutlich weniger Taktzyklen. Der Controller ist übrigens vorgegeben, den kann ich nicht mal eben so ersetzen.
Zooom schrieb: > Es soll ein PWM-signal erzeugt werden Für PWM verwendet man entsprechende Timer. > und ein paar Daten per IO rausgeschubst werden. Wertlos, weil zu unpräzise. > Der Controller ist übrigens vorgegeben, den kann ich nicht mal eben so > ersetzen. Kannst ja mal die Hausaufgabe im Original posten. ;-)
A. K. schrieb: > Kannst ja mal die Hausaufgabe im Original posten. ;-) Eine Hausaufgabe, bei der externe Hardware im Wert >10KEuro angesteuert wird. Ja. Nee. Schon klar. > Für PWM verwendet man entsprechende Timer. Sorry, aber ab da wird es einfach nur sinnloser Klugschiss: der LPC1768 hat keinen Timer, der unabhängig von der in jedem Fall zu verwendenden ISR laufen könnte. D.h. beide hängen in jedem Fall an der selben Frequenz. Und wenn der PWM-Ausgang z.B. 10 kHz liefern soll, die Datenaktualisierung innerhalb der ISR aber in jedme Fall bei 100 kHz bleiben muss - was nützt mir dann dein Timer? >> und ein paar Daten per IO rausgeschubst werden. > > Wertlos, weil zu unpräzise. Was soll ich dir dazu schreiben? Irgend welche ausufernden Details über die Hardware? Ich habe alle relevanten Informationen gegeben, es müssen im 10 usec Takt Daten per IO ausgegeben werden. Ob ich damit jetzt ein Atomkraftwerk oder eine Kaffeemaschine ansteuere, ist doch komplett irrelevant.
Zooom schrieb: > Sorry, aber ab da wird es einfach nur sinnloser Klugschiss: Woher sollte sinnvoller Klugschiss kommen, wenn du die relevanten Informationen nicht rausrückst? Mehr als allgemeine Tipps können es dann nicht werden. Und wenn man deswegen dann beschimpft wird, ... > Ich habe alle relevanten Informationen gegeben, es müssen > im 10 usec Takt Daten per IO ausgegeben werden. Das reicht nicht. Wäre nicht ganz uninteressant, ob das 1 Bit ist oder 100, parallel oder seriell, usw. Ohne solche Informationen wird das auch nur wieder sinnloser Klugschiss.
Ich kenne mich nicht mit ARMs aus. Aber es gibt Controller, die haben eine Art Event-System: Timer triggert ein DMA direkt an. Der DMA schreibt Daten aus dem SRAM auf den Port.
Schau doch wie lange Deine ISR in Wirklichkeit braucht. Die Quick&Dirty-Methode wäre am Anfang und Ende jeweils einen GPIO zu setzen/resetten und das dann auf nem Oszi anzuschauen. Du hast da natürlich etwas Ungenauigkeit drin: - Aufruf der ISR (Register sichern etc.) - GPIO setzen mit Waitstate auf den Bus - GPIO reset mit Waitstate auf den Bus - Rückkehr vom ISR zum normalen Code - Messung mit dem Oszi Aber für ne grobe Abschätzung wie lang das wirklich läuft sollte das reichen. Es gibt natürlich auch noch genauere Varianten mit Debugger, SWO etc. aber da muß man sich erst mal tief in die Doku einlesen.
Gerd E. schrieb: > Schau doch wie lange Deine ISR in Wirklichkeit braucht. Die > Quick&Dirty-Methode wäre am Anfang und Ende jeweils einen GPIO zu > setzen/resetten und das dann auf nem Oszi anzuschauen. Das ist doch mal ein echt heißer Tipp - und eigentlich so naheliegend, man muss halt nur mal drauf kommen. Dankeschön!
> Es soll ein PWM-signal erzeugt werden und ein paar Daten per IO > rausgeschubst werden. Was willst du denn da jetzt genau machen? Welche PWM-Frequenz? Welche Auflösung soll das Tastverhältnis haben? Warum müssen da schneller als mit PWM-Frequenz Daten (welche?) aktualisiert werden? Ansonsten solltest du dir mal anschauen, wie man mit dem DMA die Timer-Match-Register setzt, das soll laut Datenblatt möglich sein.
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.