Spannung gegen Vref messen, ohne Spannungsteiler Verständnisproblem

Bart schrieb:
> Hallo,
> will hier mit einem tiny eine Spannugn messen und diese Spannung als
> Vref benutzen, wohingegen ich aktiv vref intern messe...

du meinst die interne Bandgapspannung

> volt := ((1024 * 10) *10) DIV volt;

Keine Ahnung, wo da die 10 herkommen.

Aber das Prinzip ist doch einfach.
Die Höhe der Banggap Spannung kennst du, bzw. die hast du mal 
ausgemessen. Die ist immer gleich und ändert sich nicht.

d.h. wenn deine Referenzspannung 5V wäre und du weißt, dass deine 
Bandgap-Spannung zb 1.36V groß ist, dann müsste der ADC welches Ergebnis 
bringen, wenn du mit der Referenz die Bandgap vermisst?

1

    5     .....   1024

2

    1.36  .....    x

3

  ---------------------

4

         1.36 * 1024

5

    x = ------------ = 278

6

              5

d.h. du würdest erwarten, dass der ADC einen Wert von 278 raus wirft.

Jetzt wirft aber der ADC keine 278 raus, sondern 354.
Wie gross war daher die "Referenzspannung"?
(einfach die Formel umstellen)

1

          1.36 * 1024

2

   354 = --------------

3

              VRef

4

5

           1.36 * 1024

6

   VRef = ------------- = 3.93V

7

               354

Damit also der ADC bei einer zu messenden Spannung von 1.36V ein 
Ergebnis von 354 bringt, muss die Referenzspannung (die du eigentlich 
feststellen willst) also 3.93V groß gewesen sein.

> leider wird diese Möglichkeit hier gar nicht erwähnt
Weil das eigentlich nicht so schwer ist, das selber drauf zu kommen, 
wenn man erst mal überrissen hat, dass es eine Band-Gap Spannung gibt, 
deren Höhe bekannt und konstant ist und die man vermessen kann.
Im Tutorial wird nicht alles bis ins kleinste vorgekaut. Ein bischen was 
muss man schon selber können

Bart schrieb:
> irgendwie messe ich außen am VREF PIn aber auch nur 0V

Was, genau, willst du eigentlich machen?


Die Sache mit der BandGap Vermessung macht man, wenn man die 
Versorungsspannung des µC vermessen möchte.
Dann nimmt man die Versorgungsspannung als Referenzspannung und lässt 
die bekannte BandGap Spannung vermessen.
Aus dem Ergebnis kann man zurückrechnen, wie hoch die Referenzspannung 
und damit die Versorungsspannung war.


Wenn du das nicht willst (die Versorgungsspannung vermessen), dann 
wählst du ganz normal eine der Möglichkeiten als Referenzspannung, 
machst eine Messung und wendest den Dreisatz an um aus der bekannten 
Referenzspannung und dem Ergebnis vom ADC die Spannung am Messeingang zu 
errechnen. Aklso das ganz normale Prozedere, wie es in praktisch jedem 
Tutorial beschrieben ist.

ich verstehe es immer noch nicht, am AREF sollte die interne gewählte 
Aref anliegen oder extern angelegt werden, du willst die interne nutzen, 
also kannst du die an AREF messen !

aber ohne einen analog IN zu nutzen wüsste ich nicht wie man messen will 
!

Es gibt doch nur den analog IN über die AMUX Auswahl !

Ich wüsste keinen internen Weg zu analog IN

Joachim B. schrieb:
> Ich wüsste keinen internen Weg zu analog IN

Der Multiplexer endet nicht mit den externen Pins. Intern schaltbar ist 
u.a. die Bandgap-Spannung von üblicherweise 1,1V.

1

//Atmega48

2

//Ref = AVcc, Channel = Bandgap

3

ADMUX = (1 << REFS0) | (1 << MUX3) | (1 << MUX2) | (1 << MUX1);

4

//Prescaler fuer 1MHz

5

ADCSRA = (1 << ADEN) | (1 << ADPS1) | (1 << ADPS0);

6

7

int GetVcc(void)

8

{

9

  ADCSRA |= (1 << ADSC);

10

  while(ADCSRA & (1 << ADSC));

11

  return 1023 * 1100 / ADC; //Vcc in mV

12

}

mfg.

der alte Hanns schrieb:
> und die 1. Messung verwerfe

muss nicht immer oder öfter ein dummy Read ausgeführt werden, habe ich 
noch so in Erinnerung

der alte Hanns schrieb:
> Ich bin jetzt auch etwas irritiert; derzeit klappt es bei mir nur
> (ATmega1284P), wenn ich statt der Abfrage auf ADSC ein Warten mit ca.
> 100 ms einbaue

kann ich mir eigentlich kaum vorstellen.
Code?

Thomas Eckmann schrieb:
> Der Multiplexer endet nicht mit den externen Pins. Intern schaltbar ist
> u.a. die Bandgap-Spannung von üblicherweise 1,1V.

daraus werde ich nicht schlauer

das ich die REF 1,1V wählen kann weiss ich doch

nur wenn kein IN gewählt wird, warum selektierst du die AMUX ?

Joachim B. schrieb:
> der alte Hanns schrieb:
>> und die 1. Messung verwerfe
>
> muss nicht immer oder öfter ein dummy Read ausgeführt werden, habe ich
> noch so in Erinnerung

es kann sein, dass die erste Messung nach einem Kanalwechsel nicht so 
prickelnd ist. Das hängt hauptsächlich von der Eingangsimpedanz zum ADC 
ab. Dann kann sich die S&H Schaltung u.U. nicht schnell genug auf die zu 
messende Spannung einstellen.

Karl Heinz schrieb:
> Joachim B. schrieb:
>> der alte Hanns schrieb:
>>> und die 1. Messung verwerfe
>>
>> muss nicht immer oder öfter ein dummy Read ausgeführt werden, habe ich
>> noch so in Erinnerung
>
> es kann sein, dass die erste Messung nach einem Kanalwechsel nicht so
> prickelnd ist. Das hängt hauptsächlich von der Eingangsimpedanz zum ADC
> ab. Dann kann sich die S&H Schaltung u.U. nicht schnell genug auf die zu
> messende Spannung einstellen.

AUs dem Datenblatt

1

When the bandgap reference voltage is used as input to the ADC,

2

it will take a certain time for the voltage to stabilize. If not

3

stabilized, the first value read after the first conversion may

4

be wrong.

Joachim B. schrieb:
> das ich die REF 1,1V wählen kann weiss ich doch

Nein.
Referenz ist Vcc. Gemessen wird die konstante Bandgap-Spannung von 1,1V.

Es wird eine konstante Spannung gegen eine Unbekannte gemessen. Je 
niedriger der ADC-Wert, desto höher ist diese Spannung.

Ein bisschen von hinten durch die Brust ins Auge:

1023 * 1100 / ADC; //Vcc in mV

mfg.

Karl Heinz schrieb:
> es kann sein, dass die erste Messung nach einem Kanalwechsel nicht so
> prickelnd ist.

bzw. nach dem Einschalten vom ADC ! erst mal dummy READ

Joachim B. schrieb:
> Thomas Eckmann schrieb:
>> Der Multiplexer endet nicht mit den externen Pins. Intern schaltbar ist
>> u.a. die Bandgap-Spannung von üblicherweise 1,1V.
>
> daraus werde ich nicht schlauer
>
> das ich die REF 1,1V wählen kann weiss ich doch
>
> nur wenn kein IN gewählt wird, warum selektierst du die AMUX ?

Jetzt verwirrst du uns.
Wovon redest du überhaupt?

Fange nwir mal an mit: von welchem µC redest du?

der alte Hanns schrieb:
> (1<<ADPS2)+(1<<ADPS1)+(1<ADPS0)  ; /128
Läuft dein Controller mit 20MHz?

Je länger, je lieber ist nicht die Lösung, sondern der richtige 
Prescaler.

mfg.

der alte Hanns schrieb:


>   lds tmp0,ADCSRA
>   sbrc tmp0,ADSC
>  rjmp pc-3

passt doch.
Weiß gar nicht was du hast

Karl Heinz schrieb:
> Fange nwir mal an mit: von welchem µC redest du?

ich grad vom m1284p Datenblatt gerade offen !

der TO vom Tiny, aber so verschieden sollten die doch nicht sein.

Bis jetzt habe ich ADC immer über einen ADCin 0-7 gemacht, wie soll der 
interne Weg zur Bandgap geschaltet werden ohne einen ADCin zu wählen ?

Mister Jones schrieb:

> Naja...wie gesagt...steht leider nicht im Wiki

Aber es steht im Datenblatt.
Und DAS ist deine Bibel.

Joachim B. schrieb:
> Karl Heinz schrieb:
>> Fange nwir mal an mit: von welchem µC redest du?
>
> ich grad vom m1284p Datenblatt gerade offen !
>
> der TO vom Tiny, aber so verschieden sollten die doch nicht sein.
>
> Bis jetzt habe ich ADC immer über einen ADCin 0-7 gemacht, wie soll der
> interne Weg zur Bandgap geschaltet werden ohne einen ADCin zu wählen ?

Tabelle 23.4 auf Seite 259
Ganz unten, die vorletzte Zeile in der Tabelle

Joachim B. schrieb:
> ich grad vom m1284p Datenblatt gerade offen !

Dann guck doch mal in die Tabelle unter der Registerbeschreibung von 
ADMUX.

mfg.

Karl Heinz schrieb:

>> Bis jetzt habe ich ADC immer über einen ADCin 0-7 gemacht, wie soll der
>> interne Weg zur Bandgap geschaltet werden ohne einen ADCin zu wählen ?
>
> Tabelle 23.4 auf Seite 259
> Ganz unten, die vorletzte Zeile in der Tabelle

Siehe Bild

der alte Hanns schrieb:
> Er läuft mit 22.1184 MHz.

Heizer!

mfg.

Karl Heinz schrieb:
> Siehe Bild

das habe ich schon gesehen aber ich misstraue den Datenblättern immer 
etwas weil ich mir eine Differenzialmessung mit beide Spannungen an 
einem PIN so schlecht vorstellen kann

01000 !

eine ADC0 nach ADC1 Messung habe ich dagegen schon gemacht

01001

aber wie geht eine diff Messung mit beide Spannungen an ADC0 ????

wie wir schon gelernt hatten strotzen die Datenblätter nur so von C & P 
Fehlern......

Joachim B. schrieb:
> aber wie geht eine diff Messung mit beide Spannungen an ADC0 ????

Indem man einfach misst.

Joachim B. schrieb:
> wie wir schon gelernt hatten strotzen die Datenblätter nur so von C & P
> Fehlern......

Teilweise ja. In diesem Fall aber ganz und gar nicht.

Diese Messung dient dazu, den internen Offset zu ermitteln, um ihn bei 
der Ergebnisrechnung mit einzubeziehen. Das steht aber auch im 
Datenblatt.

mfg.

Thomas Eckmann schrieb:
> Joachim B. schrieb:
>> aber wie geht eine diff Messung mit beide Spannungen an ADC0 ????
>
> Indem man einfach misst.

wie denn ?

ich klemme 2 ! Spannungen einer DIFF Messung an ADC0

01000 und messe das 10-fach verstärkte Signal ?

das geht nicht in meinen Kopf !


für mich ist eine Differenz von 2 Spannungen auf einen Pin immer NULL ! 
auch 10x verstärkt ist das NULL

Joachim B. schrieb:
> Karl Heinz schrieb:
>> Siehe Bild
>
> das habe ich schon gesehen aber ich misstraue den Datenblättern immer
> etwas weil ich mir eine Differenzialmessung mit beide Spannungen an
> einem PIN so schlecht vorstellen kann

Kommt eben als Ergebnis 0 raus.
Zumindest sollte es das, wenn der zugeschaltete Verstärker keinen 
Offsetfehler hat.
Auf die Art kann man den messen.

Joachim B. schrieb:
> für mich ist eine Differenz von 2 Spannungen auf einen Pin immer NULL !
> auch 10x verstärkt ist das NULL

Ja. In einer idealen Welt mit idealer Elektronik wäre das so.

In der Realität ist aber noch etwas zwischen den Pins und dem 
eigentlichen ADC.

Wer misst, misst Mist. Das gilt hier auch.

Die Spannung, die man mit ADC0 gegen ADC0 misst, ist genau dieser Mist. 
Dieser Mist verfälscht aber auch die Messung gegen andere Eingänge.

Durch diese Messung ermittelt man diesen Mistfaktor.

mfg.

Karl Heinz schrieb:
> Kommt eben als Ergebnis 0 raus.
> Zumindest sollte es das, wenn der zugeschaltete Verstärker keinen
> Offsetfehler hat.
> Auf die Art kann man den messen.

Thomas Eckmann schrieb:
> Durch diese Messung ermittelt man diesen Mistfaktor.

also doch nicht nutzbar für eine Differenzmessung

OK als Fehlerfinder verstehe ich das jetzt, DANKE @ euch beiden !

Bart schrieb:
> hm...geht irgendwie immer noch nciht..

Dann  zeig halt mal dein ganzes Machwerk, auch wenn die wenigsten Freude 
daran haben werden, bei sowas ...

1

function Adc_Read_(channel : byte) : word;

2

begin

3

 ADMUX := channel;

4

 ADMUX.0 := 0;    //ausklammern?

5

 ADMUX.1 := 1;    // ausklammern?

6

 ADMUX.2 := 1;

7

 ADMUX.3 := 1;

8

 ADMUX.4 := 1;

9

 ADMUX.5 := 0;

10

 ADMUX.6 :=0;

11

 ADMUX.7 :=0;

12

 //ADCSRA := %11000111;

13

 ADCSRA := 199;

14

  while ADCSRA.6 = 1 do nop;

15

  Lo(result) := ADCL;

16

  Hi(result) := ADCH;

17

end;

... erst mal die Bits den Bedeutungen zuordnen zu müssen.
Kannst du denn keine symbolischen Bitnamen benutzen?

Aber eines gleich vorweg.
Wenn du ADMUX den Kanal zuweist und dann an den Bits rumpfiremelst, was 
denkst du welchen Sinn dann die Zuweisung des Kanals überhaupt hatte?

(Und sowas

1

 ADCSRA := 199;

ist sowieso der Supergau schlechthin. Das als Dezimalzahl 
hinzuschreiben, schon alleine dafür verdienst du, dass es nicht 
funktioniert.

Bart schrieb:
> wie gesagt...durch die Tests ist das mittlerweile
> zerfleddert...mal HEx
> mal Bit mal dezimal..um Fehlermöglichkeiten zu testen..aebr nichts hilft
> halt..
> Das gleiche natürlich beim  admus:= chancell...normalerweise ist das
> natürlich so gedacht, das ich nur den Kanal angeben muss..zu testzwecken
> eben deaktivert..

Die Ausrede zählt überhaupt nicht.

Dafür

1

 ADCSRA := 199;

machst du zehn Mal Kopf -> Tisch.

mfg.

> Die Ausrede zählt überhaupt nicht.


Abgesehen davon.
Welche Fehlermöglichkeiten sollen das sein? Das der Compiler eine 
Hexzahl nicht richtig umsetzt?
Träum weiter und schieb nur immer schön dem Compiler die Schuld in die 
Schuhe.

Bart schrieb:
> Nur weil es nicht schön ist hat es so gar nichts mit dem Problem zu
> tun...

Es geht nicht um Schönheit, sondern um Verständlichkeit.

In C schreibt man das üblicherweise so:

1

//Ref = AVcc, Channel = Bandgap

2

ADMUX = (1 << REFS0) | (1 << MUX3) | (1 << MUX2) | (1 << MUX1);

3

//Prescaler fuer 1MHz

4

ADCSRA = (1 << ADEN) | (1 << ADPS1) | (1 << ADPS0);

weil es niemanden interessieren muss, an welcher Bitposition das 
REFS0-Bit liegt. Und weil selbst die grösste Dumpfbacke auf einen Blick 
sieht, was hier eingestellt wurde. Und weil selbst die grösste 
Dumpfbacke den Code fehlerfrei eingeben kann.

Damit

1

ADCSRA := 199;

kann niemand etwas anfangen und die Gefahr, dass man sich dabei 
verrechnet, ist viel zu gross.

Eine ähnliche Möglichkeit wird es in deinem Pascaldialekt auch geben.

mfg.

Bart schrieb:
> alter..ich habe k.a. woher die Zahl kommt, ich meine sogar das war
> sogar direkt vom Compilerhersteller!! im Forum gepostet auf eine Frage
> von mir...ist auch absolut egal ..meine Güte...
> Nur weil es nicht schön ist hat es so gar nichts mit dem Problem zu
> tun...

Du hast ein Problem.
Du willst von uns haben, dass wir den Code kontrollieren.

Mit einer unübersichtlichen Schreibweise wirfst du uns (und auch dir 
selber) Prügel zwischen die Beine.

Ob das mit deinem Problem etwas zu tun hat oder nicht, kann erst mal 
keiner sagen. Denn wenn wir (ich zumindest) Fehler in fremden Code 
suchen, dann gehen wir von gar nichts als gesichert aus. Alles, jedes 
Detail, wird überprüft. Und zumindest meine Motivation ist im Keller, 
wenn ich zur Kontrolle der Einstellungen mit dem Datenblatt 3-mal so 
lange brauche, als ich brauchen würde, wenn du eine ordentliche 
Schreibweise gewählt hättest, bei der man auf einen Blick sieht, welche 
Bits (Bitnamen) du in welchem Konfigurationsregister gesetzt hast.

Da gehts also nicht nur um Schönheit. Das sind nur Neulinge, die glauben 
ein schönes Programm ist Luxes und das kann man hinterher immer noch 
schön machen. Die Beobachtung ist nämlich auch die, dass es sehr oft 
diejenigen mit dem scheuslichsten und am schlechtest lesbaren Code sind, 
die dann die blödesten Fehler im Code haben. Du kannst aus dieser 
Beobachtung den Schluss ziehen, dass ein schönes und gut zu lesendes 
Programm auch einen Einfluss auf die Fehlerhäufigkeit hat.
Du kannst das natürlich auch alles einfach ignorieren.