Abtastzeit ADC

BoJack schrieb:
> while(1)
> {
> adcval = ADC_Read(0);
> PINB = (1<<PB0);
> ...
> }

Außer, daß du weisst, wie man effektiv toggelt, sagt das ja nun gar 
nichts aus.

> ADC_Read(0); Was ist das das? Arduino-Zeugs?

Was du auf deinem Oszi siehst, ist nicht die Zeit der Wandlung, sondern 
die Ausführungszeit dieser ominösen Funktion. Daß die Arduino-Funktionen 
einem das erwartete Timing versauen, ist ja nun nichts neues.

Du mußt deine Wandlung mit Interrupt komplett selbst programmieren. Dann 
wirst du in der ISR auch das angestrebte Timing sehen.

Markus schrieb:
>> PINB = (1<<PB0);
>
> Das macht bestenfalls eine einzige Flanke, nicht mehrere.

Aber sicher macht es das.

BoJack schrieb:
> Daher wollte ich fragen, ob mir jemand einen Hinweis geben kann, wo mein
> Rechen- bzw. Denkfehler liegt und wie ich vielleicht den Wert
> rechnerisch, sowie Messtechnisch ermitteln kann.

Die Rechnung ist für mich erstmal plausibel.
Was mir als mögliche Ursachen einfällt:
- läuft der µC wirklich mit 16MHz?
- Zeitbedarf der Software. Das hängt auch davon ab, wie der ADC 
initialisiert ist bzw. wie ADC_Read() arbeitet.

Gruß Dietrich

BoJack schrieb:
> // 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

Das ist zwar idiotensicher, aber nicht sehr effektiv. Der ADC muß 
ständig laufen und die Abfrage muß in einer ISR erfolgen.

BoJack schrieb:
> wie kann ich die Taktfrequenz des Controllers prüfen?

Indem du dir die Einstellungen der Fuses ansiehst. Wenn du da noch nie 
etwas verändert hast, läuft der Controller mit 1 MHz.

Überprüfen kannst du das mit einer blinkenden LED.

1

while(1)

2

{

3

  PINX = (1 << Y);

4

  _delay_ms(500);

5

}

Wenn das Blinken im Sekundentakt erfolgt, stimmt die tatsächliche 
Taktfrequenz mit deinen Erwartungen überein. Kannst natürlich auch ein 
kürzeres toggeln auf dem Oszi anzeigen.

BoJack schrieb:
> Wie sollte ansonsten getoggelt werden? mit bitweisem xor
> vermutlich oder?

Da hat einer noch nicht mitbekommen, daß die Erde sich nach dem Launch 
des Atmega8 weitergedreht hat.

Sascha schrieb:
> PINB = (1<<PB0);
>
> Das ist unverständlicher Code.

Da kann der Code aber nichts dafür, denn der ist einwandfrei, und an der 
Stelle absolut richtig.

Oliver

Sascha schrieb:
> Das ist unverständlicher Code. Solltest du in Zukunft vermeiden. Lieber
> ganz normale Bitoperationen.

Warum soll man das vermeiden? Weil du es nicht verstehst?

BoJack schrieb:
> wie kann ich die Taktfrequenz des Controllers prüfen?

z.B. mit:

1

#define F_CPU 16000000

2

#include <avr/io.h>

3

#include <util/delay.h>

4

5

int main()

6

{

7

  DDRB = ( 1 << PB4 );

8

9

  while( 1 )

10

  {

11

    PORTB |= ( 1 << PB4 );

12

    _delay_ms( 1000 );

13

    PORTB &= ~( 1 << PB4 );

14

    _delay_ms( 1000 );

15

  }

16

}

Hier muss PB4 jede Sekunde toggeln. Wenn das nicht stimmt ist F_CPU 
nicht der tatsächliche Wert des µC-Taktes.

Gruß Dietrich

Sascha schrieb:
> Code sollte unabhängig von der Hardware Sinn ergeben.

Was bei Code, der Hardware direkt ansteuert, aber nunmal nicht geht. Und 
ja, da muß man dann dazu das Datenblatt lesen...

Oliver

Mein grosses V. schrieb:
> Sascha schrieb:
>> Das ist unverständlicher Code. Solltest du in Zukunft vermeiden. Lieber
>> ganz normale Bitoperationen.
>
> Warum soll man das vermeiden? Weil du es nicht verstehst?

Mein Vorschlag zur Entspannung: man könnte ja im Kommentar vermerken, 
dass diese Operation bei diesem µC den Pin toggelt. Dann versteht ein 
fremder Leser dies auch.

Gruß Dietrich

BoJack schrieb:
> Das heißt nach jeder Wandlung wird ein
> Interrupt ausgelöst, in welchem ich dann den Pin toggeln kann und dieser
> sollte dann am Oszi auch die rechnerischen 104µs anzeigen.

Richtig. Der ADC lässt sich damit sogar als Timer benutzen.

Sascha schrieb:
> Code sollte unabhängig von der Hardware Sinn ergeben.

Was hast du denn gegen den Code? Da wird etwas in ein Register 
geschrieben. Was das bewirkt, ist von der spezifischen Hardware abhängig 
und steht im Datenblatt. Also, was ist dein Problem?

Wobei es richtig eingesetzt natürlich

1

PINB |= (1<<PB0);

lauten muß.

Zuerst

Abtastzeit ist ein etwas unglücklich gewählter Begriff. Ohne gesonderte 
Definition hätte ich damit eher die sample and hold Zeit darunter 
verstanden.

Richtig ist:

Wenn der ADC schon kofiguriert und aktiviert ist, so benötigt die reine 
Wandlung des Analogwertes 13 ADC-Takte bis die Informatiion im 
ADC-Register steht. Was dann die ISR etc so macht, kann man so pauschal 
nicht vorhersagen. Um es exakt durchzugehen müsste man schon auf 
Maschinencode bzw Assembler gehen. Und auch da wird es schwierig.

Ich würde ohne Oszi "messen".

Du kannst einen Timer mitlaufen lassen und seinen Wert zu Beginn der 
Wandlung und unmittelbar danach auslesen. Die Differenz ist dann deine 
Dauer, inklusive eines kleinen Overheads für die Auswertung des Timers.

Alternativ, so ähnlich wie du es nun machst mit dem Toggeln.

Gehe in den free running modus und lasse die ISR zusätzlich eine 
Variable hochzählen. Nach einer bestimmten Zeit wertest du diese 
Variable aus und kannst die Zeit pro Wandlung berechnen. Dazu muß die 
Variable natürlich einen hinreichend großen Wertebereich haben, damit es 
nicht zu einem überlauf kommt.

Du kannst auch eine Schleife x-mal eine Wandlung durchführen lassen und 
mit einem Timer wie oben mitlaufen lassen und damit die für die ganze 
Schleife benötigten Takte zählen. Auch hier ist natürlich wieder zu 
beachten, daß der Timer einen Überlauf produzieren kann. Den kann man 
aber auch wieder mitzählen.

Carsten R. schrieb:
> Richtig ist:

Schön, was du da schreibst. So schön wie unsinnig.

Der ADC-IRQ kommt alle 104µs. Diese 104µs entsprechen ca. 1600 
CPU-Takten. Das ist die Zeit, die zur Verfügung steht, um den aktuellen 
Wert zu verarbeiten. Dann kommt nämlich der nächste. Aber 1600 Takte 
sind verdammt viel.

Um das auf dem Oszi zu zeigen, setzt man am Anfang und am Ende der ISR 
jeweils ein Toggle, ausgehend von Port = Low und bekommt eine PWM 
angezeigt. Die Periode beträgt dabei 104µs, also knapp 10KHz und der 
"Duty", der die Dauer der ISR repräsentiert, sollte, wenn der Controller 
sich auch noch um andere Dingen kümmern soll, möglichst kurz sein.

BoJack schrieb:
> ADCSRA |= (1<<ADEN)|(1<<ADPS2)|(1<<ADPS1)|(1<<ADIE);

Das ist Prescaler = 64. Passt doch.

1

int main(void)

2

{

3

   DDRB = 0x01;

4

   ADMUX |= (1<<REFS0) | (1<<MUX0);

5

   ADCSRA |= (1<<ADEN)|(1<<ADPS2)|(1<<ADPS1)|(1<<ADIE)|(1 << ADATE);

6

   //ADATE = Auto Trigger Enable

7

   sei();

8

   ADCSRA |= (1<<ADSC);

9

}

10

ISR(ADC_vect)

11

{

12

  unsigned int adc = ADC:

13

  PINB = (1<<PB0);

14

  _delay_us(5);

15

  PINB = (1<<PB0);

16

}

Damit erhälst du an PB0 eine PWM mit ca. 10% Duty Cycle. Das Delay 
simuliert dabei die Zeit für die Bearbeitung des gemessenen Wertes.

Der Interrupt kommt alle 52µs.

Auf dem Oszi siehst du jetzt grün auf grau, wann etwas passiert und wie 
lange das dauert.

Mein grosses V. schrieb:
> Carsten R. schrieb:
>> Richtig ist:
>
> Schön, was du da schreibst. So schön wie unsinnig.
>
> Der ADC-IRQ kommt alle 104µs. Diese 104µs entsprechen ca. 1600
> CPU-Takten. Das ist die Zeit, die zur Verfügung steht, um den aktuellen
> Wert zu verarbeiten. Dann kommt nämlich der nächste. Aber 1600 Takte
> sind verdammt viel.

Da hast du dich etwas weit aus dem Fenster gelehnt. Ich schrieb daß es 
13 ADC-Takte sind, nicht CPU-Takte Da kommt noch der Prescaler hinzu. 
Damit bestätigte ich nur die überschlägige Rechnung im Eingangspost. So 
findet man es auch im Datenblatt.

Deinen Daten entsprechend hast du einen CPU-Takt von 16 MHz  und den 
Prescaler auf maximum, nämlich 128. Das ergibt 13*128=1664 CPU-Takte pro 
Wandlung, bzw rund 9615 Wandlungen pro sekunde im free running Modus.

Den Prescaler kann man verringern, insbesondere wenn der CPU-Takt 
niedriger ist, und somit die Geschwindigkeit des ADC erhöhen. Allerdings 
sollte dabei beachten, daß der daraus resultierende ADC-Takt im Rahmen 
bleibt. Wird er zu hoch, werden zuerst die letzten Bits ungenau. Wird er 
sehr hoch, so verläßt man die Spezifikation. Was das bedeutet sollte 
jedem klar sein. Die Spezifikationen stehen im Datenblatt.

Wenn die ISR innerhalb dieser 1664 Takte abgearbeitet werden kann, so 
kann beim free running Modus die Softwareauswertung parallel zur 
nächsten Hardwarewandlung erfolgen. Das heißt die 
Hardwaregeschwindigkeit kann ausgereizt werden.

Ist die Software komplexer, so ist sie der begrenzende Faktor.

Geht es um einzenle ADC-Wandlungen, so addieren sich Hardware- und 
Softwareausführungszeiten, da sie nacheinander ablaufen. Um dann die 
Latenz exakt auszurechnen, müßte man jeden Maschinenbefehl der Software 
kennen. Eine Hochsprache hilft da nicht.

Oder man mißt per Oszi bzw. zählt per Timer die Takte, auch wenn 
letzteres einen kleinen zusätzlichen Softwareoverhead bedeutet.

Die Frage ist was man wissen will.

Die Latenz, bis die Software das Ergebnis ausspuckt oder die maximale 
Samplingrate, die ausgewertet werden kann?