mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik STM32: Timer-ISR löst 2x aus - Fehler im Flag-Reset bei Optimierung O3


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: STM32-User (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte euch ein sehr merkwürdiges Problem schildern, welches bei 
Optimierungen > O0 auftritt:

Eine Timer-ISR ist so konfiguriert, daß sie jede Millisekunde auslöst. 
Ohne Optimierung funktioniert dies wie erwartet.
Beim Optimierungslevel O3 findet eine doppelte Auslösung statt (ca 400ns 
nach der ersten)

Ich habe sehr lange gebraucht, um hierfür einen "Workaround" zu finden- 
die letzte Anweisung in der ISR ist eine "ohne effekt", die jedoch dazu 
führt, daß wieder das normale Verhalten eintritt , d.h. die ISR genau 1x 
aufgerufen wird.

Zum Nachvollziehen eine kleine STM32-Applikation, die bei jedem IRQ 
einen kurzen High-Puls am GPIO3 vollzieht,  danach das Timerflag 
rücksetzt.

Man kann mit einem Oszi 1 oder 2 Pulse sehen, wenn man mit O3 
kompiliert: - 1 pulse wenn die letzte aktion aktiv ist: "TimeTick;"  (no 
effekt statement, welches aber den 2. pulse unterdrückt)
- 2 pulse  wenn nach dem Rücksetzen des Statusregisters nichts mehr 
kommt


Hierzu habe ich 2 Fragen und würde mich freuen, wenn ein STM32 Experte 
seine Weisheit mit mir teilen würde:

1) Wodurch genau kommt der Fehler zustande - die Registerbelegungen des 
Timers ist exakt identisch.

2) Kann es sich um einen GCC Optimierungsfehler handeln?  (Timingfehler 
, ein fehlendes NOP sozusagen,  welches ich mit dem "no return 
statement" erzwinge?)
=> falls es in die Richtung geht,  verstehe ich eines nicht:
ob mit oder ohne TimeTick;  ,   die Größe des erzeugten Bin-Files ist 
identisch.   (da ich im ASM nicht soo fit bin, habe ich hier noch kein 
Vergleich durchgeführt, werde dies morgen mal genauer analysieren)


Vielen Dank im Voraus für jegliche Anregungen oder Ideen, die mich auf 
des Rätsels Lösung bringen

Anmerkung: Nutzt man die eingebaute "rücksetz-Funktion" der STM periph. 
libary, tritt dieses Verhalten ebenso nicht auf.
Da ich die Routine jedoch später im RAM laufen lassen muß, habe ich 
jegliche Flash-routinen in den RAM "portiert"  - und danach trat es 
auf..

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Update-Flag bei den STM32-Timern ist ein bisschen schräg. Verschiebe 
die Anweisung mit dem TIM_IT_Update an den Anfang der ISR. Poste auch 
mal die dissassembly der -O0 und -O3 Varianten, das ist das wichtigste 
bei Optimierer-Problemen...

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das Update-Flag bei den STM32-Timern ist ein bisschen schräg.

Man sollte die Interrupt Flags ganz am Anfang der ISR löschen.
Tut man es zu weit hinten, kann es passieren das die ISR verlassen
wird bevor das Flag wirklich zurückgesetzt wurde. Und schwupps
landet man ein zweites mal in der ISR.

Autor: STM32-User (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier nun die beiden Assembly Listings der ISR - jeweils direkt vor 
"Main" abgeschnitten..

Im direkten Vergleich bemerkt man einige unterschiede - es deutet alles 
darauf hin, daß Eure Annahme richtig war,  denn im "Workaround" ist vor 
dem Rücksprung noch ein zusätzlicher Befehl  -> damit vermutlich genug 
Zeit das Register rückzusetzen bevor der INT verlassen wird.


Eine Kleinigkeit fiel mir noch auf -  einmal ist hinter dem Rücksprung 
noch ein NOP vorhanden, ein anderes mal fehlt es.

So ganz wird mir dessen Existenzgrund nicht klar - ist dies evtl ein 
anderer "workaround" für den Kommando-Pipeliner, dessen Sequenz ja durch 
den HW-INT irgendwo unterbrochen wurde und der nun zurückspringen muß? - 
die Frage wäre nur, warum das NOP nur in einem der Fälle und nicht 
generell?!?


Vielen Dank im Voraus für eure Zeit und eure Ratschläge!

ein dankbarer STM32-User

Autor: STM32-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Euer Rat ist eindeutig Gold wert -  Sowas gehört als Warnung ganz Dick 
gedruckt ins Datenblatt :)

Danke für diesen Tipp!

Da der Thread nun eigentlich abgeschlossen ist, hätte ich eine 
philosophische Frage:

Wie wäre dieser Fehler einzuordnen -  müßte der Compiler bei 
entsprechenden Optimierungen nicht ein zusätzliches NOP zur Sicherheit 
einfügen?  (-> da es ja eindeutig nur bei best. Optimierungen auftritt)

Oder ist die Ursache eher im Silikon zu suchen,  da offensichtlich das 
Löschen des Registers und Update des Interrupt-Handlers nicht zeitgleich 
passieren, sodaß im "fehlerfall" die ISR im Anschluß direkt nochmal 
aufgerufen wird?


Euch Beiden eine angenehme Restwoche und nochmal vielen Dank für eure 
Mühe!

der immer wieder dazulernende
STM32-User

Autor: Ingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin auch auf diesen Fehler beim InputCapture gefallen, irgendwo 
stand mal genau erklärt wie der Fehler zu Stande kommt. Weiß aber nicht 
mehr wo

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM32-User schrieb im Beitrag #3372931:
> Wie wäre dieser Fehler einzuordnen -  müßte der Compiler bei
> entsprechenden Optimierungen nicht ein zusätzliches NOP zur Sicherheit
> einfügen?  (-> da es ja eindeutig nur bei best. Optimierungen auftritt)

Das ist nun aber definitiv nicht Sache des Compilers. Das ist auch kein 
Fehler, weder beim Compiler noch in der Hardware. Sondern das ist 
einfach nur etwas, auf das der Programmierer achten muss.

Wenn du AVRs kennst, dann kennst du vielleicht den Effekt, dass ein 
Input-Befehl, der unmittelbar auf einen Output-Befehl folgt, nicht 
sicher den Zustand eines dadurch geänderten Pins erfassen kann. Weil im 
Ablauf das eine oder andere taktgesteuerte Flipflop dazwischen sitzt.

> Oder ist die Ursache eher im Silikon zu suchen,  da offensichtlich das
> Löschen des Registers und Update des Interrupt-Handlers nicht zeitgleich
> passieren, sodaß im "fehlerfall" die ISR im Anschluß direkt nochmal
> aufgerufen wird?

Aufgrund des exakten Ablaufs in der Hardware ist es völlig normal, dass 
der Zustand des Interrupt-Systems ein ganz klein wenig dem vom 
Programmierer wahrgenommenen Programmablauf hinterher hinkt. ARM hatte 
beim Design der Cortex-M die Interrupt-Verarbeitung durch Prozessors 
aber sehr effizient gestaltet. Und hat damit nun manchen Programmier 
überholt. ;-)

Bei anderen Architekturen landen in Interrupt-Handlern meist noch 
diverse Befehle zwischen der letzten C Anweisung und dem Return. Dieser 
Wasserkopf in Interrupt-Handlern sorgt üblicherweise dafür, dass dein 
Problem nicht auftritt. Bei den Cortex-M gibts den aber nicht, folglich 
muss man selber ein wenig aufpassen.

: Bearbeitet durch User
Autor: STM32-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
>> Wie wäre dieser Fehler einzuordnen -  müßte der Compiler bei
>> entsprechenden Optimierungen nicht ein zusätzliches NOP zur Sicherheit
>> einfügen?  (-> da es ja eindeutig nur bei best. Optimierungen auftritt)
>
> Das ist nun aber definitiv nicht Sache des Compilers. Das ist auch kein
> Fehler, weder beim Compiler noch in der Hardware. Sondern das ist
> einfach nur etwas, auf das der Programmierer achten muss.
>
> Wenn du AVRs kennst, dann kennst du vielleicht den Effekt, dass ein
> Input-Befehl, der unmittelbar auf einen Output-Befehl folgt, nicht
> sicher den Zustand eines dadurch geänderten Pins erfassen kann. Weil im
> Ablauf das eine oder andere taktgesteuerte Flipflop dazwischen sitzt


Danke für die Einordnung -   wenn dies definitiv ein "Programmierer muß 
das Wissen"-Ding ist, dann frage ich mich, wieso dies nicht in der 
Beschreibung des Systemverhaltens (==> in der Doku/Datenblatt) 
beschrieben wird,  sondern selbst in den Beispielen oft ganz zum Schluß 
as Flag gesetzt wird, was dem Nutzer extrem schwierig zu debuggende 
Fehler unterschiebt.
Ich habe nun dazugelernt, frage mich aber wirklich, wie weit dieses 
Wissen wohl verbreitet ist  und wieviel Prozent der Projekte einfach nur 
"Glück in Ihrer Unwissenheit haben", da sie längere Funktionen am ende 
des ISRs haben.

Erlaube mir deshalb folgende Behauptung:
Wenn syntaktisch richtiger Code in einer Hochsprache übersetzt wird, 
sollte dies unabhängig von der Optimierung zu gleichem Systemverhalten 
führen.
Ist diese Annahme etwa zu naiv?

Gibt es einen allgemeingültigen "Sicheren Weg"/Tutorial/Guideline, 
solche Probleme zu vermeiden?

(diesmal trat der fehler am Anfang der Entwicklung auf, es war daher 
noch halbwegs übersichtlich. Tritt soetwas später und sporadisch auf, 
ist das u.U. Projektgefährdend, da man irsinnig viel Zeit darauf 
verwendet bis man einen solchen Fehler überhaupt reproduzierbar und 
damit analysierbar kriegt.)


Die "IO-Problematik" bei AVRs kenne ich, stufte sie jedoch als absolut 
irrelevant ein, da meiner Ansicht nach keine Notwendigkeit besteht, 
sofort nach dem setzen eines Outputs Pins dessen input-register zu 
lesen:
1. I.D.R hat man den outputwert ohnehin in irgendeiner Variablen
2. kann man ja auch das output register nehmen, welches (sofern mich 
meine Erinnerung nicht täuscht) immer den korrekten Wert enthält

Für mein Verständnis sind es 2 paar Schuhe, ob ein IO regelmäßig falsch 
gelesen wird oder eine Interuptroutine ohne erkennbaren und debugbaren 
Grund 2x hintereinander ausgeführt wird.
Ohne ein schnelles Oszi und einige Stunden Sucherei ist der Fehler IMHO 
gar nicht zu finden, (sofern er einen ohne das nötige Vorwissen ereilt)

Durch Eure Beiträge habe ich nun wieder etwas dazugelernt  und stehe 
deshalb tief in Eurer Schuld - vielen Dank!


Über jegliche Tipps, wie ich (und jeder spätere Leser dieses Threads) 
solche oder ähnliche Fallstricke gezielt vermeiden kann, würde ich mich 
natürlich sehr freuen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM32-User schrieb im Beitrag #3373167:
> Wenn syntaktisch richtiger Code in einer Hochsprache übersetzt wird,
> sollte dies unabhängig von der Optimierung zu gleichem Systemverhalten
> führen. Ist diese Annahme etwa zu naiv?

Nur bezogen auf jene Aspekte, die zur Sprache C gehören. Das 
Laufzeitverhalten von Interrupt-Systemen oder I/O-Bausteinen in den 
erzeugten Code einzubeziehen ist jedoch eindeutig nicht Sache des 
Compilers.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM32-User schrieb im Beitrag #3373167:
> Die "IO-Problematik" bei AVRs kenne ich, stufte sie jedoch als absolut
> irrelevant ein, da meiner Ansicht nach keine Notwendigkeit besteht,
> sofort nach dem setzen eines Outputs Pins dessen input-register zu
> lesen:

Das ist ziemlich direkt zur hiesigen Situation vergleichbar. Es wird ein 
Bit in einer I/O-Komponente zurückgesetzt, nämlich die Interrupt-Leitung 
des Timers, und anschliessend über den Interrupt-Controller vom 
Prozessor als Teil des Return-Befehls wieder ausgelesen.

Ein Beispiel, wo eine solche Sequenz bei AVRs leicht vorkommen kann, ist 
die Abfrage einer Tastaturmatrix. Es muss ja nicht das gleiche Portbit 
sein, um das es geht. Wenn man da nicht explizit ein NOP einschiebt, 
dann kriegt man bei den ATmegas Probleme, die man bei den alten 
AT890Sxxxx mangels Sync-Register am Eingang nicht hatte. Sollte avr-gcc 
vor jeden Lesebefehl ein NOP einschieben?

PS: Der ARM Compiler weiss bei den Cortex-M überhaupt nicht, ob er es 
mit einer Interrupt-Routine zu tun hat oder mit einer normalen Funktion. 
Anders als bei anderen Architekturen üblich sind die aus dessen Sicht 
identisch.

: Bearbeitet durch User
Autor: STM32-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK - wenn dem so ist, dann bin ich wohl dem falschen Pferd aufgesessen, 
daß sich der Compiler für eine bestimmte Hardwarearchitektur drum 
kümmern sollte

(könnte ich dies entscheiden, würde ich es definitiv als "must have" für 
alle Compiler festlegen - warum? Effizienz, Robustheit, standardisiertes 
Verhalten - eben die gründe, für die man eine Hochsprache i.d.R 
einsetzt)

gibt es sowas wie eine Wissensdatenbank ala "für Proz.X  füge n 
waitstates ein oder mache es am besten so... , für Proz.Y  ists egal..." 
?


OT: manchmal wünsche ich mir die gute alte AVR-Assembler Zeit zurück...
Ok, die programme von damals hatten weniger Funktionalität, doch ob Ihr 
es glaubt oder nicht, damals dauerte es zwar etwas länger bis ein 
Programm fertig war, dafür hatte es aber auch WESENTLICH weniger Fehler 
und lief ungleich Stabiler.

Autor: STM32-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kleine Anmerkung:  ob ISR oder nicht müßte der Compiler herauskriegen 
können.
OK - nennen wir es nicht Compiler, nennen wir es "Präprozessor ähnlicher 
Optimierer / graue Haare Verhinderer" :)

Danke für Deine Ausführung. Verstehe jetzt was Du meinst,  überlege mir 
nur gerade, wie man soetwas durch standardisierte Prozesse in einem 
Unternehmen verhindern könnte..

Autor: obscurity (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM32-User schrieb im Beitrag #3373167:
> Erlaube mir deshalb folgende Behauptung:
> Wenn syntaktisch richtiger Code in einer Hochsprache übersetzt wird,
> sollte dies unabhängig von der Optimierung zu gleichem Systemverhalten
> führen.
> Ist diese Annahme etwa zu naiv?

Ja, das ist absolut zu naiv. Die Interruptflags gehören zum Registersatz 
der Peripherie und nicht zum Cortex-Kern. Wie schnell die über die 
internen Busse angebunden sind kann der Compiler nicht wissen. Wenn das 
Zeitverhalten bei allen Optimierungsstufen gleich wäre, wozu wird da 
überhaupt optimiert? Also das Verhalten was du hier erlebt hast wurde 
hier schon beschrieben. Irgendwann fällt jeder mal auf sowas rein.
Man muss bei den Cortexen immer im Hinterkopf haben, dass die gesamte 
Peripherie über die AHB-Busse angebunden ist. Teilweise kann deren 
Taktrate auch noch deutlich nach unten geschraubt werden. Das würde die 
Effekte noch verstärken. Eventuell kannst du ja das Register nochmal 
lesen nach dem Schreiben. Ich denke an der Stelle wartet dann die CPU 
bis das Register gelesen ist. Das muss man dann aber auch so geschickt 
machen dass der Compiler das nicht wegoptimiert.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM32-User schrieb im Beitrag #3373206:
> Kleine Anmerkung:  ob ISR oder nicht müßte der Compiler herauskriegen
> können.

Bei klassischen ARMs ist das so, weil ISRs einen gänzlich anderen 
Wasserkopf haben als normale Funktionen. Nicht aber bei den Cortex-M.

> OK - nennen wir es nicht Compiler, nennen wir es "Präprozessor ähnlicher
> Optimierer / graue Haare Verhinderer" :)

Ja, den Do-What-I-Mean-Not-What-I-Say Compiler hätten viele gerne. C ist 
halt seit jeher andersrum konzipiert. :-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
obscurity schrieb:
> Das muss man dann aber auch so geschickt
> machen dass der Compiler das nicht wegoptimiert.

Wird er nicht, weil volatile. Der Prozessor auch nicht, weil in einem 
Adressraum mit klarer Zugriffsreihenfolge (memory ordering).

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
obscurity schrieb:
> Man muss bei den Cortexen immer im Hinterkopf haben, dass die gesamte
> Peripherie über die AHB-Busse angebunden ist.

Eher die APB Busse. Der AHB ist der schnelle vorne, die oft mehreren 
APBs sind die teils langsameren weiter draussen.

Autor: obscurity (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Ja, den Do-What-I-Mean-Not-What-I-Say Compiler hätten viele gerne. C ist
> halt seit jeher andersrum konzipiert. :-)

Ich frage mich was das mit C und dem Compiler zu tun hat. Das selbe 
würde dir im Assembler passieren. Der Hersteller der CPU und nicht ARM 
steht vor der Entscheidung ob immer und überall oder nur bei bestimmten 
Registern Waitstates eingeschoben werden bis zum wirklichen Updates der 
Register. Hat er in deinem Fall aber nicht. Das würde ja auch die eine 
oder andere Benchmarkzahl verschlechtern und das ist ein NoGo. Sicher 
wird das auch in 99,9..% nicht benötigt. Und der Rest fällt einmal 
darauf rein und dann nie wieder.
Der Compiler weiss weder ob dein Programm im Flash oder im Ram läuft und 
ob du die Vektoren zur Laufzeit änderst oder nicht. An was soll er das 
denn festmachen? Und soll er jedesmal 10ms Waitstates als Vorsorge 
einschieben nur weil einer auf die Idee kommen könnte den AHB-Takt auf 
10khz zu drehen um Strom zu sparen?

Autor: obscurity (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Eher die APB Busse. Der AHB ist der schnelle vorne, die oft mehreren
> APBs sind die teils langsameren weiter draussen.

Ja klar. Wenn man es genau nimmt hast du natürlich Recht. Ändert aber 
nichts an der Tatsache, dass vom Setzten eines Registers in der CPU bis 
zu dem Zeitpunkt an dem das Register wirklich gesetzt ist immer eine 
Zeit x vergeht die der Compiler nicht kalkulieren kann.

A. K. schrieb:
> Wird er nicht, weil volatile. Der Prozessor auch nicht, weil in einem
> Adressraum mit klarer Zugriffsreihenfolge (memory ordering).

Wenn es so ist, dann ist es ja gut. Ich wollte mich hier nicht soweit 
aus dem Fenster lehnen und das ungetestet für alle Optimierungen zu 
behaupten. Fakt ist, bei mir hat das nachträgliche Lesen des Registers 
geholfen. Ob es aber nur an der zusätzlichen Zeit des Befehls lag oder 
ob da Waitstates eingeschoben werden kann ich nicht mit Gewissheit 
sagen.

Autor: STM32-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
>> Kleine Anmerkung:  ob ISR oder nicht müßte der Compiler herauskriegen
>> können.
>
> Bei klassischen ARMs ist das so, weil ISRs einen gänzlich anderen
> Wasserkopf haben als normale Funktionen. Nicht aber bei den Cortex-M.

Achso? - Ich dachte durch die ISR Sprungtabelle, die ja direkt auf die 
betreffenden Kandidaten zeigt, kriegt ein Compiler dies raus...
Aber ich kenne mich zu wenig mit den Internas der Compiler aus - 
vermutlich wäre dies zu hardwarespezifisch oder zu komplex, auf einzelne 
Register-setzen Befehle zu schauen (ISR-Tabellen-Vektor ist ja im 
Register gehalten und könnte sich gemeinerweise noch zur Laufzeit 
ändern)..

So langsam ergibt alles einen Sinn :)

Der Traum vom "do what I mean not what I say" compiler ist leider viel 
zu schön um wahr zu sein :)..

Als Alter Realist wäre ich trotzdem wenigstens für ein "behave like I 
said" (without assuming I have in depth hardware timing knowledge) 
compiler.
Vermutlich gibt es die sogar für teuer Geld von Keil&Co zu kaufen..

Schön, hier ein Forum zu haben, in dem es nach wie vor konstruktive 
Leute mit Ahnung gibt.

OT: mal eine Frage -  wie haltet ihr es eigentlich aus, bei dauerhaft 
">20 Einträge pro Tag" die sinnvollen herauszufiltern und diese auch 
noch kompetent zu beantworten?

Ich würde vermutlich nach einigen Wochen einfach keinen Bock mehr auf 
das zehntausendste "welcher 8 bitter ist von allen der beste" Themen 
haben,  wohingegen eine (1!) Übersicht über Eignung und Anwendungsfälle, 
gegenübergestellte Vor- und Nachteile ohne Frage äußerst interessant 
wäre.


Also vor eurer Einstellung und euer Durchhaltevermögen empfinde ich 
wirklich tiefen Respekt - Hut ab!!

Autor: STM32-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
obscurity schrieb:
> Ja, das ist absolut zu naiv. Die Interruptflags gehören zum Registersatz
> der Peripherie und nicht zum Cortex-Kern. Wie schnell die über die
> internen Busse angebunden sind kann der Compiler nicht wissen. Wenn das
> Zeitverhalten bei allen Optimierungsstufen gleich wäre, wozu wird da
> überhaupt optimiert?

Danke für den Hinweis - jetzt weiß ich wenigstens woher die Probleme 
kommen
Ich dachte, da der NVIC doch jetzt angeblich im Kern integriert wäre, 
würden das Rücksetzen der ISR-Flags in der ISR schon via Hardware so 
synchronisiert sein, daß der (viel zu schnelle kern) nicht gleich 2x 
auslöst..

Ich muß zugeben, daß ich an eine zu langsame Synchronisierung von 
Peripherie-Status-Registern" überhaupt nicht gedacht habe -  ging 
blauäugig davon aus, daß diese intern synchronisiert werden "bevor 
irgendwas böses passiert"
-> dafür hat mir meine Applikation halt auch ein blaues Auge verpaßt :)

Ich finde allerdings, daß diese Info in den Peripheriebeschreibungen 
fehlt- es ist einfach nicht oder wenn dann äußerst unzureichend erwähnt.
Beispielsweise eine Berechnung, wieviele Waitstates eingefügt werden 
müssen wenn CPUTakt X  und Peripherietakt Y ist.
Gibt es soetwas für STM32?   - habe dergleichen noch nicht gesehen..

Wäre ja nötig um sicherzugehen, daß auch in zukünftigem Code (ggf. bei 
veränderter Taktrate) alles sauber läuft.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM32-User schrieb im Beitrag #3373298:
> Achso? - Ich dachte durch die ISR Sprungtabelle, die ja direkt auf die
> betreffenden Kandidaten zeigt, kriegt ein Compiler dies raus...

Du solltest mal versuchen, die Ebenen von Compiler und Maschine 
auseinander zu halten. Nicht jedes Array mit Zeigern auf Funktionen drin 
ist eine ISR-Sprungleiste.

> Aber ich kenne mich zu wenig mit den Internas der Compiler aus -
> vermutlich wäre dies zu hardwarespezifisch oder zu komplex, auf einzelne
> Register-setzen Befehle zu schauen (ISR-Tabellen-Vektor ist ja im
> Register gehalten und könnte sich gemeinerweise noch zur Laufzeit
> ändern)..

Das kann man wohl sagen. Es hätte beispielsweise zur Folge, dass man für 
jedes neue Registerbit eine neue Compilerversion bräuchte. Ein Alptraum.

> Vermutlich gibt es die sogar für teuer Geld von Keil&Co zu kaufen..

Woh kaum. Mit etwas Glück hast du bessere Doku und eine Liste gängiger 
Fallstricke. C ist nach dem Motto "Schrott rein, Schrott raus" gebaut. 
Egal ob GNU oder Keil.

> OT: mal eine Frage -  wie haltet ihr es eigentlich aus, bei dauerhaft
> ">20 Einträge pro Tag" die sinnvollen herauszufiltern und diese auch
> noch kompetent zu beantworten?

Indem man sich über die anderen Fälle lustig macht. Ok, das sehen diese 
Leute dann nicht immer so positiv. ;-)

Autor: Ralf G. (ralg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Das
> Laufzeitverhalten von Interrupt-Systemen oder I/O-Bausteinen in den
> erzeugten Code einzubeziehen ist jedoch eindeutig nicht Sache des
> Compilers.

Oder vielleicht doch? Z.B. AVR: Die Assembler-Instruktion 'sei' wird vor 
einem letzten 'pop' eingefügt.

Autor: STM32-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
beim AVR wurden die "Peripherie-Stati" (die ja angenehmerweise im Kern 
waren) automatisch zurückgesetzt.

- schön robust,  gut durchdacht und ne Runde Sache meiner Meinung nach.

Wird echt zeit, daß Atmel oder irgendwer sonst mal wieder was nachlegt 
in dieser Richtung :)

Autor: STM32-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das "unschönste" am AVR waren immernoch die Klimmzüge, mit denen man im 
Programm Konstante Daten aus dem Flash laden mußte und die Tatsache, daß 
kein Code aus externem Speicher ausgeführt werden konnte.

(unschön in dem Sinne nur deshalb, weil progmem eben 
Architekturspezifisch war und nicht mit einem "quasi-standard" zugriff 
via const char * ptr  ging.. )
Somit war der ganze mit progmem durchsetzte Code nicht mehr so einfach 
portierbar...

Autor: STM32-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf G. schrieb:
> Oder vielleicht doch? Z.B. AVR: Die Assembler-Instruktion 'sei' wird vor
> einem letzten 'pop' eingefügt.

also würde in folgendem Code automatisch die Interrupts aktiviert 
werden?
das wäre ja der Tod für jede größere ISR, da diese dann vorzeitig durch 
andere interrupts unterbrochen werden könnte..

Woher hast du diese Info -  oder habe ich etwas falsch verstanden?!?



....
cli

push R16

nop

pop R16

....

INTs nun aktiv  ohne SEI ?

Autor: Ralf G. (ralg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM32-User schrieb im Beitrag #3373362:
> das wäre ja der Tod für jede größere ISR
nee, nee.

Meine Aussage bezog sich nur darauf, dass der Compiler sich nicht um 
Hardware-Eigenheiten kümmert.

Der konkrete Sachverhalt wurde in einem älteren Thread mal erklärt. In 
einem Programm von mir ist mir das mal aufgefallen. Ich weiss nicht mehr 
in welchem Programm und in welchem Zusammenhang. Ich suche noch...

Ich glaube, mir fällt langsam wieder ein, was da gemacht wurde: Die 
Wiederherstellung von SREG wurde um einen Befehl vorgezogen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf G. schrieb:
> Oder vielleicht doch? Z.B. AVR: Die Assembler-Instruktion 'sei' wird vor
> einem letzten 'pop' eingefügt.

Das Laufzeitverhalten des Prozessors selbst wird schon eingerechnet, so 
wie es der Befehlsreferenz dokumentiert ist. Nicht Bestandteil davon ist 
aber die Peripherie, wie NVIC, Timer etc.

Teil des dokumentierten Verhaltens ist, dass die ISR-Return Operation, 
also ein BR LR mit entsprechender Pseudoadresse, anfangs den Zustand des 
Interrupt-Requests abfragt, um daraus die optimierte Abarbeitung 
weiterer Interrupts abzuleiten.

Irgendwelche Kopplungen zwischen Timer- oder NVIC-Registern und dem am 
Core auflaufenden Interrupt-Signal gehören aber ebenso wenig dazu, wie 
das exakte Zeitverhalten der von ST, TI oder NXP implementierten 
Busssysteme.

Compiler sind Werkzeuge. Wie eine Axt. Es wäre wohl vermessen, den 
Hersteller der Axt zu beauftragen, nur Axte erzustellen, die garantiert 
keinen Finger abhacken können. Du musst schon selbst drauf achten, dass 
keiner im Weg ist.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM32-User schrieb im Beitrag #3373362:
> also würde in folgendem Code automatisch die Interrupts aktiviert
> werden?

In eine ISR gehört kein SEI, es sein denn man will Schachtelung 
erlauben.

Was vmtl. gemeint war: Der AVR Compiler erzeugt als Teil des Wasserkopfs 
von Funktionen Code, der einen 16-Bit Stackpointer atomar ändert. Das 
geht nur bei abgeschalteten Interrupts. Und darin findet SEI genau vor 
dem letzten relevanten Befehl statt, was schon manche irritiert hat. Nur 
wird bei bisher abgeschalteten Interrupts der Folgebefehl von SEI 
immer direkt anschliessend ausgeführt.

Damit wird also eine bestimmte Eigenschaft des Prozessorkerns 
ausgenutzt, um die Interrupt-Latenz zu minimieren.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf G. schrieb:
> Meine Aussage bezog sich nur darauf, dass der Compiler sich nicht um
> Hardware-Eigenheiten kümmert.

Wenn du mit Mehrkern- und Mehrprozessorsystemen arbeitest, wie in 
heutigen PCs oder Handys, und ein Programm mit mehreren Threads laufen 
lässt, dann kriegst du je nach Prozessor und Problem noch ganz andere 
Schweinereien auf den Tisch.

Dann musst du nämlich bei Nutzung gemeinsamer Variablen u.U. auch noch 
selber drauf achten, dass diese Variablen in der richtigen Reihenfolge 
im Speicher landen, weil sich das nicht nur durch Optimierung des 
Compilers, sondern auch durch Optimierung innerhalb Prozessors anders 
darstellen kann, als es aus dem C Quellcode ersichtlich ist.

Dann kann es sein, dass du manchen Code mit Memory-Barrier Befehlen 
spicken musst, um diese Reihenfolge sauber zu ordnen. Auch das nimmt 
einem der Compiler nicht ab. Weil sich der nicht um Code kümmert, den er 
nicht wahrnimmt.

Den Optimierungs-Effekt der Hardware kannst du aber auch bei den 
Cortexe-Ms erleben, zumindest theoretisch. Wenn du nämlich Daten ins RAM 
schreibst, die anschliessend vom DMA Controller verwendet werden. Selbst 
wenn du diese Daten als volatile deklarierst, ist dennoch je nach 
Adressraumkonfiguration ohne entsprechenden Barrier-Befehl nicht völlig 
gesichert, dass sie im RAM gelandet sind bevor der DMA Controller sie 
dort rausfischt.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM32-User schrieb:
> dann frage ich mich, wieso dies nicht in der
> Beschreibung des Systemverhaltens (==> in der Doku/Datenblatt)
> beschrieben wird
Weil die Doku ST-Qualität hat. Schau mal 
STM32: Errata vom STM32F4xx die nicht im Errata von ST stehen und 
http://www.efton.sk/STM32/STM32F4xx_doc_errors.txt
Bei der Programmierung mit den STM32 stößt man leider ständig auf 
fehlende/falsche/unzureichende Angaben in der Doku, da muss man sich mit 
abfinden...

Und ich gebe meinen Vorrednern definitiv Recht, dass das einfügen von 
Waitstates hier nicht Aufgabe des Compilers ist; bei richtigen™ 
Compilern wie dem GCC ist zB die ISR einfach nur ein Array an 
Funktionspointern das per Linkerscript an die richtige Stelle gepackt 
wird, eine ISR eine ordinäre C-Funktion, ein Hardware-Register einfach 
nur eine Speicherstelle - der Compiler stellt einen Satz von Werkzeugen 
bereit, mit denen man sich eine Anwendung zusammenbauen kann. Von der 
Struktur des Ergebnisses weiß der Compiler nichts. Daher kann der 
Compiler für eine Vielzahl an Controllern mit unterschiedlicher 
Hardware, in verschiedenen Konfigurationen (Bootloader, RAM, Flash...) 
benutzt werden. Hier passt es nicht hinein, dass der Compiler bestimmte 
Register "erkennt" und für die anderen Code generiert. C/C++ ist eben 
kein Rundum-Sorglos-Paket, und das ist auch gut so. Wenn du das willst 
schau dir mal http://www.stm32java.com/ an ...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM32-User schrieb im Beitrag #3373350:
> beim AVR wurden die "Peripherie-Stati" (die ja angenehmerweise im Kern
> waren) automatisch zurückgesetzt.

Bei Baukastensystemen ist das wenig wahrscheinlich. Alle Microcontroller 
auf ARM Basis sind genau das (ebenso PIC32 auf MIPS Basis). Der 
Hersteller kombiniert einen eingekauften ARM Core mit allerlei 
Peripherie-Modulen, die entweder er selbst entwickelte, oder wiederum 
irgendwo einkaufte. Systeme aus einem Guss sind da nicht zu erwarten.

Autor: STM32-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut, damit wäre das Problem eindeutig beim Hersteller des Chips zu 
suchen - bzw. in dessen lausiger Art das Systemverhalten zu 
dokumentieren.

Durch die immer schneller werdenden Produktzyklen hold man sich 
automatisch als Kunde immer mehr Kinderkrankheiten ins Haus.


Ich Danke euch für eure Einschätzung und daß ihr meine Fehleinschätzung 
"der compiler müßte es machen" korrigiert habt.

Damit rettet ihr mir - und hoffentlich vielen anderen Lesern dieses 
Threads einige der kostbaren Finger.

Euch einen angenehmen Abend
STM32-User

ps:
wie gut daß es Backups gibt- sonst müßte ich diesen Beitrag vermutlich 
mit der Nase verfassen - und selbst die wäre...  Autsch :)

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM32-User schrieb im Beitrag #3373167:
> Die "IO-Problematik" bei AVRs kenne ich

Und sie ist auch im Datenblatt eindeutig dokumentiert:

"When reading back a software assigned pin value, a nop instruction must 
be inserted as indicated in Figure 10-4 on page 51. The out instruction 
sets the “SYNC LATCH” signal at the positive edge of the clock. In this 
case, the delay tpd through the synchronizer is one system clock 
period."

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.