Codexplosion bei _delay_ms mit ADC Wert

1

for (uint16_t i = Pause; i > 0; i--)

2

    delay_ms(1);

Grund: Aus der Dukumentation von delay.h:

1

In order for these functions to work as intended, compiler optimizations

2

 must be enabled, and the delay time must be an expression that is a known

3

constant at compile-time. If these requirements are not met, the resulting

4

 delay will be much longer (and basically unpredictable), and applications 

5

that otherwise do not use floating-point calculations will experience severe 

6

code bloat by the floating-point library routines linked into the

7

 application.

sieht doch kurz und knackig aus.
nimmt _delay_ms() auch 16 bit integer?
vielleicht selber eine delay funktion bauen mit NOPs und zähler?

Abgesehen davon:
ADC_Hilfe ist woanders deklariert?
ADCH solltest du zuerst lesen und shiften, dann ADCL addieren.

1

  ADC_Hilfe = (ADCL<<8);  //ADCL um 8 Bit verschieben

2

  ADC_Hilfe = ADC_Hilfe + ADCH;  //ADCH hinzufügen

sieht mir eher nach einer Vertauschung des oberen mit dem unteren Byte 
aus.   Ich glaube nicht, dass das so beabsichtigt ist.

Der GCC kann IMHO auch 16Bit-Register lesen.

Mach einfach ein "return ADC" dann kannst dir das Bitgeshifte sparen.
(ADC entspricht ADCL | ADCH << 8

Außerdem sehe ich gerade, dass du ADCL shiftest. Verwechslung oder 
Absicht?

Gruß
Roland

Wenn du unbedingt ein delay verwenden musst dann schau dir mal das
util/delay_basic.h  an.
Steht in der gcc.lib.referenz.

Michael O. schrieb:
> Kann mir jemand sagen, ob es geht den Code zu verkleinern. Um mir dann
> auch nen Tipp geben kann wie ich das anstellen muss.
Baue eine Schleife mit _delay_ms(1.0) drin, die Pause oft durchlaufen 
wird.

1

while(Pause--) _delay_ms(1.0);

Gruß, DetlevT

danke @ all

auf die For Schleife hätte ich auch kommen können.

Das mit ADCH und ADCL war ein Fehler von mir, da ich ncht aufgepasst 
habe.

Den im Datenbaltt steht ja:
>When ADCL is read, the ADC Data Register is not updated until ADCH is read. 
>Consequently, if
>the result is left adjusted and no more than 8-bit precision is required,
>it is sufficient to read
>ADCH. Otherwise, ADCL must be read first, then ADCH.

Allerdings hab ich nicht auf die Bitwertigkeit geschaut.

ADC_Hilfe war auch deklariert hab ich nur im Snippet vergessen.

Gruß

Ich stell gerade fest, dass die ADC Messung gar nicht funktioniert. 
Gemessen werden soll mit ADC1 bzw. PB2

Code-Snippet:

1

uint16_t Pause;

2

Pause = 0x0000;

3

4

ADMUX = (1<<ADLAR);  //"runden"

5

ADCSRA = (1<<ADATE);

6

ADCSRA = (1<<ADEN);  //ADC ein

7

8

uint16_t ADC_messen(uint8_t channel)

9

{

10

  ADMUX = (ADMUX & ~(0x1F)) | (channel & 0x1F);

11

  ADCSRA = (1<<ADSC);            // messen

12

  while (ADCSRA & (1<<ADSC) );    // auf AVR warten

13

  return ADCH;                    // ADC Wert zurückgeben

14

}

15

16

Pause = ADC_messen(1);

Hat jemand nen Fehler entdeckt?

Gruß

Michael O. schrieb:
> Hat jemand nen Fehler entdeckt?

1

ADCSRA = (1<<ADATE);

2

ADCSRA = (1<<ADEN);  //ADC ein

Die zweite Zeile setzt ADATE wieder auf Null (aber warum setzt du ADATE 
überhaupt?).

1

  ADCSRA = (1<<ADSC);            // messen

Und beim Starten der Messung den ADC gleichzeitig abzuschalten ist 
sicher auch keine gute Idee.

ups....

da hat wohl wern nen | vergessen

danke dir

gruß

Michael O. schrieb:
>

1

>   return ADCH;                    // ADC Wert zurückgeben

2

>

->

1

return ADC;

> Nach ANSI ist jede Konstante immer
> "signed int"-Datatype und ohnen Suffix wir schreiben einen
> signed-Operand in die unsigned-Variable, was datentypmismatch bedeutet.

In ANSI C gibt es kein Ding namens "datentypenmismatch", sondern 
"promotion rules".  Es ist also vielmehr genau definiert, zu welchem 
Typen erweitert wird, wenn 2 verschiedene Typen aufeinander treffen.

> Weiter, "bitwise and shift operations" nur für "unsigned" definiert
> sind.

Nein, auch für signed Integers ist Shift definiert, solange sie nicht 
negativ sind:

1

4. The result of E1 << E2 is E1 left-shifted E2 bit positions: vacated

2

bits are filled with zeros. ... If E1 has a signed type and a

3

nonnegative value, and E1x2^32 is representable in the result type,

4

then that is the resulting value; otherwise, the behavior is undefined.

> aber ANSI spricht klar und MISRA schreibt das vor.

Ich weiß nicht, was MISRA schreibt, aber ANSI sagt für den gezeigten 
Code klar aus, dass die Korrektur überflüssige Mühe ist.

lies dir mal das Datenblatt zum ADC durch. Ich glaube mich zu erinnern, 
dass man beim Umschalten von ADMUX den ersten Wert unter bestimmten 
Umständen verwerfen musss, weil er falsch ist.

Gruß
Roland

Du hast mit deiner Erklärung Recht, aber das "2x2^32" bzw. "2x2^16"
da im Text ist falsch: im Standard steht "2 x 2^E2".  E2 ist hier
gleich 8.  Ändert nur nichts dran, dass 0xff00 nicht als signed int
darstellbar ist.

Allerdings trifft das auf das ADC-Ergebnis nicht zu: die ganzen
IO-Register sind vom Typ uint8_t, damit wird der Teil "If E1 has
an unsigned type, [...]" wirksam, für den das Ergebnis definiert
ist.

DERLEVELER schrieb:
>

1

ADC_Hilfe = ADC_Hilfe + ADCH;  //ADCH hinzufügen

2

>

>
> würde ich lieber so schreiben:
>

1

ADC_Hilfe += ADCH;  //ADCH hinzufügen

Nein, ADCH und ADCL sollte man nicht direkt auslesen, sondern ADC 
benutzen, damit diese in der richtigen Reihenfolge ausgelesen werden.
Einfach mal lesen, was schon geschrieben wurde, kann nicht schaden!

@  Simon K. (simon) Benutzerseite

>Nein, ADCH und ADCL sollte man nicht direkt auslesen, sondern ADC
>benutzen, damit diese in der richtigen Reihenfolge ausgelesen werden.

Ich würde lieber ADCW nutzen ;-)

MFG
Falk

Falk Brunner schrieb:

> Ich würde lieber ADCW nutzen ;-)

Kein Unterschied.

@  A. K. (prx)

>> Ich würde lieber ADCW nutzen ;-)

>Kein Unterschied.

Hmm, stimmt, im C. Aber im ASM geht das nicht, weil ADC ein Befehl ist. 
Ist auch so mit Fallunterscheidung in den Include Files drin ;-)

MfG
Falk

Falk Brunner schrieb:
> Aber im ASM geht das nicht, weil ADC ein Befehl ist.

Könnte schon, da der C-Präprozessor ja nur ADCW erseten würde,
während adcw immer noch für den Befehl benutzbar ist.

Aber: wer sich für Assembler entschieden hat, kann sowieso keine
16-bit-IO-Register automatisch lesen oder schreiben lassen. ;-)