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
> 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.
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;-)
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.
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.
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
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"
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"
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
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
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?
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?
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
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
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.
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
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 ;-)
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;-)
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.
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
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".
Bitte 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.