Hallo,
ich versuche grade, mit GCC ein kleines Programm für ARM (LPC2378) zu
compilieren.
Das Programm verfügt über eine Interruptfunktion namens tick, die von
einem Timer (Timer0) periodisch alle 1 ms aufgerufen wird.
So, der Interrupt und der Timer funktionieren föllig einwandfrei.
Jetzt möchte ich aber aus der Interruptfunktion heraus (also aus tick)
eine andere Funktion aufrufen.
etwa so:
void tick(void) _attribute_ ((interrupt("FIQ")));
void tick(void)
{
fTickHandler();
T0IR = 0xFF;
VICAddress = 0;
}
Das ganze funktioniert, aber nur, wenn ich es im RAM ausführe. Sobald
ich es ins Flash lade, geht mein ganzes Programm nicht mehr.
Der GCC gibt auf jeden Fall eine Warnung aus:
Warning: writeback of base register is UNPREDICTABLE
Frage:
Was bedeutet das? Wie kann ich es beheben? Und warum funktioniert mein
Programm nicht, obwohl es eigentlich einwandfrei ist?
Ich hoffe ihr könnt mir helfen.
Vielen Dank schon mal im Voraus!
PS:
Ach ja, mir fällt noch was ein.
Ich hatte (von einem früheren Experiment her) mal versehentlich folgende
Code-Zeile stehen lassen:
void tick(void) _attribute_ ((interrupt("FIQ")));
anstatt
void tick(void) _attribute_ ((interrupt("IRQ")));
Das Programm hat aber in beiden Fällen funktioniert. Warum?
Das habe ich schon gefunden.
Das Problem wird aber nicht behoben, wenn die die Optimierung auf "none"
umstelle. Dann läuft das Programm ebenfalls nicht.
Was ich mich aber frage - wie dumm ist der GCC denn, dass er aus einem
Interrupt heraus keine andere Funktion aufrufen kann? das ist ja
verdammt bitter.
Der Startup-Code ist nicht von mir:
vectors: ldr PC, Reset_Addr
ldr PC, Undef_Addr
ldr PC, SWI_Addr
ldr PC, PAbt_Addr
ldr PC, DAbt_Addr
nop /* Reserved Vector */
ldr PC, IRQ_Addr
ldr PC, FIQ_Addr
Reset_Addr: .word Reset_Handler /* defined in this module below
*/
Undef_Addr: .word UNDEF_Routine /* defined in irq.c */
SWI_Addr: .word SWI_Routine /* defined in irq.c */
PAbt_Addr: .word PAbt_Routine /* defined in irq.c */
DAbt_Addr: .word DAbt_Routine /* defined in irq.c */
IRQ_Addr: .word IRQ_Routine /* defined in irq.c */
FIQ_Addr: .word FIQ_Routine /* defined in irq.c */
Das ganze ist wegen der eigentlich unnötigen Sprüngen zu Beginn eines
IRQ nicht umbedingt optimal, allerdings hatte ich bisher weder mit
Funktionsaufrufen noch mit Optimierungen Probleme.
Allerdings hat mein uC keinen VIC, einige Dinge werden also anderst als
bei dir sein.
@Tilo
danke, ich versuche es mal auf die Art wie du das machst.
Mal schauen, ob das Abhilfe bringt :-)
Wenns keine Möglichkeit gäbe, aus einer Interruptfunktion eine beliebige
sonstige Funktion aufzurufen, dann wäre das ziemlich sch..... schade.
Ich muss im Timerinterrupt einen Haufen Sachen erledigen, es wäre
ziemlich unübersichtlich (und wegen Modularität auch nicht gut) den
ganzen Code in den Timerinterrupt rein zu packen.
Hat sonst noch niemand das Problem gehabt? :o Bin ich der einzige, der
im Interrupt eine Funktion aufrufen will?
Nein, bist du nicht. Aber vielleicht der einzige bei dem dieses Problem
auftritt.
Wobei ich jedoch bei den ARMs einen zentralen Interrupt-Dispatcher
verwende. Der IRQ landet in einer Assembler-Funktion, die die Register
sichert, zur Unterstützung von verschachtelten Interrupts den Modus
wechselt und dann als Handler über denn VIC-Vektor eine normale C
Funktion aufruft. Die deshalb ggf. auch in Thumb codiert sein kann. Da
kann das Problem nicht auftreten.
@A.K.:
Kann man sich deinen Startup-Code mit diesen Handlern einmal ansehen?
Bei mir ist einfach eine normale Vector-Tabelle, in dem Stil
vectors:
b reset
b undef
b swi
b pabort
b dabort
nop /* bootloader checksum */
ldr pc, [pc, #-0x120]
b fiq
im reset-Handler wird dann für jeden Modus der Stackpointer
initialisiert, also undef, user, supervisor und so weiter. Nachher kommt
ein
b main
Danke A.K.
Ich schaue mir das jetz noch ein paar mal an; ich blicke nämlich
überhaupt nicht durch bei dem Code.
Aber einfach copy & paste möchte ich nicht machen, ich will meinen
Startup-Code schon selber schreiben, damit ich genau weiss, was abgeht.
Wozu muss man überhaupt die IRQ-Funktionen markieren?
Ist dies dafür notwendig, damit der Compiler weiß, welche Register zur
Verfügung stehen? Die belegten Register werden im Startup-Code von Hand
freigeräumt, daran kann es also nicht liegen.
@Tilo
> Wozu muss man überhaupt die IRQ-Funktionen markieren?
Damit der Compiler weiss, dass er nun alle Register sichern muss. Und
> damit der Compiler weiß, welche Register zur Verfügung stehen
Und genau bei diesem Prolog/Epilog-Code liegt beim GCC für ARM der Hase
im Pfeffer. Ich haben mir den mal angesehen und es wundert mich
eigentlich nur, dass da nicht öfter Mist gebaut wird. Wirkt sehr
historisch gewachsen und eine Erweiterung stapelt sich über die andere.
Ich habe den Eindruck, dass sich da keiner so recht heran traut.
Tilo schrieb:
> Wozu muss man überhaupt die IRQ-Funktionen markieren?
Ohne einen solchen IRQ-Wrapper im Startup-Code muss man das. Denn dann
wird der Handler ziemlich direkt aus der Vektorleiste heraus
angesprungen.
A.K,
ich habe da auch mal eine Frage bez¨glich des Startup-Code.
Ich habe hier einiges mitgelesen und das auch auf meinen Code adaptiert,
funktioniert alles bestens. Das einzige, was ich bisher weggelassen
hatte, war diese Kopiererei ("Copy initialized data to its execution
address in RAM") vom Flash ins RAM, weil mir nicht klar war wozu die gut
sein sollte.
Danach hatte ich einige Probleme mit Variablen, die als static
deklariert waren. Nach einfügen der Kopierfunktionen hat dann auch das
geklappt.
Nun habe ich nur noch ein Problem. Und zwar wollte ich einen wirklich
universellen Startup-Code bauen, der alles nötige initialisiert, sodass
man auch mit C++ programmieren könnte (wenn man das denn wollte). Also
muss ich vor dem main-Aufruf noch die C++ Konstruktoren aufrufen, und
nach dem Beenden von main (was zwar nicht vorkommt, aber der
vollständigkeit halber) die Destruktoren.
Soweit so gut; doch nachdem ich nun diesen Code noch eingefügt habe, der
die Konstruktoren aufruft, kommt es in anderen Programmteilen zu
sporadischen Abstürzen. Es ist reproduzierbar, tritt aber
interessanterweise nur auf, wenn die Konstruktoren vorher aufgerufen
wurden; ansonsten nicht. Was ich noch erwähnen sollte ist, dass in
meinem Testprogramm C und C++ vermischt sind - C++ geht jetzt, dafür C
nicht mehr ganz richtig. Wenn mehrere Funktionen ineinander
verschachtelt sind und Rückgabewerte zurückgeben sollen, dann geht das
nur bis zu einer bestimmten Tiefe, dann stürzt der Rechner ab, ich kann
mir aber nicht erklären wieso.
Könntest du bitte meinen Code anschauen, und mir sagen, ob es an dem
liegt? Wär super toll.
Gruss
Tobias
