ADC-Kanäle sukzessive abfragen

StefanK schrieb:

Wie macht man das am elegantesten? Hat jemand ein Beispiel?

int h=adc(0); int i=adc(1); int j=adc(2);

StefanK schrieb:

so schnell wie möglich

1k schnell oder 1M schnell?

StefanK schrieb:

Wie macht man das am elegantesten?

Und elegant soll es auch noch sein. Mir reicht es schon, wenn es funktioniert.

StefanK schrieb:

Wie macht man das am elegantesten?

Summierer mit anschließendem Integrator. Das läuft voll im Hintergrund.

Die Frage ist so unspezifisch. Mit den gegebenen Angaben:

Akkumulatorregister auf 0 setzen. Nacheinander Kanal auswählen, Wandlung starten, Ergebnis abwarten, Ergebnis auf das jeweilige Akkumulatorregister addieren. Das ganze viermal, dann den Inhalt der Akkumulatorregister durch vier teilen.

Oder worauf bezieht sich die Frage genau?

Dann will ich mal mehr spezifizieren. Das ganze soll auf einem Arduino entwickelt/getestet werden und später auf einem ATtiny laufen. Ich will die Fähigkeit Des AD-Wandlers laufend zu messen geschickt nutzen, so dass das Hauptprogramm nicht warten muss.

Dann geht es genauso, wie beschrieben. Den ADC auf maximal 200 kHz konfigurieren (so kenne ich es von den AVR), ADC-Interrupt aktivieren, Kanal auswählen und Wandlung starten. Am Ende der Wandlung das Ergebnis auslesen, den nächsten Kanal auswählen und die nächste Wandlung starten.

StefanK schrieb:

Dann will ich mal mehr spezifizieren.

Erwähne am besten nicht, was das werden soll, und warte, bis es Sonnabend geworden ist. ATTiny und möglichst schnell geht eher in Richtung schwarzer Schimmel.

Florian schrieb:

Dann geht es genauso, wie beschrieben. Den ADC auf maximal 200 kHz konfigurieren (so kenne ich es von den AVR), ADC-Interrupt aktivieren, Kanal auswählen und Wandlung starten. Am Ende der Wandlung das Ergebnis auslesen, den nächsten Kanal auswählen und die nächste Wandlung starten.

Danke Florian. Kann man in der Interruptroutine bereits auf den nächsten Kanal umschalten und die nächste Wandlung für diesen anstossen?

Gibt es Beispiele für Implementierungen? Das ist doch vermutlich ein Standardfall, dass man mehrere Kanäle direkt hintereinander auslesen will.

StefanK schrieb:

Wie macht man das am elegantesten?

Indem man ersteinmal die Randbedingungen klar legt.

Welche ADCs kommen in Frage, wie hoch muss die Auflösung mindestens sein, welche µCs kommen in Frage, was ist der Mindestwert für "so schnell wie möglich", was darf es kosten?

Das hier kommt dem am nächsten, was ich suche: https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Analoge_Ein-_und_Ausgabe#Der_interne_ADC_im_AVR

/* ADC Einzelmessung */ uint16_t ADC_Read( uint8_t channel ) { // Kanal waehlen, ohne andere Bits zu beeinflußen ADMUX = (ADMUX & ~(0x1F)) | (channel & 0x1F); ADCSRA |= (1<<ADSC); // eine Wandlung "single conversion" while (ADCSRA & (1<<ADSC) ) { // auf Abschluss der Konvertierung warten } return ADCW; // ADC auslesen und zurückgeben }

...und genau das "warten" will ich vermeiden: while (ADCSRA & (1<<ADSC) ) { // auf Abschluss der Konvertierung warten }

Kann man in der Interruptroutine bereits auf den nächsten Kanal umschalten und die nächste Wandlung für diesen anstossen?

Warum nicht? Woher sollte der ADC wissen, ob er im Hauptprogramm oder in der ISR gestartet wird?

StefanK schrieb:

Wie macht man das am elegantesten? Hat jemand ein Beispiel?

Nacheinander auslesen! Beispiel? Nicht 100%. Einfach umzubauen.

StefanK schrieb:

Dann will ich mal mehr spezifizieren. Das ganze soll auf einem Arduino entwickelt/getestet werden und später auf einem ATtiny laufen. Ich will die Fähigkeit Des AD-Wandlers laufend zu messen geschickt nutzen, so dass das Hauptprogramm nicht warten muss.

Auch kein Problem.

Rainer W. schrieb:

Welche ADCs kommen in Frage, wie hoch muss die Auflösung mindestens sein, welche µCs kommen in Frage, was ist der Mindestwert für "so schnell wie möglich", was darf es kosten?

Interner ADC des ATMega328P zum entwickeln und wenn fertig auf Target ATtiny13 portieren, Auflösung 10bit. Kein extra AD-Wandler.

Wichtig ist mir, dass das Hauptprogramm nicht warten muß, bis der AD die Wandlungen beendet hat. Und da hapert es mit dem Beispiel im o.g. Tutorial.

S. L. schrieb:

Woher sollte der ADC wissen, ob er im Hauptprogramm oder in der ISR gestartet wird?

Das weiß der AD natürlich nicht. Aber bis die Messung des neuen Kanals von der Interruptroutine angestossen ist, hat der AD vlt schon mit der Messung des alten Kanals weitergemacht.

Sie verwenden für diesen Fall natürlich den 'Single Conversion'- und nicht den 'Free Running'-Modus.

Auch Ulli auf seiner Roboterseite wartet: https://ullisroboterseite.de/avr-libs-adc.html#avg-source

for(i=0; i< AdcAvgCount; i++) { // Eine Wandlung ADCSRA |= (1<<ADSC); // Auf Ergebnis warten... while(ADCSRA & (1<<ADSC));

result += ADCW; }

warten ist doof!

Vorschlag: ausprobieren! Also:

1. Ihr Beispiel (von wem auch immer) mit dem Warten.
2. Umschreiben auf Interrupt nach Wandlung, d.h. ohne Warten.
3. mehrere Kanäle mit dem Umschalten in der ISR.

Warten muss man nicht.

S. L. schrieb:

Vorschlag: ausprobieren! Also:

1. Ihr Beispiel (von wem auch immer) mit dem Warten.
2. Umschreiben auf Interrupt nach Wandlung, d.h. ohne Warten.
3. mehrere Kanäle mit dem Umschalten in der ISR.

Klingt nach einem guten Vorschlag. Danke, auch an Florian.

StefanK schrieb:

Wichtig ist mir, dass das Hauptprogramm nicht warten muß, bis der AD die Wandlungen beendet hat.

Das Hauptprogramm muss nicht warten. Es kann während dessen beliebigen anderen Aktionen nachgehen und dann mit einem Interrupt auf das ADIF reagieren.

Was dein "so schnell wie möglich" betrifft, hast du mit einem ATmega328 das Problem, dass er nur einen einzigen ADC besitzt, d.h. du kannst den Kanal sowieso erst umschalten und die nächste Messung starten, wenn die erste Wandlung fertig ist. Parallele Messung ist damit nicht möglich. Die Wandlungszeit beträgt 13 ADC Clock Zyklen, da lässt sich nichts dran abkürzen, wenn du die volle Auflösung nutzen möchtest.

Beispiel aus meiner Wühlkiste, leicht modifiziert! Tuts für die üblichen Arduino AVR Boards und dem t45 und t85

Zeigt den grundsätzlichen Ablauf. Wenn gewünscht, gibts auch die Lib, die ist aber noch relativ unaufgeräumt.

StefanK schrieb:

...und genau das "warten" will ich vermeiden: while (ADCSRA & (1<<ADSC) ) { // auf Abschluss der Konvertierung warten }

Mir war nicht klar, dass diese Warteschleife der Kern der Frage ist. Deshalb gingen meine Antworten etwas daran vorbei. Aber mit den anderen Antworten sollte es jetzt ja klar sein.

Ja mein Gott dann mach doch einfach mal. Einfach mal was ohne ein Beispielcode, ohne Copy&Paste ohne Vorlage MACHEN. Schau in das scheiß Datenblatt.

Aber nööööö, bevor man 5 Zeilen Code schreibt erstmal Thread im Forum aufmachen.

Cyblord -. schrieb:

erstmal Thread im Forum aufmachen.

.... und 100 Beiträge generieren/provozieren. Tagelang warten bis einem die gebratenen Tauben in den Mund fliegen.

Cyblord -. schrieb:

Aber nööööö, bevor man 5 Zeilen Code schreibt erstmal Thread im Forum aufmachen.

Was erwartest du? Es reicht ja nicht einmal für eine vernünftige gestellte Frage, aus der wenigstens die Randbedingungen klar hervor gehen - aber ist ja einfacher, irgendwelche Anforderungen ins Forum zu kippen, als selber zu denken.

https://ww1.microchip.com/downloads/en/AppNotes/atmel-8456-8-and-32-bit-avr-microcontrollers-avr127-understanding-adc-parameters_application-note.pdf

Leute, die (zugegeben etwas dürftigen) Voraussetzungen waren doch gleich zu Beginn offensichtlich - es wurde niemand gezwungen weiterzulesen.

Erinnert mich an Watzlawicks 'alte Jungfer' in 'Anleitung zum Unglücklichsein'.

Mi N. (msx) schrieb:

ATTiny und möglichst schnell geht eher in Richtung schwarzer Schimmel.

Der TO hatte "mehr spezifiziert" und einen Arduino als Hardware genannt. Somit ist ein Mega328 als µC anzunehmen. Was soll da z.B. auf einem Tiny25 langsamer laufen?

Bei beiden ist 200 kHz ADC-Takt das Limit für volle Auflösung. Bei beiden dauert eine Wandlung 13 ADC-Takte. Bei beiden fällt bei der max. Speed von 20 MHz die Rechnerei (Summierung und Mittelwert) kaumt in's Gewicht.

????

Was meint ChatGPT dazu? ;-)

Wenn die ISR ausgeführt wird, ist der ADC schon mit der nächsten Messung beschäftigt.

Im 'Single Conversion Mode'? Na, Stefan Frings ...

ChatGPT meint dazu

"Super! Der ATmega328 (wie auf dem Arduino Uno) hat einen eingebauten ADC (Analog-Digital-Wandler), den man effizient nicht-blockierend mit Interrupts benutzen kann. Damit kannst du Messungen durchführen, ohne dass dein Programm anhalten muss. 🛠️ Ziel:

Nicht-blockierende ADC-Messung auf dem ATmega328 mit Interrupts. Ergebnis soll z. B. in einer globalen Variable gespeichert werden. ✅ So funktioniert es:

1

ADC wird im Hintergrund gestartet.

2

3

Wenn die Wandlung fertig ist, löst der ADC einen Interrupt aus.

4

5

Im ISR (Interrupt Service Routine) holst du das Ergebnis ab und speicherst es z. B. in einer globalen Variable.

📜 Beispielcode in C (für Atmel Studio oder avr-gcc)"

1

#define F_CPU 16000000UL

2

#include <avr/io.h>

3

#include <avr/interrupt.h>

4

5

volatile uint16_t adc_result = 0;

6

7

void adc_init(void) {

8

    ADMUX = (1 << REFS0); // AVcc als Referenz, ADC0 als Eingang

9

    ADCSRA = (1 << ADEN)  | // ADC einschalten

10

             (1 << ADIE)  | // Interrupt einschalten

11

             (1 << ADPS2) | (1 << ADPS1) | (1 << ADPS0); // Prescaler 128

12

    sei(); // globale Interrupts aktivieren

13

}

14

15

void adc_start_conversion(void) {

16

    ADCSRA |= (1 << ADSC); // Start ADC-Konvertierung

17

}

18

19

ISR(ADC_vect) {

20

    adc_result = ADC; // Ergebnis in globale Variable speichern

21

    // Optional: adc_start_conversion(); // Neue Messung direkt starten (Dauerbetrieb)

22

}

23

24

int main(void) {

25

    adc_init();

26

    adc_start_conversion(); // erste Messung starten

27

28

    while (1) {

29

        // Hauptprogramm läuft weiter, ohne zu blockieren

30

        // z. B. LED steuern, andere Tasks bearbeiten

31

    }

32

}

Naja, prinzipiel erstmal richtig, wenn gleich unvollständig.

Ralf K. schrieb:

Der TO hatte "mehr spezifiziert" und einen Arduino als Hardware genannt. Somit ist ein Mega328 als µC anzunehmen. Was soll da z.B. auf einem Tiny25 langsamer laufen?

Bei beiden ist 200 kHz ADC-Takt das Limit für volle Auflösung.

Bei 1 MHz kann man auch 6 Bit erhalten. Wo hatte der TO denn volle Auflösung gefordert?

Eine Antwort zeigte 12 Bit Auflösung bei 375 ksps, eine andere dann 'adcCallCack' bei Arduino und selbst "Ulli auf seiner Roboterseite wartet", weil alles so schwierig ist.

Schon klar, alles ein kleiner Spaß zum Freitag ;-)

Etwas besser, wenn gleich nicht gut

"Ah, das macht Sinn! Du möchtest den Mittelwert der Messungen bilden und gleichzeitig den ADC mit maximaler Geschwindigkeit betreiben. Kein Problem – beides lässt sich leicht einbauen! 🔧 Ziel:

1

Maximale ADC-Datenrate: Der ADC des ATmega328 läuft mit einer maximalen Taktfrequenz von 200 kHz bei einer Referenzfrequenz von 16 MHz. Um dies zu erreichen, muss der ADC mit einem Prescaler von 2 betrieben werden.

2

3

Mittelwertbildung: Du willst mehrere Messungen sammeln und den Mittelwert berechnen, um Störungen zu glätten.

🏎️ Maximale ADC-Geschwindigkeit:

1

Der ADC benötigt bei einem Prescaler von 2 nur 13 Takte pro Messung. Bei einem 16 MHz Systemtakt läuft der ADC mit 16 MHz / 2 = 8 MHz, was eine maximal mögliche Frequenz von 200 kHz ergibt."

FALSCH! Soviel zum Thema KI! Ein mit Exabyte aufgepumpter "Zauberlagorithums" fabuliert einfach was zusammen, das in Teilen korrekt ist, in Summe logisch aber falsch. Naja . . .

"🧮 Mittelwert berechnen:

Wir sammeln eine feste Anzahl an Messungen, addieren sie und teilen sie durch die Anzahl der Messungen, um den Mittelwert zu erhalten. 📜 Code mit Mittelwert und maximaler Geschwindigkeit:"

1

#define F_CPU 16000000UL

2

#include <avr/io.h>

3

#include <avr/interrupt.h>

4

5

#define NUM_SAMPLES 10   // Anzahl der Messungen für den Mittelwert

6

7

volatile uint16_t adc_result = 0; // Aktuelles ADC-Ergebnis

8

volatile uint16_t adc_sum = 0;    // Summe der Messungen

9

volatile uint8_t sample_count = 0; // Zähler für gesammelte Messungen

10

11

// ADC initialisieren

12

void adc_init(void) {

13

    ADMUX = (1 << REFS0); // AVcc als Referenz, ADC0 als Eingang

14

    ADCSRA = (1 << ADEN)  | // ADC einschalten

15

             (1 << ADIE)  | // Interrupt einschalten

16

             (1 << ADPS0);  // Prescaler auf 2 (maximale Geschwindigkeit)

17

    sei(); // globale Interrupts aktivieren

18

}

19

20

// ADC-Konvertierung starten

21

void adc_start_conversion(void) {

22

    ADCSRA |= (1 << ADSC); // Start ADC-Konvertierung

23

}

24

25

// ISR für den ADC-Interrupt

26

ISR(ADC_vect) {

27

    adc_result = ADC; // ADC-Ergebnis holen

28

    adc_sum += adc_result; // Messung zur Summe hinzufügen

29

30

    sample_count++; // Zähler erhöhen

31

32

    if (sample_count >= NUM_SAMPLES) {

33

        uint16_t average = adc_sum / NUM_SAMPLES; // Mittelwert berechnen

34

        adc_sum = 0; // Summe zurücksetzen

35

        sample_count = 0; // Zähler zurücksetzen

36

37

        // Mittelwert weiterverwenden (z. B. über serielle Ausgabe)

38

        // Serial.println(average); // Wenn du in der Arduino IDE arbeitest

39

    }

40

41

    adc_start_conversion(); // Neue Messung starten

42

}

43

44

int main(void) {

45

    adc_init();

46

    adc_start_conversion(); // erste Messung starten

47

48

    while (1) {

49

        // Hauptprogramm läuft weiter, ohne zu blockieren

50

        // Hier kannst du die Mittelwerte weiterverarbeiten

51

    }

52

}

Mit dem Hinweis auf den Free running modus schafft es auch ChatGPT. Hmm, not bad. Aber ist da WIRKLICH die Zukunft der Softwareentwicklung? Ich meine, ich musste erst die entscheidenden Stichworte geben? Wenn ich die aber nicht kenne, weil mir das Problem bzw. dessen Lösung unbekannt sind, was macht man dann?

Beispielcode mit Free Running Modus und Mittelwertbildung in der ISR:

1

#define F_CPU 16000000UL

2

#include <avr/io.h>

3

#include <avr/interrupt.h>

4

5

#define NUM_SAMPLES 10   // Anzahl der Messungen für den Mittelwert

6

7

volatile uint16_t adc_result = 0; // Aktuelles ADC-Ergebnis

8

volatile uint16_t adc_sum = 0;    // Summe der Messungen

9

volatile uint8_t sample_count = 0; // Zähler für gesammelte Messungen

10

11

// ADC initialisieren

12

void adc_init(void) {

13

    ADMUX = (1 << REFS0);  // AVcc als Referenz, ADC0 als Eingang

14

    ADCSRA = (1 << ADEN)   | // ADC einschalten

15

             (1 << ADIE)   | // Interrupt einschalten

16

             (1 << ADATE)  | // Free Running Modus aktivieren

17

             (1 << ADPS0);   // Prescaler auf 2 (maximale Geschwindigkeit)

18

    sei(); // globale Interrupts aktivieren

19

}

20

21

// ISR für den ADC-Interrupt

22

ISR(ADC_vect) {

23

    adc_result = ADC; // ADC-Ergebnis holen

24

    adc_sum += adc_result; // Messung zur Summe hinzufügen

25

    sample_count++; // Zähler erhöhen

26

27

    if (sample_count >= NUM_SAMPLES) {

28

        uint16_t average = adc_sum / NUM_SAMPLES; // Mittelwert berechnen

29

        adc_sum = 0; // Summe zurücksetzen

30

        sample_count = 0; // Zähler zurücksetzen

31

32

        // Mittelwert weiterverwenden (z. B. über serielle Ausgabe)

33

        // Beispiel:

34

        // Serial.println(average); // Wenn du in der Arduino IDE arbeitest

35

    }

36

37

    // Keine Notwendigkeit, eine neue Messung zu starten, 

38

    // der ADC läuft im Free Running Modus weiter.

39

}

40

41

int main(void) {

42

    adc_init(); // ADC initialisieren

43

44

    while (1) {

45

        // Hauptprogramm läuft weiter, ohne zu blockieren

46

        // Hier kannst du andere Aufgaben erledigen

47

    }

48

}

Stefan Frings vermutete:

Der TO hatte nach dem free running Modus gefragt.

Ich denke, StefanK hatte bis heute abend den Unterschied zwischen 'free running' und 'single conversion' gar nicht gekannt - Sie haben das hineininterpretiert.

S. L. schrieb:

Stefan Frings vermutete:

Der TO hatte nach dem free running Modus gefragt.

Lass die Finger von Dingen, die du nicht verstehst.

Mit deiner Editiererei hast du als Alleinstellungsmerkmal erreicht, dass der Link auf den zitierten Beitrag nicht mehr funktioniert.

S. L. schrieb:

Wenn die ISR ausgeführt wird, ist der ADC schon mit der nächsten Messung beschäftigt.

Im 'Single Conversion Mode'? Na, Stefan Frings ...

Ja ihm fehlen so viele Grundlagen...

Falk B. schrieb:

Aber ist da WIRKLICH die Zukunft der Softwareentwicklung? Ich meine, ich musste erst die entscheidenden Stichworte geben?

Bin gespannt, wann es den ersten Studiengang mit Abschluss Dipl. KI-Prompter gibt.

ATtiny mit 2x ADC.

Georg M. schrieb:

ATtiny mit 2x ADC.

Bringen einem 2 ADC so viel mehr wenn man eigentlich 3 braucht? 😄

StefanK schrieb:

Ich will drei ADC-Kanäle (0 bis 2)

Wenn man es richtig schnell haben will, soll er bei den G von STM32 oder so vorbei schauen. Die haben teilweise schon Mittelwert Filter in HW und 3-5 komplette ADCs mit bis 4MSPS. Da muss die CPU garnichts machen.

Ich bin mir nicht ganz sicher, aber ich meine dass es auch ein Peripheral gab das summieren kann (könnte aber auch der H7 gewesen sein bin ich nicht sicher). Wenn das der Fall ist würden 3 DMA und das Peripheral voll den Rest machen. Ohne CPU.

Viel Spaß beim Datenblatt lesen 😁

Das Problem beim AVR ADC ist, dass nach dem Kanalwechsel extra Zyklen anfallen, i.W. dauert die erste ADC Konvertierung so lange wie die erste Konvertierung nach Aktivierung des ADC.

Ist also recht langsam.

In den Datenblättern steht dazu nix. Hatte ich vor Jahren mal beim Atmel-Support nachgefragt.

Hallo, Johann L. schrieb im Beitrag #7880848:

In den Datenblättern steht dazu nix.

Datenblatt ATmega8/L (2486AA-AVR-02/2013), Kapitel "ADC Input Channels", Seite 194: "In Free Running mode, always select the channel before starting the first conversion. The channel selection may be changed one ADC clock cycle after writing one to ADSC. However, the simplest method is to wait for the first conversion to complete, and then change the channel selection. Since the next conversion has already started automatically, the next result will reflect the previous channel selection. Subsequent conversions will reflect the new channel selection."

rhf

N. M. schrieb:

Viel Spaß beim Datenblatt lesen 😁

och, das ist ja noch recht kompakt im Vergleich zum Referenzmanual!

N. M. schrieb:

Wenn man es richtig schnell haben will, soll er bei den G von STM32 oder so vorbei schauen. Die haben teilweise schon Mittelwert Filter in HW und 3-5 komplette ADCs mit bis 4MSPS. Da muss die CPU garnichts machen.

Da es hier um den ATmega328 mit seinem doch eher gemächlichen ADC Clock geht, spielt die CPU-Zeit für die Mittelung, in Relation zur Wandlungszeit, für die erreichbare Abtastrate fast keine Rolle.

Johann L. schrieb:

Das Problem beim AVR ADC ist, dass nach dem Kanalwechsel extra Zyklen anfallen, i.W. dauert die erste ADC Konvertierung so lange wie die erste Konvertierung nach Aktivierung des ADC.

Ist also recht langsam.

Ist das so? Die komplette Messsequenz 3*4 benötigt hier bei einem ADC-Teiler /64 rund 10800 Takte, also pro Messung 900 System- bzw. 14 ADC-Takte. Laut Datenblatt dauert eine Wandlung 13 ADC-Takte, die Differenz von ca. 1 ADC-Takt bzw. 64 Systemtakte geht beim Interrupthandling verloren.

Falk B. schrieb:

Beispielcode mit Free Running Modus und Mittelwertbildung in der ISR:

Halbiert die Abfragerate bei mehr als einem Kanal, da jede 2te Messung verworfen werden muss.

Sherlock 🕵🏽‍♂️ schrieb:

Der TO hatte nach dem free running Modus gefragt.

Nur in deiner Fantasie.

Gunnar F. schrieb:

och, das ist ja noch recht kompakt im Vergleich zum Referenzmanual!

Erst das eine, dann das andere 😄

Rainer W. schrieb:

Da es hier um den ATmega328 mit seinem doch eher gemächlichen ADC Clock geht, spielt die CPU-Zeit für die Mittelung, in Relation zur Wandlungszeit, für die erreichbare Abtastrate fast keine Rolle.

Ja, er hatte es erst sehr allgemein geschrieben und wollte so schnell wie möglich 3 ADC Werte haben.

StefanK schrieb:

ich will drei ADC-Kanäle (0 bis 2) so schnell wie möglich hinter einander abfragen

Erst später wurde dann ein ATMega/Tiny gesetzt.

N. M. schrieb:

Ja, er hatte es erst sehr allgemein geschrieben und wollte so schnell wie möglich 3 ADC Werte haben. ... Erst später wurde dann ein ATMega/Tiny gesetzt.

Das merkt jedoch nur der Leser, der alle Beiträge in der Reihenfolge ihres Entstehens gelesen hat. Vermutlich sind die Anforderungen (mal wieder) ganz trivial, sodaß es egal ist, ob ADC-Werte 'möglichst schnell', 'sofort' oder 'unmittelbar' zur Verfügung stehen.

Ich denke, der TO weiß selber nicht, was er braucht oder will. Sonst könnte er das ja einfach mal mitteilen.

Sherlock 🕵🏽‍♂️ schrieb:

"Möglichst schnell" erfordert jedenfalls den Free-running Mode denn nur dann arbeitet der ADC ohne Pausen zwischen den Messungen.

Nein!

Stichwort: gesperrte Interrupts. In welcher Phase befindet sich der ADC? Wann darf ein neuer Kanal gewählt werden? Welcher Wert gehört dann zu welchem Kanal?

Nach der Eingangsfrage des TO hätte ich in Bezug auf 'möglichst schnell' beispielsweise einen STM32F/G/Hxyz vorgeschlagen. Ein einzelner ADC im 'scan modus' und Ablage der Einzelwert per DMA wäre 'recht schnell'.

Ein kleiner, feiner µC ist schon der STM32G031, der neben dem 'scan modus' auch noch 'oversampling' zur Filterung bietet. Das nutzt aber nur, wenn man weiß, was man will.

Sherlock 🕵🏽‍♂️ schrieb:

Der neue Kanal gilt dann für die nächste Messung, die nach der gerade laufenden kommt. Also für das übernächste Messergebnis.

'Übernächstes Messergebnis'? Und das soll schnell sein?

Mi N. schrieb:

Stichwort: gesperrte Interrupts.

Was hast Du daran nicht verstanden? Es ist mir jetzt auch egal!

Sherlock 🕵🏽‍♂️ schrieb:

....

Du irrst!

Das ist so typisch für dieses Forum. Irgendwer rotzt eine unüberlegte und schlampig hingeworfene Frage rein und dann streiten sich tagelang die Experten. Immerhin Respekt vor soviel Hilfsbereitschaft. Ich erwarte mehr Sorgfalt von einem Fragesteller.

Sherlock 🕵🏽‍♂️ schrieb:

Auch für dich:

Ja ja...

Ich möchte dein übersteigertes Selbstbewusstsein nicht mit Fakten belasten die dir offensichtlich nicht schmecken.

Johann L. schrieb:

Das Problem beim AVR ADC ist, dass nach dem Kanalwechsel extra Zyklen anfallen, i.W. dauert die erste ADC Konvertierung so lange wie die erste Konvertierung nach Aktivierung des ADC.

Das kann ich nicht bestätigen. Siehe Anhang. Arduino UNO mit ATmega328P. Ich messe 38,459kHz am Testpin PB0. Das macht 76,918 KHz ISR-Frequenz. x13x16=16MHz. D.h. jede Messung braucht wie im Datenblatt beschrieben 13 ADC-Takte. Und das mit Wechsel des ADC-Kanals nach jeder Messung. Das Testsignal ist sogar jitterfrei (auch durch Nutzung von sleep_mode()).

Mit Single Shot Betrieb und Neustart per CPU in der ISR kommt man nur auf 29,4099kHz am Testpin, weil der ADC ja halt ein paar Takte inaktiv ist, bis die ISR angesprungen der ADC neu gestartet worden ist.

In den Datenblättern steht dazu nix. Hatte ich vor Jahren mal beim Atmel-Support nachgefragt.

Gilt das für ALLE AVR oder nur für sehr alte Modelle?

Wenn man also mal eine Zeitbasis braucht und alle Timer belegt sind, der ADC kann das auch!

PS Laut Datenblätter ist ein KANALwechsel ohne "Strafzeit" möglich. Nur das Einschalten des ADC (ADEN) bedingt eine Messzeit von 25 statt 13 Takten. Ebenso ist ein Umschalten der ADC-Referenz mit zusätzlichen Verzögerungen behaftet, das liegt aber an der Referenz, nicht direkt am ADC.

Falk B. schrieb:

Johann L. schrieb:

Das Problem beim AVR ADC ist, dass nach dem Kanalwechsel extra Zyklen anfallen, i.W. dauert die erste ADC Konvertierung so lange wie die erste Konvertierung nach Aktivierung des ADC.

Das kann ich nicht bestätigen. Siehe Anhang.

Bei gleicher Genauigkeit?

Johann L. schrieb:

Das kann ich nicht bestätigen. Siehe Anhang.

Bei gleicher Genauigkeit?

Das war doch gar nicht die Frage. Nein, die hab ich nicht gemessen.

Sherlock 🕵🏽‍♂️ schrieb:

Sieht mir eher nach einem Fall aus, wo jemand persönlich wird, nachdem ihm die Argumente ausgegangen sind.

Du irrst!

Eine Atmel Application Note AVR126 https://www.professordan.com/avr/techlib/techlib8/appnotes/pdf_avr/AVR126.pdf

Seite 7, dritter Punt von unten: "It is recommended to discard the first conversion result (like whenever there is a change in ADC configuration like voltage reference / ADC channel change)"

Sherlock 🕵🏽‍♂️ schrieb:

Johann L. schrieb:

dass nach dem Kanalwechsel extra Zyklen anfallen... In den Datenblättern steht dazu nix.

Das steht nicht im Datenblatt, weil es nicht stimmt. Es fallen keine Extrazyklen an.

Ok, danke für die Information.

Dann hat mir der Atmel Support damals Käse erzählt.

Johann L. schrieb:

Falk B. schrieb:

Johann L. schrieb:

Das Problem beim AVR ADC ist, dass nach dem Kanalwechsel extra Zyklen anfallen, i.W. dauert die erste ADC Konvertierung so lange wie die erste Konvertierung nach Aktivierung des ADC.

Das kann ich nicht bestätigen. Siehe Anhang.

Bei gleicher Genauigkeit?

Ja.

Zumindest bei meinem ATmega328P von '1545'.

Johann L. schrieb:

Ok, danke für die Information.

Dann hat mir der Atmel Support damals Käse erzählt.

Sie haben dich getrollt! Logisch, waren ja Norweger! ;-)

https://trollland.eu/wp-content/uploads/norwegen-troll.jpg

Sherlock 🕵🏽‍♂️ schrieb:

Ja das ist schnell. Beispiel:

Du startest den ADC im free-running Modus auf Kanal 1 und gibst ihm direkt danach (genauer gesagt: einen ADC Takt später) den Befehl, zum Kanal 2 zu wechseln ...

Da stellt sich die Frage: wie sieht das konkret aus? Sprich: das dazugehörende Programm zeigen, gemäß der Anforderung 'Messsequenz 3*4' - wieviele Systemtakte werden benötigt?

S. L. schrieb:

Da stellt sich die Frage: wie sieht das konkret aus?

Da ist keine Frage, denn Arduino ist als eine der Ziel/Testplattformen genannt. Damit sind die Diversen Interrupts mit im Spiel UART millis() I2C und wohl noch weitere.

Mal unabhängig von Arduino - Stefan Frings kann als alter Hase sicher ohne dieses Hilfsmittel programmieren. Nach seiner Theorie müsste er mit dem 'free running mode' auf eine Taktanzahl von 3 * 4 * 13 * ADC_Teiler plus ein Bisschen kommen - das würde ich gerne sehen; und gegebenenfalls dazulernen, denn ich komme, wie oben geschrieben, auf rund 10800 Takte.

PS: 3 mal 4 mal 13 mal ADC_Teiler plus ein Bisschen

single conversion mode: 10800 Takte bei einem ADC-Teiler von 64

S. L. schrieb:

Mal unabhängig von Arduino - Stefan Frings kann als alter Hase sicher ohne dieses Hilfsmittel programmieren. Nach seiner Theorie müsste er mit dem 'free running mode' auf eine Taktanzahl von 3 4 13 * ADC_Teiler plus ein Bisschen kommen - das würde ich gerne sehen; und gegebenenfalls dazulernen,

Das steht praktisch schon hier. Ich habe nur das Auslesen und Speichern der ADC-Werte für den Test entfernt.

Beitrag "Re: ADC-Kanäle sukzessive abfragen"

denn ich komme, wie oben geschrieben, auf rund 10800 Takte.

Es sind

1

3*4*13*64=9984

3 ADC-Kanäle 4 Samples / Kanal 13 ADC-Takte/Messung 64 Teilerfaktor für ADC-Takt

Es wird im Freerun Mode KEIN zusätzlicher ADC-Takt für Interrupts verschwendet! Nur im manuellen Modus, wenn die CPU immer wieder den Startschuß geben muss.

Erstmal danke - das Programm (hatte ich völlig übersehen) ist ja sehr kompakt.

Sehe ich das richtig: der ADC-Kanal wird mitten im 1. ADC-Takt umgeschaltet?

Ich habe nur das Auslesen und Speichern der ADC-Werte für den Test entfernt.

Wie sehen die ADC-Werte für die 3 Kanäle aus?

PS: "Once the conversion starts, the channel and reference selection is locked ..." Okay, damit ist der 1. Punkt geklärt und eigentlich auch der 2.

Nochmals danke, einen schönen Abend noch ...

S. L. schrieb:

Erstmal Danke - das Programm (hatte ich völlig übersehen) ist ja sehr kompakt.

Sehe ich das richtig: der ADC-Kanal wird mitten im 1. ADC-Takt umgeschaltet?

Nö. Das MUX-Register wird mit dem neuen Kanal geladen. Das hat aber in dem Moment keinen Einfluß auf den laufenden ADC-Vorgang. Denn der Wert wird beim Start intern in einen "unsichtbaren" Speicher übernommen und die MUX damit eingestellt.

Siehe Datenblatt, ADMUX.

"If these bits are changed during a conversion, the change will not go in effect until this conversion is complete (ADIF in ADCSRA is set)."

"The MUXn and REFS1:0 bits in the ADMUX Register are single buffered through a temporary register to which the CPU has random access. This ensures that the channels and reference selection only takes place at a safe point during the conversion. The channel and reference selection is continuously updated until a conversion is started. Once the conversion starts, the channel and reference selection is locked to ensure a sufficient sampling time for the ADC."

Ich habe nur das Auslesen und Speichern der ADC-Werte für den Test entfernt.

Wie sehen die ADC-Werte für die 3 Kanäle aus?

Was meinst du damit?

Falk B. schrieb:

Siehe Datenblatt, ADMUX.

"If these bits are changed during a conversion, the change will not go in effect until this conversion is complete (ADIF in ADCSRA is set)."

Die Sache ist relativ einfach. Nehmen wir mal an, die ADC-ISR wird aufgerufen, während die Wandlung mit der Kanalnummer n läuft. Dann enthält das ADC-Ergebnisregister den Wert des Kanals n - 1. Und die ISR muß die Parameter für den Kanal n + 1 setzen. Plus und Minus sind natürlich zyklisch entsprechend der Anzahl der Kanäle zu betrachen/benutzen.

Da fehlt dann aber noch ein kleines (aber wichtiges) Stück Wahrheit. Zu Beginn einer "conversion" gibt es leider eine kleine Zeitspanne, in der trotz formal bereits laufender Wandlung noch wirksam am Setup der "aktuellen" Wandlung manipuliert werden kann. Zumindest bei einigen Devices war das so. Sprich: Hardware-Bug beim Register-Buffering, die Übernahme der gepufferten Konfigwerte in die ADC-Hardware erfolgte zum falschen Zeitpunkt im Wandlerzyklus, nicht zum Zeitpunkt der Interuptauslösung sondern erst etwas später. Das verkompliziert die Sache etwas. Zumindest bei den Devices, die von diesem Bug betroffen sind.

Hier die vollständige Version mit Mittelwert und Ende der Messung nach der Mittelwertbildung.

Danke für die Bereitstellung des Programms.

Vielleicht mache ich ja etwas falsch, aber:

Ich lege auf: ADC0 0.0 V, ADC1 3.0 V, ADC2 2.5 V. Erwarte also die Werte 0, 614, 512. Erhalte in adc_avg[0] 380, adc_avg[1] 0, adc_avg[2] 608.

Es scheint also mit adc_avg[0] (der Wert für ADC2) etwas nicht zu stimmen.

PS: bei Ucc= 5.0 V

S. L. schrieb:

Es scheint also mit adc_avg[0] (der Wert für ADC2) etwas nicht zu stimmen.

Dann beseitige den Fehler. Wo im Programm wird welcher Kanal gewählt, wann läuft die Wandlung, was kommt raus, wie geht es in die Mittelung ein und wo wird das Ergebnis abgelegt? Nimm einen Debugger und verfolge Schritt für Schritt was passiert. Genauso, wie man eine neu entwickelte Schaltung Schritt für Schritt in Betrieb nimmt, ist das auch bei der Softwareentwicklung sinnvoll.

S. L. schrieb:

Danke für die Bereitstellung des Programms.

Vielleicht mache ich ja etwas falsch, aber:

Ich lege auf: ADC0 0.0 V, ADC1 3.0 V, ADC2 2.5 V. Erwarte also die Werte 0, 614, 512. Erhalte in adc_avg[0] 380, adc_avg[1] 0, adc_avg[2] 608.

Offensichtlich berücksichtigt das Programm die zyklische Verschiebung um 1 nicht korrekt. Siehe:

Beitrag "Re: ADC-Kanäle sukzessive abfragen"

Holt man das mal nach, kommt raus: adc_avg[0] 0, adc_avg[1] 608, adc_avg[2] 380

Und das sieht doch schon ganz gut aus.

Der Restfehler? Wie war denn der Innenwiderstand der jeweiligen Quellen und mit welchem ADC-Tak wurde gemessen?

Ob S. schrieb:

Offensichtlich berücksichtigt das Programm die zyklische Verschiebung um 1 nicht korrekt. Siehe:

Kann sein, sollte aber eigentlich nicht.

Beitrag "Re: ADC-Kanäle sukzessive abfragen"

Holt man das mal nach, kommt raus:

Was hast du geändert?

adc_avg[0] 0, adc_avg[1] 608, adc_avg[2] 380

Und das sieht doch schon ganz gut aus.

Darum ging es mir nicht, sondern um die Diskrepanz zwischen 380 und 512: 3*512/4 = 380: adc_avg[0] scheint dreimal ADC2 und einmal ADC0 zu messen.

Ob S. schrieb:

Offensichtlich berücksichtigt das Programm die zyklische Verschiebung um 1 nicht korrekt. Siehe:

Stimmt. Die Sache ist etwas kniffeliger als es auf den ersten Blick aussieht. Hier die korrigierte Version, sollte jetzt passen.

S. L. schrieb:

Darum ging es mir nicht, sondern um die Diskrepanz zwischen 380 und 512: 3*512/4 = 380: adc_avg[0] scheint dreimal ADC2 und einmal ADC0 zu messen.

Um das auszuschließen: Welche Impedanz haben die Spannungen an den Eingängen?

Welche Impedanz ...

0.0 V und 3.0 V praktisch 0 (GND und Spannungsregler), 2.5 V Spannungsteiler 1k0 & 1k0.

Falk B. schrieb:

ATmega328P, aka Arduino Uno/Micro/Nano

Du meinst bestimmt den Mini oder Pro Mini.

Der Micro hat einen ATMega32U4 auf dem Board. Dessen ADC ist dem vom 328P ähnlich, aber nicht gleich.

Funktioniert dein Programm wirklich mit dem 32U4? Ich habe es nicht getestet.

Falk B. schrieb:

Hier die korrigierte Version, sollte jetzt passen.

Ich bekomme jetzt 474, 510, 0.

Frage am Rande: warum probieren Sie es nicht selbst aus?

Die Sache ist etwas kniffeliger als es auf den ersten Blick aussieht.

Jedenfalls wäre StefanK überfordert, falls er überhaupt noch mitliest - wir haben die Sphäre des "warten ist doof!" verlassen.

S. L. schrieb:

Hier die korrigierte Version, sollte jetzt passen.

Ich bekomme jetzt 474, 510, 0.

Frage am Rande: warum probieren Sie es nicht selbst aus?

Weil ich auch manchmal faul bin ;-)

Falk B. schrieb:

S. L. schrieb:

Hier die korrigierte Version, sollte jetzt passen.

Ich bekomme jetzt 474, 510, 0.

Frage am Rande: warum probieren Sie es nicht selbst aus?

Weil ich auch manchmal faul bin ;-)

Vielleicht mache ich ja etwas falsch - muss immerhin in Ihr Programm eingreifen, mit meinen nur rudimentären C-Kenntnissen.

S. L. schrieb:

muss immerhin in Ihr Programm eingreifen,

Wer zwingt dich dazu? Wenn jemand mit einer Knarre hinter dir stehen sollte, dann blinzle 2x kurz mit dem linken Auge, damit alle Bescheid wissen.

scnr, WK

OK, hier jetzt real getestet und geht jetzt WIRKLICH! ;-) Incl. Testausgaben auf dem UART mit 9k6. Man darf aber den Prescaler nicht zu klein wählen! Denn dann kommt es zum Übersprechen der ADC-Kanäle am Multiplexer, der kann nur mit endlicher Geschwindigkeit umladen. 20kHz Abtastrate sind mit Prescaler 64 drin, 32 geht auch noch. Bei 16 gibt es Übersprechen und damit falsche Meßergebnisse. Und ja, meine Eingänge sind niederohmig angesteuert, 2x aus einem Labornetzteil und einmal über ein Laborkabel mit 20cm gegen GND.

Falk B. schrieb:

OK, hier jetzt real getestet und geht jetzt WIRKLICH! ;-)

Mit der Arduino IDE auf einem UNO getestet. Läuft!

Sorry, für die späte Rückmeldung. Ist doch noch eine sehr spannende Diskussion geworden. Das Feedback, besser zu spezifizieren und zu MACHEN, nehme ich gern mit. Das mit den gebratenen Tauben nicht ;-)

Was ich auf dem Arduino Uno R3 gemacht habe, findet ihr im Anhang. Leider ist der Wurm drin und ich bekomme es nicht zum Laufen.

Ich habe den ersten Ansatz von Falk B. mit Free Running aufgegriffen und versucht, in der ADC-Interruptroutine 4 Kanäle (AD0-AD3) je 4 mal zu erfassen. An den 4 Kanälen liegen via 10K Potis einstellbare, deutlich voneinander unterscheidbare Spannungen an (AD0:100mV, AD1:200mV, AD2:400mV, AD3:800mV), so dass es möglich sein sollte, falsch zugeordnete Kanäle zu erkennen. Ich erhalte aber völlige erratische Messwerte, die für ca. eine halbe Sekunde stabil sind, dann ansteigen und irgendwann überlaufen. AD0 liefert immer 0, AD1-AD3 leicht ansteigende, aber relativ ähnliche Werte.

Die ADC-Interruptroutine wird alle 106µs aufgerufen. Das viermalige Messen aller 4 Kanäle dauert 1360µs. Das würde bedeuten, dass sich die Interruptroutine ständig selbst unterbricht? Vielleicht ist Free Running doch keine so gute Idee?

Wo liegt der Hase im Pfeffer? Danke schon mal für Hilfreiche Hinweise!

P.S. Habe erst jetzt gesehen, dass es neuen Code gibt. Werde ihn mir mal ansehen, lade trotzdem mal hoch, was ich habe.

OK, einen Fehler habe ich in meinem Programm schom mal gefunden. Das Summen Array muß natürlich vor jeder Messung ge-nullt werden.

Wie übernimmt man den Falk B.-Code in die Arduino IDE?

StefanK schrieb:

Wie übernimmt man den Falk B.-Code in die Arduino IDE?

Neuen Arduino Sketch öffnen Die *.ino komplett leeren und speichern Die c und h Dateien von Falk in den gleichen Ordner werfen. Kompilieren/Hochladen und fertig. Beim nächsten Start der IDE zeigt es auch die Dateien in Tabs

Vielleicht noch Umlaute reparieren und den F_CPU Eintrag auskommentieren.

Cool, es compiliert. Danke

Sketch uses 2410 bytes (7%) of program storage space. Maximum is 32256 bytes. Global variables use 47 bytes (2%) of dynamic memory, leaving 2001 bytes for local variables. Maximum is 2048 bytes.

...zu groß für einen ATtiny mit 1K ;-)

StefanK schrieb:

...zu groß für einen ATtiny mit 1K ;-)

printf raus werfen. Der Tiny hat sowieso keine solche UART

Ja, abspecken, wo es nur geht:-)

Ja, abspecken, wo es nur geht:-)

Nun, auch ich halte viel von "small is beautiful" oder "in der Beschränkung zeigt sich erst der Meister", trotzdem - wie wäre es mit einem ATtiny85? Etwas moderner und vor allem Platz, um sich zu bewegen, nicht wie im Korsett des ATtiny13.

Falk B. schrieb:

Denn dann kommt es zum Übersprechen der ADC-Kanäle am Multiplexer, der kann nur mit endlicher Geschwindigkeit umladen.

Die Impedanz der Quelle ist da nicht ganz unbeteiligt. Kondensatoren an den Multiplexereingängen entschärften das Problem.

Rainer W. schrieb:

Denn dann kommt es zum Übersprechen der ADC-Kanäle am Multiplexer, der kann nur mit endlicher Geschwindigkeit umladen.

Die Impedanz der Quelle ist da nicht ganz unbeteiligt. Kondensatoren an den Multiplexereingängen entschärften das Problem.

Wer lesen kann ist klar im Vorteil!

"Und ja, meine Eingänge sind niederohmig angesteuert, 2x aus einem Labornetzteil und einmal über ein Laborkabel mit 20cm gegen GND."

https://www.youtube.com/watch?v=aoqORos_1WA

;-)

Falk B. schrieb:

Wer lesen kann ist klar im Vorteil!

Ach, das war ein Hinweis für StefanK

S. L. schrieb:

Welche Impedanz ...

0.0 V und 3.0 V praktisch 0 (GND und Spannungsregler), 2.5 V Spannungsteiler 1k0 & 1k0.

Rainer W. schrieb:

Falk B. schrieb:

Wer lesen kann ist klar im Vorteil!

Ach, das war ein Hinweis für StefanK

Dann solltest du zitieren lernen.

S. L. schrieb:

Welche Impedanz ...

0.0 V und 3.0 V praktisch 0 (GND und Spannungsregler), 2.5 V Spannungsteiler 1k0 & 1k0.

Danke. Dann hatte das offensichtlich keinen Anteil am Fehler.

Falk B. schrieb:

Man darf aber den Prescaler nicht zu klein wählen! Denn dann kommt es zum Übersprechen der ADC-Kanäle am Multiplexer, der kann nur mit endlicher Geschwindigkeit umladen.

So isses. Samplerate und Quellimpedanzen sind quasi gegenläufig. Je höher die Samplerate, desto geringer müssen die Quellimpedanzen sein, um letztlich korrekte Werte zu bekommen.

Das gilt übrigens nicht nur für die Messkanäle, sondern genau so auch für die Referenzen, falls man für die Messkanäle auch zwischen verschiedenen Referenzen umschaltet.

Rainer W. schrieb:

Die Impedanz der Quelle ist da nicht ganz unbeteiligt. Kondensatoren an den Multiplexereingängen entschärften das Problem.

Das hilft nur dann, wenn man es garnicht so genau für den aktuellen Moment wissen will, wenn sich also die Messwerte des mit Kondensator "geboosteten" Kanals sowieso nur relativ langsam ändern.

Dieser Ansatz ist hilfreich, wenn man mit der einen verfügbaren ADC sowohl schnell veränderliche Kanäle als auch langsam veränderliche Kanäle messen will. Dann ist man ja zu einer hohen Samplerate gezwungen, um die schnell veränderlichen Kanäle korrekt zu erfassen. Um den Aufwand zu sparen, für die langsamen Kanäle eine Pufferstufe zu verwenden, kann man für diese dann tatsächlich einfach nur einen Puffer-Kondensator verwenden.

Für die schnellen Kanäle wäre so einer aber natürlich massiv kontraproduktiv. Die brauchen halt ggf. doch eine richtige Bufferstufe, wenn sie zu hochohmig sind.

Ob S. schrieb:

Das hilft nur dann, wenn man es garnicht so genau für den aktuellen Moment wissen will, wenn sich also die Messwerte des mit Kondensator "geboosteten" Kanals sowieso nur relativ langsam ändern.

Der Kondensator liefert die Ladung für das Umladen parasitärer Kapazitäten im Multiplexer und für die S&H-Stufe. Die Bandbreite, die sich aus Kondensator und Quellimpedanz ergibt, muss natürlich kompatibel zum Problem sein. Noch ist nicht klar, was StefanK eigentlich messen möchte oder ob das nur eine Fingerübung für "so schnell wie möglich" und "Prozessor nicht warten lassen" sein soll. Bei einer konkreten Anwendung wären die erforderliche Abtastrate und Bandbreite durch die zu lösende Messaufgabe definiert.

Rainer W. schrieb:

Noch ist nicht klar, was StefanK eigentlich messen möchte oder ob das nur eine Fingerübung [...] sein soll.

Er hat ja ein Beispiel genannt. StefanK schrieb im Beitrag #7880633:

/* ADC Einzelmessung */ uint16_t ADC_Read( uint8_t channel ) { // Kanal waehlen, ohne andere Bits zu beeinflußen ADMUX = (ADMUX & ~(0x1F)) | (channel & 0x1F); ADCSRA |= (1<<ADSC); // eine Wandlung "single conversion" while (ADCSRA & (1<<ADSC) ) { // auf Abschluss der Konvertierung warten } return ADCW; // ADC auslesen und zurückgeben }

...und genau das "warten" will ich vermeiden: while (ADCSRA & (1<<ADSC) ) { // auf Abschluss der Konvertierung warten }

Da ist es egal, ob Übung oder Anwendung, auf diese Art ist es extrem ineffizient.

Florian schrieb:

... Er hat ja ein Beispiel genannt.

Trotzdem bleibt unklar, was er mit

drei ADC-Kanäle (0 bis 2) so schnell wie möglich hinter einander abfragen

meint; klar ist nur, dass es interruptgesteuert erfolgen muss ("warten ist doof!"). Meint er die gesamte Messsequenz, dann wäre es der 'single conversion mode', sollen hingegen die Einzelmessungen möglichst dicht hintereinander erfolgen, wäre es der 'free running mode'.

Wie dem auch sei - also ich fand die Diskussion interessant.

In Free Running ist man natürlich um die Zeit schneller, bis der Interrupt sein Ding gemacht hat. Dafür hat man das Risiko, daß bei langen anderen Interrupts der MUX nicht rechtzeitig umschaltet und man den falschen ADC ausliest. Bei Teiler 16 sind dafür nur 208 CPU-Takte Zeit für alle Interrupts! Ob man das Risiko eingehen will, muß jeder für sich entscheiden. Man sollte aber berücksichtigen, daß der Code durch andere erweitert werden könnte und das Risiko nicht offensichtlich ist.

Hält man sich an die max 200kHz für beste Auflösung, klappt auch die MUX-Umschaltung ohne Übersprechen. Und Single Conversion braucht dann eben einen ADC-Takt mehr (14 bei 16MHz / 128). Ich mag lieber Code ohne Fallgruben.

Moin,

S. L. schrieb:

also ich fand die Diskussion interessant

Ich haette es interessanter gefunden, sich mal etwas cleverere Filter als [1 1 1 1]/4 zu ueberlegen. Evtl. sogar 3 verschiedene Filter mit aehnlichem Frequenzgang, die sich aber in der Gruppenlaufzeit um jeweils 1/3 Tsample unterscheiden - so koennte man so tun, als waeren die 3 Kanaele zur selben Zeit gesampled worden und nicht hintereinander... Aber jeder Jeck ist anders und ich sehe ein, dass DSP aufm attiny13 ein exotisches Hobby ist.

Gruss WK

S. L. schrieb:

Trotzdem bleibt unklar, was er mit

drei ADC-Kanäle (0 bis 2) so schnell wie möglich hinter einander abfragen

meint;

Genau das ist das Problem. Die Kanalumschaltung kostet Zeit, weil der Multiplexer/S&H umgeladen werden muss und deshalb der ADC Clock nicht zu hoch sein darf. Für den Zeitaufwand ist es daher nicht ganz unwesentlich, ob immer sequentiell zwischen den Kanälen umgeschaltet werden muss und dies für die Mittelung 4x wiederholt werden soll, oder ob ein Kanal 4x abgetastet werden kann und erst dann auf den nächsten umgeschaltet werden darf. Steht also äquidistante Abtastung der Einzelkanäle im Vordergrund, weil die Mittelung zur Filterung des Signals erfolgen soll (dann gibt es bessere Filter als den reinen Mittelwert) oder geht es um breitbandiges Rauschen, bei dem das Abtasttheorem sowieso egal ist. Bei einer realen Messaufgabe sollte das Spektrum des zu erfassenden Signales klar sein.

S. L. schrieb:

klar ist nur, dass es interruptgesteuert erfolgen muss

Da es eine Anfängerfrage war, denke ich, dass das für die eigentlich Anforderung nichtmal notwendig ist. Ich habe das so interpretiert, dass es nicht um ein paar Taktzyklen geht, sondern nur darum, den Rest des Programms nicht warten zu lassen, bis das ADC-Ergebnis vorliegt.

Peter D. schrieb:

Und Single Conversion braucht dann eben einen ADC-Takt mehr (14 bei 16MHz / 128).

Warum? Man braucht etwas mehr Zeit, weil man die Wandlung 'von Hand' starten muss, aber doch keinen ganzen ADC-Takt, oder?

Florian schrieb:

Warum? Man braucht etwas mehr Zeit, weil man die Wandlung 'von Hand' starten muss, aber doch keinen ganzen ADC-Takt, oder?

Bei Single Conversion ist der ADC-Teiler durchlaufend, bei Free Running erfolgt durch die Triggerquelle ein Reset, daher sind es 13,5 Takte.

Peter D. schrieb:

Bei Single Conversion ist der ADC-Teiler durchlaufend, bei Free Running erfolgt durch die Triggerquelle ein Reset, daher sind es 13,5 Takte.

Falsch. Im Free Running Mode ist der ADC-Takt durchlaufend und jede Wandlung benötigt EXAKT 13 ADC-Takte und es gibt keine Lücken. Beim Auto Trigger Modus mit einer anderen Quelle (also nicht Free Run) wird der ADC-Vorteiler zurück gesetzt, was praktisch 0,5 Takte Zusatzverzögerung bedeutet. Bei Einzelwandlungen ist der ADC-Takt auch durchlaufend, dann hat man aber prinzipbedingt immer mindestens einen ADC-Takt Lücke zwischen Wandlungen. Steht alles im Datenblatt, wenn gleich der Free Run Modus in der Tabelle fehlt, denn der ist, wenn gleich auch als ein Auto Trigger Modus bezeichnet, anders!

Zusammenfassung:

Free run: 13 Takte Wandlungszeit, lückenloser Betrieb Single conversion: 13 Takte Wandlung, min. 1 ADC-Takt Lücke, 0-1Takt Jitter zwischen Setzen von ADSC und Begin der Messung! Auto Trigger: 13,5 Takte Wandlung, min. 1 ADC-Takt Lücke, jitterfreier Start der ADC-Messung (naja, +/-1 CPU-Takt, wenn die Triggerquelle von außen kommt, z.B. der Komparator. Interne Triggerquellen sind jitterfrei)

Peter D. schrieb:

Bei Single Conversion ist der ADC-Teiler durchlaufend, bei Free Running erfolgt durch die Triggerquelle ein Reset, daher sind es 13,5 Takte.

Danke. Lustigerweise habe ich beim AVR-ADC (bei Single-Conversion) immer mit 14 Takten gerechnet, aber wusste nicht mehr, warum.

S. L. schrieb:

Wie dem auch sei - also ich fand die Diskussion interessant.

Dem kann ich mich nur anschließen, sehr interessant und lehrreich :-) Danke dafür! Manchmal ist es vlt doch nicht so verkehrt, wenn der Hintergrund einer Frage nicht bis ins letzte Detail spezifiziert ist - bleibt mehr Raum für kreative Gedanken.

Trotzdem bleibt unklar, was er mit

drei ADC-Kanäle (0 bis 2) so schnell wie möglich hinter einander abfragen Ich spezifiziere mal nach: Es sollen DC Größen gemessen werden, die sich mit max. 1V/s verändern. Zwei der Messungen sind zusammenhängende Größen: Spannung U1 einer nicht idealen Spannungsquelle, deren in einen Verbraucher eingespeister Strom über einen Shunt (U2) gemessen werden sollen. Wenigstens dieses Pärchen will ich zeitlich eng beieinander liegend erfassen. Für die dritte Spannung U3 gibt es keine zeitlichen Anforderungen, aber sie wird eben wie die anderen mit gemessen und das ganze soll so schnell gehen, wie es der AVR bzw. die SW eben kann. Mittelwerte weil ich auf Grund von Schaltvorgängen rauschbehaftete Signale erwarte. Auf Grund der hier gewonnenen Erkenntnisse sieht so aus, als sei das mit einem ATtiny bei 9,6MHz zumindest zeitlich kein Problem. Auf dem AVR wird es auch nur einen weiteren sehr kurzen Interrupt von TIMER0 geben. Ich habe das im Blick, erwarte aber keine Probleme dadurch.

Nun, auch ich halte viel von "small is beautiful" Sehe ich genauso. Der ATtiny85 wäre natürlich eine gute Rückfalllösung, aber ich habe ein paar 13er rumliegen und den Ehrgeiz, das in 1K zu bekommen.

Und das führt zu meiner nächsten Frage: Mein Code Beispiel von oben verbraucht gefühlt (zu)viel Flash, selbst wenn man alles mit serial.print etc. weglässt. Kann sich das bitte mal jemand ansehen und mir ein paar Hinweise geben, wie das effizienter codiert werden kann?

StefanK schrieb:

Das mit den gebratenen Tauben nicht ;-)

StefanK schrieb:

Mein Code Beispiel von oben verbraucht gefühlt (zu)viel Flash, selbst wenn man alles mit serial.print etc. weglässt. Kann sich das bitte mal jemand ansehen und mir ein paar Hinweise geben, wie das effizienter codiert werden kann?

:-)

Hallo,

eine Randnotiz. Ich würde einen moderneren µC verwenden. Ein ATmega4809 hat einen Akku für 64 Samples. Ein AVRxDB hat einen Akku für 128 Samples. Damit fallen paar Interrupts für die Aufsummierung im "Quellcode" weg.

StefanK schrieb:

S. L. schrieb:

Nun, auch ich halte viel von "small is beautiful"

Sehe ich genauso.

Sie haben (wohlweislich) den mittleren Teil meines Satz weggelassen: "in der Beschränkung zeigt sich erst der Meister". Und 1 KiByte Flash ist nun mal ziemlich beschränkt. Zumal es mit dem Datensammeln alleine ja nicht getan ist: verarbeiten und (in irgendeiner Form) nach draußen geben benötigt auch Programmplatz

aber ich habe .. den Ehrgeiz, das in 1K zu bekommen.

Nur zu ...

Veit D. schrieb:

eine Randnotiz. Ich würde einen moderneren µC verwenden. Ein ATmega4809 hat einen Akku für 64 Samples. Ein AVRxDB hat einen Akku für 128 Samples. Damit fallen paar Interrupts für die Aufsummierung im "Quellcode" weg.

Klar, weil sich die Signale mit "die sich mit max. 1V/s verändern." auch soo schnell ändern und den armen kleinen AVR sooo stressen! ;-)

Hallo Falk,

man muss nicht immer alles gleich zerreden.

StefanK schrieb:

zeitlich eng beieinander liegend

Kannst du das in Zahlen ausdrücken? Es hängt sehr vom Kontext ab, was "eng beieinander liegend" bedeutet. Welche Abtastrate brauchst du? Auf welche Bandbreite sind die Signale vorgefiltert? Welche ist die maximale Änderungsgeschwindigkeit der Signale? Von effektiven Bits und Abtastjitter einmal ganz zu schweigen.

StefanK schrieb:

Mein Code Beispiel von oben verbraucht gefühlt (zu)viel Flash, selbst wenn man alles mit serial.print etc. weglässt. Kann sich das bitte mal jemand ansehen und mir ein paar Hinweise geben, wie das effizienter codiert werden kann?

Wo "oben"? Da sind über 100 Beiträge.

Schlechter Compiler? Es passt spielend in einen Tiny13. Das Serial braucht ca 100Byte, doppelt so viel das Umrechnen in eine Dezimalzahl. Mit seinem Init liegt es unter 600Byte so das noch >400 für das Hauptprogramm frei bleiben.

Sherlock 🕵🏽‍♂️ schrieb:

Ich sehe da keine Chance, das Programm signifikant kleiner zu bekommen.

Sherlock hat die Frage beantwortet, danke. Habe es vermutet. Wenn ich die Messequenz allein ohne serial... in AVR Studio 4.18 mit WinAVR mit -Os kompiliere werden 268 Bytes verbraucht.

Achim H. schrieb:

Schlechter Compiler? Es passt spielend in einen Tiny13. Das Serial braucht ca 100Byte, doppelt so viel das Umrechnen in eine Dezimalzahl. Mit seinem Init liegt es unter 600Byte so das noch >400 für das Hauptprogramm frei bleiben.

Der Compiler ist z.B. WinAVR oder avr-gcc 14. Die Optimierung steht auf -Os. Haben Sie ein Code-Beispiel für das erwähnte Serial? Tx allein würde reichen.

StefanK schrieb:

Haben Sie ein Code-Beispiel für das erwähnte Serial? Tx allein würde reichen.

Das hier?

Beitrag "Re: ADC-Kanäle sukzessive abfragen"

Allerdings muss man dort das normale printf entfernen und die Ausgabe der Zahlen und String neu (kleiner) machen.

Falk B. schrieb:

Das hier?

Hatte vergessen ATtiny13 zu spezifizieren ;-) Leider hat der ATtiny13 keinen UART. Es müsste ein Soft-UART sein.

StefanK schrieb:

Leider hat der ATtiny13 keinen UART.

Weil total veraltet. Vergleiche z.B. mit dem ATtiny412.

StefanK schrieb:

Es müsste ein Soft-UART sein.

Na denn, an die Arbeit :-)

Ohne Quarz mit dem alten AVR8 - wird das funktionieren?

Und StefanK schaut sich ja bereits nach etwas anderem um.

StefanK schrieb:

werden 268 Bytes verbraucht.

Geht Doch ;-) Hier ein Asm Beispiel für Tx (56Byte) Macro Bitdauer
nop DEC r17 BRNE -2 End Macro 'Zeichen in R16, R14 bestimmt Baudrate (17 für 115k oder 233 für 9600 Baud) Psw:
Cli 'Disable Interrupts CBI portb,4 ' #10 Startbit nop
nop
LDI r18,9
sec 'Set Carry (Stopbit) _sw2_loop: 'Schleife Datenbits mov r17,r14 ' Bit-Dauer setzen Bitdauer
ror r16
SBIS SREG,0 ' 1-Bit oder 0-Bit ausgeben? RJMP _SW2_Zero
SBI portb,4
RJMP _SW2_Next _sw2_zero: '0-Bit ausgeben CBI portb,4
nop _sw2_next: nop DEC r18 '1 Bit-Zähler BRNE _SW2_Loop 'nächstes Datenbit ausgeben Sei
mov r17,r14
Bitdauer Ret

Anbei ein einfacher UART-Sender.

1

void sputchar(unsigned char c)

2

{

3

  c = ~c;                                       // complement to send 0 = stop bit(s)

4

  STXD_oe = 1;                                  // output

5

  STXD = MARK;                                  // start bit

6

  for (uint8_t i = 9 + STOP_BITS; i; i--)       // start + data + stop bits

7

  {

8

    _delay_us(1e6 / BAUD);                      // bit duration

9

    if (c & 1)

10

      STXD = MARK;

11

    else

12

      STXD = !MARK;                             // = Space

13

    c >>= 1;                                    // next bits or stop bit(s)

14

  }

15

}

Peter D. schrieb:

Anbei ein einfacher UART-Sender.

Damit die Übertragung nicht gestört wird, sollten besser alle Interrupts gesperrt sein ;-)

Wenn ich mir die Salamischeiben des TO ansehe, muß ich schmunzeln. Aus einer völlig allgemeinen, nichtsagenden Frage ist ein Minimalsystem mit ATtiny13 geworden, was jeglichen sinnvollen Ansatz blockiert. So ein Blödsinn! Aber der TO wird von den hier üblichen Selbstdarstellern immer schön weiter 'gefüttert' ;-)

Moin,

Mi N. schrieb:

Damit die Übertragung nicht gestört wird, sollten besser alle Interrupts gesperrt sein ;-)

Noch besser (vor allem eben auf schwachbruestigen Platformen) waer's, sich gleich mal von Anfang an Gedanken zu machen, was auf dem Ding alles laufen soll und was nicht und was von exaktem Timing profitiert.

Hier waere's wahrscheinlich nicht voellig bekloppt, wenn man den ADC regelmaessig durch einen Timer starten laesst, wie's die HW auch vorsieht. Und dann kann man den Timer auch gleich so einstellen, dass das irgendwie das geforderte UART-Bit-Timing matched. Und dann im ADC-Interrupt nicht nur die Datenverarbeitung und das Multiplexing der Eingaenge machen, sondern halt gucken, ob man nicht noch zufaellig grad mal wieder ein Bit auf den UART-TX-GPIO schicken sollte (Und wenn man ganz crazy drauf ist, koennte man damit sogar auch den Bitratenteiler fraktionell einstellbar machen, wenn man z.b. MIDI oder sonstwas krummratiges machen will).

Also so ungefaehr das Gegenteil von dem, wie der TO vorgeht.

Gruss WK

Mi N. schrieb:

Damit die Übertragung nicht gestört wird, sollten besser alle Interrupts gesperrt sein ;-)

Welche erwartest du denn? Interrupts kommen nicht aus heiterem Himmel.

Rainer W. schrieb:

Welche erwartest du denn? Interrupts kommen nicht aus heiterem Himmel.

Verstand auch nicht.

Mi N. schrieb:

Damit die Übertragung nicht gestört wird, sollten besser alle Interrupts gesperrt sein ;-)

Kann man so generell nicht sagen, es hängt stark von der Baudrate ab. Bei 9600 Baud wären das 10.000 CPU-Zyklen Interruptsperre. Man könnte noch ein define hizufügen, um wahlweise mit ATOMIC_BLOCK(ATOMIC_FORCEON) zu klammern.

Peter D. schrieb:

Kann man so generell nicht sagen, es hängt stark von der Baudrate ab.

Oder anders formuliert: es hängt davon ab, ob man Glück oder Pech hat ;-)

All diese vielen Worte und Beiträge, weil der TO eingangs nicht klar und deutlich sein Problem formuliert hat und zu geizig ist, einen µC zu verwenden, der der Aufgabe gerecht wird, ohne auf Glück angewiesen zu sein.

Peter D. schrieb:

Damit die Übertragung nicht gestört wird, sollten besser alle Interrupts gesperrt sein ;-)

Kann man so generell nicht sagen, es hängt stark von der Baudrate ab. Bei 9600 Baud wären das 10.000 CPU-Zyklen Interruptsperre. Man könnte noch ein define hizufügen, um wahlweise mit ATOMIC_BLOCK(ATOMIC_FORCEON) zu klammern.

Ich hab mal einen hybriden Soft-Uart programmiert, der die Daten mittels Output Compare Funktion und dazugehörigem Interrupt sendet. Der blockiert keine anderen Interrupts und ist auch relativ tolerant gegenüber anderen, kurzen Interrupts.

Beitrag "Re: Baugruppe gesucht: Image Player mit HDMI-Ausgang, steuerbar"

Schöne Lösung. Traumhaft für kleine Bautraten (keine Wartezeit), bei 340kBaud darf natürlich kein (Adc)Int mehr dazwischen 'funken' ;-)

Achim H. schrieb:

Traumhaft für kleine Bautraten

Wie bringst du das mit dem Einheitenzeichen 'Bd' für die Symbolrate zusammen? Benannt ist die Einheit nach dem Namensanfang von Émile Baudot. https://de.wikipedia.org/wiki/%C3%89mile_Baudot

Ich sag's ja ..... kaum sind 150 Beiträge geschrieben, schon ist das Thema immer noch nicht durch .....

Wastl schrieb:

.... und 100 Beiträge generieren/provozieren. Tagelang warten bis einem die gebratenen Tauben in den Mund fliegen.

@Sherlock, @ von Achim H. (pluto25), @Peter D. (peda) und @Falk B.

Danke für das UART-Beispiel! Ich sehe es mir auf jeden Fall an. Ich will jetzt niemanden schockieren, aber mein SW-UART muss ohne TIMER auskommen, da dieser für PWM benutzt ist.

@Falk B. Ihr Freerunning Beispiel hat mich entscheidend weitergebracht. Nochmals besten Dank dafür. Ich habe Anmerkungen und Fragen dazu. Können wir uns darüber austauschen?

StefanK schrieb:

Ich habe Anmerkungen und Fragen dazu. Können wir uns darüber austauschen?

Die kannst du einfach hier im Forum stellen. Dann lernen ggf. andere noch was. Oder wenn es privat sein soll, musst du mir eine Nachricht schreiben. Oben auf meinen Namen clicken.

StefanK schrieb:

aber mein SW-UART muss ohne TIMER auskommen, da dieser für PWM benutzt ist.

Das Eine schließt das Andere nicht aus. Mein Hybrid-UART nutzt den Timer freilaufend. Eine PWM macht das auch. Und kann es sein, daß du ohne Not immer mehr Einschränkungen erfindest? Es gibt TONNENWEISE AVRs und andere Mikrocontroller zum SPOTTPREIS! Da gibt es keine Sekunde die Notwendigkeit, ausgerechnet die ollen Attiny13 bis zum Erbrechen auszureizen.

@Falk B. Können wir uns über den Code Ihres ADC-Freerunning Beispiel austauschen? Oder sind Sie daran nicht weiter interessiert?

StefanK schrieb:

@Falk B. Können wir uns über den Code Ihres ADC-Freerunning Beispiel austauschen? Oder sind Sie daran nicht weiter interessiert?

Er ist wohl eher nicht an einer kuscheligen zweisammen Session interessiert.

Und er hat völlig recht damit dass es anständiger wäre dies im Forum zu diskutieren weil das Forum ja allen helfen soll.

Ich spezifiziere nach: Können wir uns über den Code des ADC-Freerunning Beispiel von Falk B. in diesem Forum austauschen?