Atmega 8 / 16 ADC mit 2 Kanälen

[MichaF]

@Gock: Klingt total logisch. Ist auch bei den meisten AVRs so. Ein Blick ins Datenblatt bringt aber frecherweie zum Vorschein, das man das beim Mega16 tatsächlich anders gelöst hat. Da gibt es nur ein ADATE == "ADC Auto Trigger Enable". Und was diesen Trigger auslöst ist dann wiederum im SFIOR einzustellen. Ich war auch überrascht, eigentlich dachte ich den ADC der Megas recht gut zu kennen - man lernt eben nie aus

Ändert imho nichts daran, das der FR Mode keinen Vorteil bringt wenn man in Controller Zeiten gerechnet nur all Schaltjahr eine Messung braucht. Insbesondere beim Kanalwechsel muss man dann doch wieder einige beachte, was einen im Single Conversion Mode nicht zu interessieren braucht. FR macht Sinn wenn man z.B. ein Signal kontinuierlich sampeln muss. Aber das erfordert dann eine sehr angepasste Programmierung, um die anfallende Datenmenge auch verarbeiten zu können.

[Gock]

Mega16 hab ich noch nie benutzt. Ich beschränke mich auf so wenige wie möglich, weil auch ich schon bemerkt habe, wie inkompatibel die AVRs auch bei sehr ähnlichen Modellen sein können.
Gruß

[Destrono]

Hallo,
vielen Dank für Eure Hilfe. Jetzt, wo ich auf den Single Conversion Mode umgestiegen bin, geht es einwandfrei. An meiner main.c (wo sich die beiden if Schleifen befinden) musste ich nicht einmal was verändern. Der Code von MichaF zur Initialisierung und der Adc abfrage läuft auch einwandfrei.
Ich habe sogar die Schwankungen, die beim Bestlasten des Portpins entstanden sind, raus bekommen, indem ich einen Kondensator am Messpin angeschlossen haben. Das hat vorher auch nicht funktioniert.
Ich wüsste trotzdem ganz gerne, warum das Ganze im Freerunning Mode zuvor nicht funktioniert hat. Denn in meinem ersten Code konnte ich bis auf ein paar "Schönheitsfehler" immer noch keinen gravierenden Fehler finden. Vielleicht muss man den Adc im Freerunning Mode erst anhalten, bevor man den Kanal wechsel ?

MfG
Destrono

[MichaF]

Dein Code war schlicht und ergreifend falsch. Vom ADIF Bit hat man die Finger zu lassen wenn man nicht genau weiß was man tut, das ADSC ist dein Freund. Vom Free Running Mode ebenso. Das Timing kann hierbei sehr komplex werden. Aus diesem Grund kann dir auch keiner genau sagen warum dein Code nicht funktioniert hat. Davon abgesehen das er aus oben genannten Gründen verkehrt ist kommt es darauf an, wie oft du deine read Funktionen aufgerufen hast.

[chientech]

Hi,
ich meine mal gelesen zu haben, dass die AVR's 'pipelining' betreiben.
http://de.wikipedia.org/wiki/Pipeline_%28Prozessor%29

soll heißen, dass der AVR beim einlesen des ADCSRA evtl. auf einen alten stand von ADCSRA zugreift. Bin mir allerdings nicht 100% sicher. Hier im RNetz kennt sich sicher jemand besser aus und kann erklären warum dass in diesem Fall nicht zutrifft.

Aber schalt mal die Optimirung aus und probier das:

ADCSRA |= (1<<ADIF); //reset Flag
;
;
;
;
while (!(ADCSRA & (1<<ADIF))){}

mfg ch

[MichaF]

Hier im RNetz kennt sich sicher jemand besser aus und kann erklären warum dass in diesem Fall nicht zutrifft.

Nunja, auch wenn ich nicht gerade der Experte auf diesem Gebiet bin, versuche mich trotzdem mal eine Antwort

Praktisch jeder halbwegs moderne Controller verfügt mindestens über eine zweistufige Pipeline. So auch der AVR. Dabei handelt es sich aber nur um eine relativ simple fetch & execute pipeline. In der ersten Stufe wird der Befehl gelesen, in der 2. stufe wird er ausgeführt. Wobei die 2. Stufe innerhalb eines Taktes die Daten holt, durch die ALU jagt, und sie wieder zurück schreibt. Veraltete Daten sollten zumindest bei Befehlen die nur einen Takt brauchen, und das sind auf dem AVR sehr viele, nicht vorkommen. Wie das bei umfangreicheren Befehlen aussieht vermag ich nicht zu sagen. Aber selbst wenn die ADC Daten jetzt 4 Takte "zu alt" sind... das sollte nun wirklich nicht der Grund für eine Fehlfunktion sein.

[chientech]

Sind wir nicht alle Experten

Praktisch jeder halbwegs moderne Controller verfügt mindestens über eine zweistufige Pipeline. So auch der AVR. Dabei handelt es sich aber nur um eine relativ simple fetch & execute pipeline. In der ersten Stufe wird der Befehl gelesen, in der 2. stufe wird er ausgeführt. Wobei die 2. Stufe innerhalb eines Taktes die Daten holt, durch die ALU jagt, und sie wieder zurück schreibt.

OK, ich bin bis jetzt davon ausgegangen, dass die AVR's 1Takt=1Operation nur im Mittel auf Grund von Pipelining erreichen.


@Destrono hast du das mal probiert.

Aber schalt mal die Optimirung aus und probier das:

ADCSRA |= (1<<ADIF); //reset Flag
;
;
;
;
while (!(ADCSRA & (1<<ADIF))){}