Forum: Compiler & IDEs AVR Nicht-Atomares Fehlverhalten in flagrante ertappt


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.
von Gerhard O. (gerhard_)


Bewertung
0 lesenswert
nicht lesenswert
AVR Nicht-Atomares Fehlverhalten in flagrante ertappt!

Falls es Euch am Rande interessiert berichte ich hier im Zusammenhang 
auf den Wert oder Unwert vom atomaren Zugriff mit einem kleinen 
Experiment:

Zur Zeit läuft mein neuer pneumatische Füllstandmesser im Dauerbetrieb 
im Arbeitsraum wo ich ihn ständig beobachten kann.

Wie in meinem anderen Thread 
(Beitrag "Ein Füllstandmesser auf Einperlungsbasis") zu lesen ist 
werkelt dort ein AVR auf einer NANO Bord. Der ADC läuft in einer ISR um 
automatisch sechs Analog Kanäle regelmäßig zu messen und dann in einen 
globalen 16-bit Array live abzuspeichern. Grundsätzlich greife ich auf 
solche Daten außerhalb der ADC-ISR atomar zu.

Im normalen Betrieb wird der MPXV4006 Sensor periodisch ständig 
überwacht um gefährlichen möglichen Überdruck rechtzeitig zu erfassen 
und in so einem Fall das Messsystem umgehend belüften zu können um den 
Sensor nicht zu überlasten und möglicherweise zu zerstören weil die 
Pumpe den maximal zulässigen Sensor Überdruckwert fast um das dreifache 
übersteigen fähig ist.

Dann habe ich aus Neugierde absichtlich den atomaren Zugriff im Alarm 
Code auskommentiert um das so modifizierte Messgerät auf längere Zeit 
beobachten zu können. Nach einigen zig Stunden ununterbrochenen Betriebs 
war es dann so weit: Der Überdruckalarm wurde trotz normaler 
Referenzdruckverhältnisse plötzlich aktiviert und ein völlig 
uncharakteristischer extrem hoher ADC Wert (~27K) wurde zum Beweis am 
Terminal ausgelesen. (Normalerweise sind ADC Werte ja nur im Bereich 
0-1023) Nach Wiederaktivierung des atomaren Zugriffs lief alles wieder 
dauerhaft (7 Tage+) störungsfrei und es gab bis jetzt noch keine 
Wiederholung dieses Phänomen.

: Bearbeitet durch User
von foobar (Gast)


Bewertung
3 lesenswert
nicht lesenswert
> wurde [...] ein extrem hoher ADC Wert (~27K) [...] ausgelesen.
< (Normalerweise sind ADC Werte ja nur im Bereich 0-1023)

Das klingt aber nicht nach einem typischen Fehler durch nichtatomares 
Lesen.

Durch das nichtatomare Lesen eines 16-Bit-Wertes wird das Low-Byte eines 
Meßwertes und das High-Bytes des folgenden zusammengemanscht (oder 
umgekehrt).  Das kann aber nicht dazu führen, dass das High-Byte auf 
einmal einen Wert hat, der bei Messungen nie vorkommt.

von Gerhard O. (gerhard_)


Bewertung
1 lesenswert
nicht lesenswert
foobar schrieb:
>> wurde [...] ein extrem hoher ADC Wert (~27K) [...] ausgelesen.
> < (Normalerweise sind ADC Werte ja nur im Bereich 0-1023)
>
> Das klingt aber nicht nach einem typischen Fehler durch nichtatomares
> Lesen.
>
> Durch das nichtatomare Lesen eines 16-Bit-Wertes wird das Low-Byte eines
> Meßwertes und das High-Bytes des folgenden zusammengemanscht (oder
> umgekehrt).  Das kann aber nicht dazu führen, dass das High-Byte auf
> einmal einen Wert hat, der bei Messungen nie vorkommt.

Das hört sich plausibel an. Dann muß irgend etwas anderes passiert sein. 
In der ADC-ISR werden die Messungen alle noch gemittelt bevor sie im 
Array geschrieben werden, erklärt aber nicht was da bei mir passiert 
ist. Innerhalb der ISR sollte nichts passieren können. Allerdings laufen 
da noch TIMER 0 und 2 ISRs. Ich werde es noch einmal probieren um 
herauszufinden ob sich der Fehler reproduzieren läßt. Danke jedenfalls 
meine "Voreiligkeit" zu kritisieren;-)

von oweiowei (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> AVR Nicht-Atomares Fehlverhalten in flagrante ertappt!

Das klingt sehr danach dass du hoch über den Dingen stehst und
soeben einen Design-Fehler der Atmel Entwickler gefunden hast.

Sozusagen das Pendant zu "ich habe einen Compiler Bug gefunden".

Na dann, grossen Respekt vor deinen hohen Künsten. Die Atmel
Entwickler bei Microchip werden dir ein Denkmal setzen. Aber
melden musst du dich schon selbst bei denen, sonst wird das nix.

von oweiowei (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Wie in meinem anderen Thread
> (Beitrag "Ein Füllstandmesser auf Einperlungsbasis") zu lesen ist

Wenn ich mir auf den Bildern anschaue wie nahe der arme kleine
Arduino Nano neben der Leistungs-Elektronik und Elektrik
positioniert ist kann es einem nur übel werden. Da fliessen
ein paar Ampere durch Spulen gleich neben dem Nano, und da
soll nichts Unerwünschtes in so einer CMOS-Schaltung passieren?

Na dann, gute Nacht .... obwohl es erst Morgen ist.

von Gerhard O. (gerhard_)


Bewertung
2 lesenswert
nicht lesenswert
Was mich betrifft finde ich Deine Bemerkungen voller (böswilliger) 
Unterstellungen die überhaupt nicht zutreffend sind und möchte sie 
hiermit einzeln widerlegen:

oweiowei schrieb:
> Gerhard O. schrieb:
>> AVR Nicht-Atomares Fehlverhalten in flagrante ertappt!
>
> Das klingt sehr danach dass du hoch über den Dingen stehst und
> soeben einen Design-Fehler der Atmel Entwickler gefunden hast.
Blödsinn!!!

Der Titel entsprung nur meiner Neigung manchmal schlagzeigenartige Titel 
zu wählen um etwas humorvolle Dramatik in den Kontext zu bringen und 
nichts Weiteres. Das kann man sehen wie man will.
>
> Sozusagen das Pendant zu "ich habe einen Compiler Bug gefunden".
Widerum Blödsinn und eine unnötige nd unangebrachte Unterstellung. Wie 
kommst Du denn darauf? Ich beschäftige mich schon zu lange mit uC um 
nicht zu wissen, daß in vielen Fällen die Fehler vor dem Komputer sitzen 
und man nicht voreilig sein sollte. In diesen Fall könntest Du nicht 
ferner von der Wahrheit sein. Man sollte mit der Beurteilung Anderer die 
man nicht wirklich kennt vorsichtig sein.
>
> Na dann, grossen Respekt vor deinen hohen Künsten. Die Atmel
> Entwickler bei Microchip werden dir ein Denkmal setzen. Aber
> melden musst du dich schon selbst bei denen, sonst wird das nix.
Blödsinn! Welche Läuse laufen bei Dir heute auf der Leber herum? Wer 
mich kennt, würde mir so eine bornierte Einstellung und Denkweise 
überhaupt nicht zutrauen. Du tust mir leid alles in einem so einen 
negativen Licht zu sehen. Ganz im Gegenteil hatte ich immer schon einen 
großen Respekt vor den Entwicklern in solchen Firmen.

Abgesehen davon finde ich es eigentlich ziemlich hinterhältig so anonym 
zu stänkern. Ganz im Gegenteil reflektiert Dein Kommentar was Du mir 
vorwirfst. Chill out!

Aber lassen wir es gut sein. Solange der Fehler reproduzierbar ist wird 
man mit etwas Geduld und Arbeit dem Phänomen bestimmt alleine auf die 
Spur kommen.

Schönes Wochenende noch.

Gerhard

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hm. Na gut. Du hast das vielleicht nicht so gemeint.

Aber bist Du Dir darüber im klaren, dass bei den Entwicklern im ersten 
Moment alle ALARMGLOCKEN läuten, wenn so was im Raum steht?

Das ist wie Feuer "rufen". Man macht das nicht zum Spaß. Aus gutem 
Grund.
Denn viele verdienen ihr tägliches Brot und ihr Dach über dem Kopf mit 
den Sachen. Du hättest es auch nicht gerne, wenn jemand mit Deinen 
Knöpfen (also Deinen Befürchtungen) herumspielt.

@ Mods: Ich halte es für angebracht den Thread-Titel zu ändern.
Z.B. in "Nicht-atomarer Zugriff bewirkt unerwünschtes Programmverhalten"

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hm. Na gut. Du hast das vielleicht nicht so gemeint.

Aber bist Du Dir darüber im klaren, dass bei den Entwicklern im ersten 
Moment alle ALARMGLOCKEN läuten, wenn so was im Raum steht?

Das ist wie Feuer "rufen". Man macht das nicht zum Spaß. Aus gutem 
Grund.
Denn viele verdienen ihr tägliches Brot und ihr Dach über dem Kopf mit 
den Sachen. Du hättest es auch nicht gerne, wenn jemand mit Deinen 
Knöpfen (also Deinen Befürchtungen) herumspielt.

Im übrigen ist die Tatsache an sich trivial und allgemein bekannt. 
Meiner Meinung nach, ist es also sinnlos daraus ein Thema zu machen.

@ Mods: Ich halte es für angebracht den Thread-Titel zu ändern.
Z.B. in "Nicht-atomarer Zugriff bewirkt unerwünschtes Programmverhalten"

von Gerhard O. (gerhard_)


Bewertung
1 lesenswert
nicht lesenswert
oweiowei schrieb:
> Gerhard O. schrieb:
>> Wie in meinem anderen Thread
>> (Beitrag "Ein Füllstandmesser auf Einperlungsbasis") zu lesen ist
>
> Wenn ich mir auf den Bildern anschaue wie nahe der arme kleine
> Arduino Nano neben der Leistungs-Elektronik und Elektrik
> positioniert ist kann es einem nur übel werden. Da fliessen
> ein paar Ampere durch Spulen gleich neben dem Nano, und da
> soll nichts Unerwünschtes in so einer CMOS-Schaltung passieren?
>
> Na dann, gute Nacht .... obwohl es erst Morgen ist.

Nichts für ungut, hier muß ich Dir auch noch einige Zähne ziehen;-)

Erstens fliessen durch die Miniatur-Magnetventile keine großen Ströme. 
Der Betriebstrom der Ventile ist einzeln unter 160mA. Abgesehen davon 
sind das 12V Ventile die noch sparat Elko gestützt sind und die 
Schaltenergie vom Elko bekommen. Oszillographisch ist die 
Stromversorgung bewiesen Ohne jegliche Einbrüche oder Transienten. Die 
5V Stromversorgung ist auch extern vom Nano und absolut zuverlässig. UC 
RESETS sind bisher noch NIE vorgekommen.

Zweitens war keines der Magnetventile beim Fehlerbild überhaupt in 
Betrieb. Ausser beim zyklischen Nachpumpen und Sensor 
Nullpunktüberprüfung bleiben alle Magnetventile zwecks Energiersparnis 
immer abgeschaltet und sind deshalb für das erwähnte Phänomen nicht 
verantwortlich. Das passierte aus heiterem Himmel dessen Ursache zu 
ergründen der Zweck meiner Anfrage war. Der Pumpenmotor hat auch seine 
eigene Filterung und Elko Entkopplung und oszilloskopisch ist da auch 
nichts auffälliges zu bemerken.

Drittens ist die ganze Elektronik metallisch vom Elektroteil statisch 
abgeschirmt vom Oberteil und alles funktioniert absolut einwandfrei. 
Kein IO-Pin vom NANO ist ungeschützt. Die ganze Elektronik um den NANO 
herum wurde nach industriellen Gesichtspunkten mit allen gebräuchlichen 
Schutzmaßnahmen entworfen und hat sich bis jetzt als 100% zuverlässig 
erwiesen. Eine elektromagnetische Beeinflussung des uC ist so ziemlich 
auszuschliessen obwohl natürlich möglich. Aber das muß erst noch 
bewiesen werden.

Aber hören wir auf zum Streiten und freuen uns lieber übers warme 
sommerliche Wochenende.

Gerhard

: Bearbeitet durch User
von Gerhard O. (gerhard_)


Bewertung
1 lesenswert
nicht lesenswert
Theor schrieb:
> Hm. Na gut. Du hast das vielleicht nicht so gemeint.
>
> Aber bist Du Dir darüber im klaren, dass bei den Entwicklern im ersten
> Moment alle ALARMGLOCKEN läuten, wenn so was im Raum steht?
Hmmm. Das hatte ich nicht bedacht;-)
>
> Das ist wie Feuer "rufen". Man macht das nicht zum Spaß. Aus gutem
> Grund.
> Denn viele verdienen ihr tägliches Brot und ihr Dach über dem Kopf mit
> den Sachen. Du hättest es auch nicht gerne, wenn jemand mit Deinen
> Knöpfen (also Deinen Befürchtungen) herumspielt.
Das stimmt.
>
> Im übrigen ist die Tatsache an sich trivial und allgemein bekannt.
> Meiner Meinung nach, ist es also sinnlos daraus ein Thema zu machen.
Wie meinst Du das? Kannst Du mir ein ähnliches Beispiel nennen wo 
Ähnliches vorgekommen ist?
>
> @ Mods: Ich halte es für angebracht den Thread-Titel zu ändern.
> Z.B. in "Nicht-atomarer Zugriff bewirkt unerwünschtes Programmverhalten"

Danke für Deine Gedanken dazu. Ich war wohl etwas voreilig und finde 
Deine Betrachtungen dazu stichhaltig.

Auch möchte ich das Teil noch eine Zeitlang überwachen um zu ergründen 
ob der Fehler reproduzierbar ist. Auch ein Programmierfehler meinerseits 
ist natürlich nicht auszuschließen. Im Augenblick weiß ich nur, daß der 
Fehler bei atomaren Zugriff auf die ADC Daten vom Array bis jetzt noch 
nicht aufgetreten ist und nur so wie beschrieben passierte.

Gruß,
Gerhard

: Bearbeitet durch User
von W.S. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Der ADC läuft in einer ISR um
> automatisch sechs Analog Kanäle regelmäßig zu messen und dann in einen
> globalen 16-bit Array live abzuspeichern.

Gerhard, warum machst du das bloß SO? Ich würde an deiner Stelle bei 
jedem neuen ADC-Wert ein Ereignis generieren, was dann in der 
Grundschleife ausgewertet wird. Ab dort kannst du dann alle deine 
ADC-Werte beliebig speichern, weil ab da ohnehin kein Zugriff durch die 
ISR erfolgt.

Eine einfache Event-Verwaltung paßt ganz gewiß auch in einen kleinen AVR 
hinein, für die Queue braucht es da wohl nicht mehr als 4 Events (macht 
dann eine Queue von 12 Bytes im RAM aus), da mußt du dir ja lediglich 
ein passendes Format für so einen Event ausdenken. Zum Beispiel einen 
kleinen Struct aus 3 Byte: ID, WertHi, WertLo.

Und wenn du dich erstmal an das Arbeiten mit Events gewöhnt hast, wirst 
du die nicht mehr missen wollen.

W.S.

ps: wolltest du nicht mal bei Gelegenheit noch ein Wort über EDA Systeme 
sagen?

von MWS (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Dann habe ich aus Neugierde absichtlich den atomaren Zugriff im Alarm
> Code auskommentiert
>....
> und ein völlig
> uncharakteristischer extrem hoher ADC Wert (~27K) wurde zum Beweis am
> Terminal ausgelesen.

Das bedetet also, wenn man es so macht, wie es bei wechselweisen Zugriff 
aus ISR/main gehört, dann läuft es, ansonsten nicht. Wo bekommst Du nur 
diese sagenhaften Erkenntnisse her?
Aus China vielleicht, Sack Reis und so?!

> in flagrante ertappt!

In flagranti wär's vielleicht, wenn Du den Stand des PCs, den 
verletzenden Opcode und ein Abbild des Stacks hättest, was Du dagegen 
vermutest ist, dass der Controller irgendwo/irgendwann fremd ging.

Und dafür dieser Thread.
Bist Du einsam?

von Gerhard O. (gerhard_)


Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Gerhard O. schrieb:
>> Dann habe ich aus Neugierde absichtlich den atomaren Zugriff im Alarm
>> Code auskommentiert
>>....
>> und ein völlig
>> uncharakteristischer extrem hoher ADC Wert (~27K) wurde zum Beweis am
>> Terminal ausgelesen.
>
> Das bedetet also, wenn man es so macht, wie es bei wechselweisen Zugriff
> aus ISR/main gehört, dann läuft es, ansonsten nicht. Wo bekommst Du nur
> diese sagenhaften Erkenntnisse her?
> Aus China vielleicht, Sack Reis und so?!
Kann man denn nicht einmal mal nur einfach neugierig sein zu erfahren 
was passiert wenn man es absichtlich nicht richtig macht? Warum wird man 
immer so extrem mißverstanden? Es war pure Neuguerde, sonst nichts was 
mich zu diesen Experiment bewogen hatte. Den Sarkasmus finde ich nicht 
wirklich fair.

Was interessant war, daß es mindestens 24 Stunden ohne Fehler 
funktioniert hatte.
>
>> in flagrante ertappt!
>
> In flagranti wär's vielleicht, wenn Du den Stand des PCs, den
> verletzenden Opcode und ein Abbild des Stacks hättest, was Du dagegen
> vermutest ist, dass der Controller irgendwo/irgendwann fremd ging.
Da hast Du natürlich recht. Ist aber im Augenblick mangels Debug Zugang 
keine praktische Möglichkeit.
>
> Und dafür dieser Thread.
> Bist Du einsam?
Ich war offensichtlich der irrtümlichen Meinung, daß so ein absichtlich 
herbei geführter Fehler für einige im Forum lesenden interessant sein 
hätte können. Für euch Profis ist es natürlich ein alter Hut. Da sieht 
man wie man sich irren kann;-)

Jedenfalls wäre es am Besten diesen Thread so bald wie möglich in ein 
schwarzes Loch hineinfallen zu lassen.

Schönes Wochenende noch

Gerhard

von Gerhard O. (gerhard_)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Gerhard O. schrieb:
>> Der ADC läuft in einer ISR um
>> automatisch sechs Analog Kanäle regelmäßig zu messen und dann in einen
>> globalen 16-bit Array live abzuspeichern.
>
> Gerhard, warum machst du das bloß SO? Ich würde an deiner Stelle bei
> jedem neuen ADC-Wert ein Ereignis generieren, was dann in der
> Grundschleife ausgewertet wird. Ab dort kannst du dann alle deine
> ADC-Werte beliebig speichern, weil ab da ohnehin kein Zugriff durch die
> ISR erfolgt.
Ich mache das schon seit Jahrzehnte so, daß die erfassten ADC Werte 
immer live von main aus zugänglich sind und der ADC unsichtbar im 
Hintergrund ohne weitere Interventionen läuft. Pure Gewohnheit. Es ist 
auch notwendig beim Drucksensor zwei Werte gleichzeitig zur 
Ratiometrischen Berechnung zur Verfügung zu haben.
>
> Eine einfache Event-Verwaltung paßt ganz gewiß auch in einen kleinen AVR
> hinein, für die Queue braucht es da wohl nicht mehr als 4 Events (macht
> dann eine Queue von 12 Bytes im RAM aus), da mußt du dir ja lediglich
> ein passendes Format für so einen Event ausdenken. Zum Beispiel einen
> kleinen Struct aus 3 Byte: ID, WertHi, WertLo.
Das wäre mal interessant so auszuprobieren. Danke für den Vorschlag.
>
> Und wenn du dich erstmal an das Arbeiten mit Events gewöhnt hast, wirst
> du die nicht mehr missen wollen.
Events verwende ich im Program schon. Nur den ADC lasse ich selbständig 
im Hintergrund die Kanäle abarbeiten.
>
> W.S.
>
> ps: wolltest du nicht mal bei Gelegenheit noch ein Wort über EDA Systeme
> sagen?
Im Winter, vielleicht. Eigentlich habe ich ehrlich gesagt keine große 
Motivation über KiCad zu kommentieren weil ich mich dazu fairerweise 
mehr hineinknien müsste und ich dazu im Augenblick keine Zeit habe. Auch 
habe ich bald Urlaub und bin einige Zeit nicht zuhause. Auch habe ich 
nur eine alte Version von KiCad installiert. Für mich sind eigentlich 
nur Altium und PR99SE von wirklichen Interesse. Meine fast dreissig 
Jahre Reichende Investition in meinen Bibliotheken ist einfach zu 
umfangreich als das ich ohne triftigen Grund jetzt auf ein anderes CAD 
umsteigen wollte. Es ist leider so, daß mir die Bibliotheken einfach zu 
wichtig sind. Ich bin trotz allem sicher, daß ich warscheinlich KiCad 
verwenden würde wenn ich nicht Zugang zu den vorher genannten hätte. 
KiCad ist denen noch am ähnlichsten.

Gerhard

von MWS (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Ich war offensichtlich der irrtümlichen Meinung, daß so ein absichtlich
> herbei geführter Fehler für einige im Forum lesenden interessant sein
> hätte können.

Codetechnische Fehler werden in der Regel unbeabsichtigt herbeigeführt 
und führen zu, taddaa: Problemen. Sonst gäbe es keine Posts dazu.

Nun gibt es tausende Möglichkeiten für unbeabsichtigte Fehler, wenn Du 
jetzt noch aufzeigen willst, wieviele beabsichtigte Möglichkeiten es 
gibt, dann wird das eine Lebensaufgabe.

Mit 'nem Lerneffekt wird's auch schwierig, denn die Auswirkung von 
nichtatomaren Zugriffen hängen vom betroffenen Code ab.

Also: Sack Reis.

von Gerhard O. (gerhard_)


Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Gerhard O. schrieb:
>> Ich war offensichtlich der irrtümlichen Meinung, daß so ein absichtlich
>> herbei geführter Fehler für einige im Forum lesenden interessant sein
>> hätte können.
>
> Codetechnische Fehler werden in der Regel unbeabsichtigt herbeigeführt
> und führen zu, taddaa: Problemen. Sonst gäbe es keine Posts dazu.
Hmmm...
>
> Nun gibt es tausende Möglichkeiten für unbeabsichtigte Fehler, wenn Du
> jetzt noch aufzeigen willst, wie viele beabsichtigte Möglichkeiten es
> gibt, dann wird das eine Lebensaufgabe.
War nicht meine Absicht. Wollte nur sehen wie lange es dauern würde bis 
beim Fehlverhalten ein Alarm produziert wird. Fazit ist, dass mit 
atomaren Zugriff noch nie (1 Woche) ein Fehler auftrat und es ohne 
innerhalb von 24 Stunden ein Fehlverhalten gab.
>
> Mit 'nem Lerneffekt wird's auch schwierig, denn die Auswirkung von
> nichtatomaren Zugriffen hängen vom betroffenen Code ab.
>
> Also: Sack Reis.
Na, wenn Du wirklich meinst lasse ich's jetzt gelten;-)

OK. Hören wir jetzt besser auf ein totes Pferd weiterhin zu prügeln. Es 
wurde mittlerweile ja genug Tinte deswegen verspritzt.

Gerhard

von MWS (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Wollte nur sehen wie lange es dauern würde bis
> beim Fehlverhalten ein Alarm produziert wird.

Das kann u.U ewig dauern, wenn zufälligerweise (bei sehr geradlinig 
ablaufendem Code) ein festes Teilerverhältnis zwischen der main und 
einem Timer mit dessen ISR existiert. Sofern dann aufgrund einer 
Verzweigung im main sich dIe Ablaufzeit und damit Synchronisation 
ändert, kommt's zum Fehler. Deshalb eine tückische Fehlerquelle.

> Es wurde mittlerweile ja genug Tinte deswegen verspritzt.

Sind nur recycelte Bytes ;-)

von Gerhard O. (gerhard_)


Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Gerhard O. schrieb:
>> Wollte nur sehen wie lange es dauern würde bis
>> beim Fehlverhalten ein Alarm produziert wird.
>
> Das kann u.U ewig dauern, wenn zufälligerweise (bei sehr geradlinig
> ablaufendem Code) ein festes Teilerverhältnis zwischen der main und
> einem Timer mit dessen ISR existiert. Sofern dann aufgrund einer
> Verzweigung im main sich dIe Ablaufzeit und damit Synchronisation
> ändert, kommt's zum Fehler.
Deshalb wollte ich wissen ob ich da absichtlich eine Fehler auf diese 
Weise absichtlich produzieren kann.
> Deshalb eine tückische Fehlerquelle.
Darüber habe ich auch schon nachgedacht. Es laufen T0 und T2, ADC-ISR 
und die USART ISRs wenn Kommunikation passiert. Ein Scheduler initiiert 
periodische Arbeitsabläufe und die HW Überwachung. Die Tasten, LEDs und 
der Motor uns alle Ventile müssen sich die 16-bit SR Ausgaenge teilen 
und werden von der Timer2 ISR periodisch bearbeitet. Es passiert als im 
normalen Ablauf relativ viel. Ob das alles wie ein Uhrwerk 
Zahnradtriebwerk reproduzierbar läuft? Kaum...
>
>> Es wurde mittlerweile ja genug Tinte deswegen verspritzt.
>
> Sind nur recycelte Bytes ;-)
Das stimmt auch wieder;-)

von MWS (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Ob das alles wie ein Uhrwerk
> Zahnradtriebwerk reproduzierbar läuft? Kaum...

Wenn immer dieselben Abläufe existieren, besonders ohne 
User-Interaktion, kann's synchron werden. Die verschiedenen 
Unterprogramme brauchen ja in der Regel die gleiche Anzahl Takte.

Bis ein ISR-Zugriff zufällig den nichtatomaren main-Zugriff erwischt und 
vor allem auch einen bemerkbaren Fehler hinterlässt, kann's dauern.

In Deinem Beispiel hast Du den Fehler wegen stark abweichendem Wert 
bemerkt, aber im Umkehrschluss bedeutet es nicht, dass nicht vorher 
bereits Fehler auftraten, welche für Dich nicht erkennbar waren.

von Gerhard O. (gerhard_)


Bewertung
0 lesenswert
nicht lesenswert
MWS schrieb:
> Gerhard O. schrieb:
>> Ob das alles wie ein Uhrwerk
>> Zahnradtriebwerk reproduzierbar läuft? Kaum...
>
> Wenn immer dieselben Abläufe existieren, besonders ohne
> User-Interaktion, kann's synchron werden. Die verschiedenen
> Unterprogramme brauchen ja in der Regel die gleiche Anzahl Takte.
>
> Bis ein ISR-Zugriff zufällig den nichtatomaren main-Zugriff erwischt und
> vor allem auch einen bemerkbaren Fehler hinterlässt, kann's dauern.
>
> In Deinem Beispiel hast Du den Fehler wegen stark abweichendem Wert
> bemerkt, aber im Umkehrschluss bedeutet es nicht, dass nicht vorher
> bereits Fehler auftraten, welche für Dich nicht erkennbar waren.

Hmm. Das ist wahr. Ein Fehlwert unter der Alarmschwelle würde im 
speziellen Fall nicht erkannt werden. Ich könnte interessehalber 
periodisch alle ADC Werte vom Terminal in eine CSV Datei schreiben und 
dann einige tausend Werte vergleichen. Abweichungen müssten dann sofort 
erkenntlich sein. Die ADC Werte sind normalerweise immer sehr stabil.

I will be back;-)

Habe heute viel Ablenkungen weil ich Besuch habe...

Gerhard

von W.S.H. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> Gerhard O. schrieb:
>> Der ADC läuft in einer ISR um
>> automatisch sechs Analog Kanäle regelmäßig zu messen und dann in einen
>> globalen 16-bit Array live abzuspeichern.
>
> Gerhard, warum machst du das bloß SO? Ich würde an deiner Stelle bei
> jedem neuen ADC-Wert ein Ereignis generieren, was dann in der
> Grundschleife ausgewertet wird. Ab dort kannst du dann alle deine
> ADC-Werte beliebig speichern, weil ab da ohnehin kein Zugriff durch die
> ISR erfolgt.

Es gibt Menschen die können programmieren und es gibt: dich.

1)
Jittert das nicht so sehr wenn es im IRQ abgeholt und angestoßen wird 
(zB beim mehrere Kanäle durchgehen).

2)
Im Free running Mode mit "Event" kann ein Wert verloren gehen, wenn die 
Hauptschleife grade einen anderen großen Task abhandelt.

3)
Leider haben AVR keinen DMA, dann geht alles nebenher zur CPU.
So viel zu deiner ewigen Behauptung "DMA spart keine Rechenleistung".

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.

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