www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Analog/Digitalwandnlung Atmega644


Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
Ich habe folgendes Problem. Ich versuche mich an einer 
Analog/Digitalwandnlung. Hierbei habe ich das Problem das mir der 
Mikrocontroller(Atmega644) bei z.B. 2 V am Eingang auch 2000 mV angibt 
aber wenn ich den Eingang low lasse (gemessen 0.3 V ) er mir trotzdem 
angibt zB. 1500 mV. Ich benutze einen Externen 14,7456 MHZ. Als Kanal 
übergebe ich zB. 0 (für PortA Pin0). Die Referenzspannung beträgt 3,3 V.

long ReadAnalog(uint8_t mux)
{
  if((mux > -1) | (mux < 8)){

    uint8_t i;
    uint16_t result;

    ADMUX = mux;                      // Kanal waehlen
    ADMUX |= (1<<REFS0); // AVCC als Referenz (3,3 V)
    ADCSRA = (1<<ADEN) | (1<<ADPS2) | (1<<ADPS1) | (1<<ADPS0);    //
    ADCSRA |= (1<<ADSC);
    while ( ADCSRA & (1<<ADSC) ) {
       ;     // auf Abschluss der Konvertierung warten
    }
    result = ADCW;
     result = 0;
    char zwischenspeicher[10];
    for( i=0; i<4; i++ )
    {
      ADCSRA |= (1<<ADSC);
      while ( ADCSRA & (1<<ADSC) ) {
      ;
    }
      result += ADCW;

    ltoa(result,zwischenspeicher,10);

    ausgabe(zwischenspeicher);
      ausgabe(" ");
    }
    ADCSRA &= ~(1<<ADEN);
    result /= 4;
    return ((result * 3.30 /1024.00)*1000);
  } // Ende   if((mux>-1) | (mux < 8))
}




Bei "ausgabe(zwischenspeicher);" gibt mir der Mikrocontroller schon 
300,600,900,1200 an. Wobei mich hierbei stört das 300 von 1024=3,3V 
schon um die 1 V sind .(Die anderen sind aufaddierungen von 300 was auch 
so sein sollte
Jemand ne idee?
Vielen dank im Vorraus

Alex

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex wrote:
> aber wenn ich den Eingang low lasse (gemessen 0.3 V ) er mir trotzdem

Heißt das, der Eingang ist unbeschaltet? In dem Fall kann der Eingang 
jeden Spannungspegel annehmen. Solche Messungen können höchstens 
sinnvoll sein, wenn man gerne Zufallszahlen erzeugen möchte.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jup habe den Fehler. Liegt nicht an der Software sondern an der 
Hardware.. Benutze keine Pull Up/Down Widerstände. Danke für die 
schnelle Hilfe

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bist du sicher dass die Zeile wirklich macht was du dir vorgestellt 
hast?
->  if((mux > -1) | (mux < 8)){

z.B. wenn du jetzt 100 als mux übergibst.

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast wrote:
> Bist du sicher dass die Zeile wirklich macht was du dir vorgestellt
> hast?
> ->  if((mux > -1) | (mux < 8)){
>
> z.B. wenn du jetzt 100 als mux übergibst.

Zufällig funktioniert das, aber nur, weil mux vom Typ uint8_t ist (also 
unsigned) und deshalb (mux > -1) immer false ergibt.
Sinnvoller wäre es auf jeden Fall, einfach
if (mux < 8)
zu schreiben.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist wohl eher immer true, da jeder Wert den mux annehmen kann größer 
als -1 ist.

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast wrote:
> Es ist wohl eher immer true, da jeder Wert den mux annehmen kann größer
> als -1 ist.

Ne, eben nicht. mux ist 1 byte lang, folglich wird der Compiler für den 
Vergleich die -1 als Bytewert verwenden. In Hexadezimalschreibweise ist 
das 0xff. Zufällig ist dies genau gleich dem größten Wert, den eine 
Variable vom Typ uint8_t - wie mux - annehmen kann.
Deshalb kann mux niemals größer als -1 sein. Klingt verrückt, ist aber 
so.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Vogt wrote:
> Gast wrote:
>> Es ist wohl eher immer true, da jeder Wert den mux annehmen kann größer
>> als -1 ist.
>
> Ne, eben nicht. mux ist 1 byte lang, folglich wird der Compiler für den
> Vergleich die -1 als Bytewert verwenden. In Hexadezimalschreibweise ist
> das 0xff. Zufällig ist dies genau gleich dem größten Wert, den eine
> Variable vom Typ uint8_t - wie mux - annehmen kann.
> Deshalb kann mux niemals größer als -1 sein. Klingt verrückt, ist aber
> so.

Die Conclusio ist zwar richtig, aber die Begründung ist falsch.
Es geht nicht um bytewert oder wordwert.

Es geht um Signedness.

   mux > -1

ist ein Ausdruck, in dem 2 Datentypen gemischt werden.

  mux   ist ein uint8_t, also wohl ein unsigned char
  -1    ist ein int. Genauer: ein signed int

Die C Regeln schreiben jetzt vor, dass alles auf die Länge des größten 
gemeinsamen Datentyps gebracht werden muss. Das wäre jetzt erst mal 16 
Bit, für den int. Aus dem uint8_t wird also ein uint16_t.

Jetzt steht da ein unsigned Typ einem signed Typ gegenüber und in dem 
Fall sagen die C-Regeln, dass alles auf unsigned gebracht wird.

mux bleibt so wie es war, während -1 zu einem unsigned wird. Bei 
Benutzung von 2-er Komplementregeln (was wir mal vorraussetzen können), 
ist der zu -1 gehörende unsigned Wert 65535

Und jetzt hast du Recht.
mux wird wohl nie größer als 65535 sein. Vor allen Dingen gibt es keinen 
unsigned 16 Bit Wert der größer als 65535 sein kann.

(Der Optimizer des Compilers könnte die Erweiterung von 8 auf 16 Bit 
spritzen, allerdings bleibt das Problem nach wie vor, dass in ein und 
derselben Expression ein unsigned mit einem signed Datentyp gemischt 
wird. Und in dem Fall gewinnt immer unsigned)

Autor: Andreas Vogt (tico)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:
>   -1    ist ein int. Genauer: ein signed int

Ist das irgendwo festgelegt? Könnte der Compiler nicht auch ein signed 
char daraus machen?


Karl heinz Buchegger wrote:
> Jetzt steht da ein unsigned Typ einem signed Typ gegenüber und in dem
> Fall sagen die C-Regeln, dass alles auf unsigned gebracht wird.

Ich habe arbeite gerade einem C++ Projekt für einen ATmega mit der 
Winavr Toolchain. Da habe ich mal gehässigerweise folgendes Kompilieren 
lassen:
uint8_t mcucsr = MCUCSR;
if (mcucsr > -2)
   __asm__ volatile("nop");
Im resultierenden .lss-File sieht man, dass die if-Abfrage komplett 
wegomptimiert wird, und dass das  nop bedingungslos ausgeführt wird. 
Offenbar ist der gcc - jedenfalls bei der Verarbeitung von cpp-Dateien - 
der Ansicht, dass ein unsigned immer größer ist, als ein negativer 
Wert. Eine Umwandlung von signed auf unsigned scheint hier gar nicht 
stattzufinden.

Karl heinz Buchegger wrote:
> (Der Optimizer des Compilers könnte die Erweiterung von 8 auf 16 Bit
> spritzen, allerdings bleibt das Problem nach wie vor, dass in ein und
> derselben Expression ein unsigned mit einem signed Datentyp gemischt
> wird. Und in dem Fall gewinnt immer unsigned)

Was genau meinst Du damit? Dass der Compiler den signed Wert einfach als 
unsigned betrachtet? Das tut gcc in meinem Beispiel offensichtlich 
nicht.

edit
Alles Quark, Du hast Recht. In meinem Beispiel wird die if-Abfrage 
deshalb wegoptimiert, weil ein Wert mit der Länge von einem Byte nie 
größer sein kann als eine zwei Byte lange -2, die als unsigned 
betrachtet wird.

Autor: Eddy Current (chrisi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wieso sollte mux auf unsigned int erweitert werden? Im Gegenteil wird 
aus mux ein signed int, womit der Vergleich immer true ist.

Erwähnenswert wäre noch

if((mux > -1) | (mux < 8))

Die bitweise Veroderung der beiden Vergleiche, was ebenfalls 
funktioniert, aber tunlichst nicht zu Gewohnheit werden sollte. Kann 
üble Fehler ergeben, die man nicht mehr sieht.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.