[gelöst] Starten des ADC bei AVR (ATtiny45) seltsam

[Lenny G. (e_lenny)]

Hi,

ich habe ein seltsames Problem beim Starten des ADC bei meinem ATtiny45. 
Nach dem Einschalten starte ich eine Wandlung und will dann einen 
Dummy-Read machen, wie es auch im mikrocontroller.net-Tutorial 
(http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Analoge_Ein-_und_Ausgabe) 
beschrieben ist.
Zwischen PB1 und PB2 hängen 2 antiparallele LEDs. Mit PORTB = 1 leuchtet 
LED1, mit PORTB = 2 leuchtet LED2.

#include <avr/io.h>
#define F_CPU 8000000UL

int main(void)
{
  DDRB = 0b00000011;
  PORTB = 2;                             // kritische Zeile

  ADMUX   = (1 << MUX1) | (1 << MUX0);   // V_CC als Referenz (A_REF nicht verbunden), PB3 als Input
  ADCSRA  = (1 << ADPS2) | (1 << ADPS1); // Prescaler auf 64 setzen (ergibt Samplerate von 125 kHz)
  ADCSRA |= (1 << ADEN);                 // ADC einschalten
  ADCSRA |= (1 << ADSC);                 // Wandlung starten

  while (ADCSRA & (1<<ADSC));            // warten, bis Wandlung beendet (ADSC zurückgesetzt)
  (void) ADC;                            // Dummy-Read

  PORTB = 1;                             // LED1 anschalten
  while(1);
}

Jetzt das Seltsame: Ohne die kritische Zeile leuchtet keine LED, der 
Controller bleibt in der ADC-Warteschleife hängen. Setzt man in der 
kritischen Zeile PORTB auf Werte wie 0, 4, 8 oder 16, passiert dasselbe. 
Setze ich PORTB allings auf 1, 2, 3, 5 oder irgendeinen Wert, bei dem 
PB1 oder PB2 auf 1 gesetzt werden, funktioniert alles wie gewünscht und 
am Ende leuchtet brav die LED1.
Die Wandlung funktioniert also nur, wenn mindestens einer der 
Ausgangspins auf 1 gesetzt wird! Hat einer von euch dafür eine 
Erklärung?

Fuses sind E:FE, H:DF, L:E2.
Makefile:

PROGRAMMER = avrisp2
CPU_GCC = attiny45
CPU_DUDE = t45

F_CPU = 8000000

CDEFS = -DF_CPU=$(F_CPU)
CFLAGS = -mmcu=$(CPU_GCC) $(CDEFS) -Wall -Os -DSTARTERKIT

.phony: clean

all: fftest.hex

program: fftest.hex
  avrdude -c $(PROGRAMMER) -P usb -p $(CPU_DUDE) -U flash:w:fftest.hex

clean:
  rm *.o *.elf *.hex

fftest.hex: fftest.c
  avr-gcc $(CFLAGS) -c fftest.c -o fftest.o
  avr-gcc $(CFLAGS) fftest.o -o fftest.elf
  avr-objcopy -R .eeprom -O ihex fftest.elf fftest.hex

Ich bin µC-Anfänger, also seid lieb zu mir. :D

[der alte Hanns (Gast)]

>Zwischen PB1 und PB2 hängen 2 antiparallele LEDs. Mit PORTB = 1 leuchtet
>LED1, mit PORTB = 2 leuchtet LED2.

Zwischen? Dann leuchtet LED1 bei PB2=1 und PB1=0, d.h. PORTB=4, sowie 
LED2 bei PB2=0 und PB1=1, d.h. PORTB=2 (oder umgekehrt).

(Ohne dass ich jetzt den ganzen Rest des Textes lesen&verstehen will).

[Marc V. (Firma: Vescomp) (logarithmus)]

Lenny G. schrieb:
> Zwischen PB1 und PB2 hängen 2 antiparallele LEDs. Mit PORTB = 1 leuchtet
> LED1, mit PORTB = 2 leuchtet LED2.

 Wenn es PB1 und PB2 sind, was hat die 1 da zu suchen ?
 Mit 1 schaltest du PB.0

[Thomas E. (thomase)]

Lenny G. schrieb:
> ich habe ein seltsames Problem beim Starten des ADC bei meinem ATtiny45.
Seltsame Probleme sitzen immer vor dem PC.

Lenny G. schrieb:
> Ich bin µC-Anfänger, also seid lieb zu mir. :D
Nein.

Was soll das?
Lenny G. schrieb:
>   PORTB = 2;

Warum schreibst du hier nicht "PORTB = (1 << PB2);"?

Genauso wie hier:

Lenny G. schrieb:
> PORTB = 1;                             // LED1 anschalten

Dann passiert dir auch so ein Scheiss nicht:

Marc Vesely schrieb:
> Wenn es PB1 und PB2 sind, was hat die 1 da zu suchen ?
>  Mit 1 schaltest du PB.0

oder hier:
> DDRB = 0b00000011;
Das betrifft auch PB0 und PB1.

mfg.

[Lenny G. (e_lenny)]

Meine Güte, zerreißt euch doch nicht gleich das Maul, nur weil ich mich 
vertippt habe!
Die LEDs hängen selbstverständlich zwischen PB0 und PB1, nicht zwischen 
PB1 und PB2 ...

Also, vllt hat jemand freundlichere (und hilfreichere) Ratschläge zu dem 
Problem?

[c-hater (Gast)]

Lenny G. schrieb:

> Also, vllt hat jemand freundlichere (und hilfreichere) Ratschläge zu dem
> Problem?

Das Problem dürfte mit der Stromversorgung der Controllers 
zusammenhängen.

Vermutlich klappt es auch, wenn du einfach eine zusätzliche LED zwischen 
VCC und GND betreibst und dann wird auch deine "kritische" Zeile nicht 
mehr kritisch sein.

Wenn das so ist, dann darfst du hier den Schaltplan veröffentlichen, der 
zeigt, wie du derzeit deinen Controller betreibst. Der dürfte einiges 
Potential für Verbesserungsvorschläge enthalten.

[Dirk K. (dekoepi)]

100nF Abblockkondensator hast du eingelötet?

Außerdem solltest du für die PORTB-Zuweisung dieselbe Notation verwenden 
wie in deinem Richtungsregister. Dann siehst du sofort, warum deine 
"wild gewählten Zufallszahlen" auch komische Ergebnisse liefern.

Die LEDs sollten jeweils leuchten, wenn du:
PORTB = 0b00000010;
oder
PORTB = 0b00000001;

entsprechend Dezimal 1 oder 2 setzt. Vorwiderstände korrekt berechnet 
mit der Versorgungsspannung und Durchlassspannung? Wenn zuwenig Strom 
ankommt, kann die LED nicht leuchten. Sind die heile, beim Test direkt 
mit Vorwiderstand und Speisung sind beide LEDs auch heil?

[Lenny G. (e_lenny)]

Die zusätzliche LED zwischen V_CC und GND hat nicht geholfen. Ich 
betreibe die Schaltung über USB, ein 100-nF-Ceramic sitzt direkt am 
V_CC-Pin des Controllers.

Dirk K. schrieb:
> Außerdem solltest du für die PORTB-Zuweisung dieselbe Notation verwenden
> wie in deinem Richtungsregister. Dann siehst du sofort, warum deine
> "wild gewählten Zufallszahlen" auch komische Ergebnisse liefern.
Keine Ahnung, was du damit meinst. Es sollte doch kein Problem sein, 
wenn ich schreibe

DDRB = 0b00000011;
PORTB = 1;

Wäre mir neu, dass man das einheitlich machen muss. Die Zahlen sind auch 
keineswegs zufällig, die Systematik ist oben erklärt.

Der Schaltplan zeigt dir die Vorwiderstände. Wie bereits gesagt, mit der 
kritischen Zeile drin funktioniert es ja, die LEDs sind nicht kaputt.

Allerdings tritt das Problem nicht auf, wenn ich den Controller auf dem 
Breadboard betreibe und bis auf die LEDs die restliche Beschaltung 
weglasse. Ich probiere mal noch etwas rum ...

[Adi Positas (Gast)]

Lenny schrieb:
>Meine Güte, zerreißt euch doch nicht gleich das Maul, nur weil ich mich
>vertippt habe!

Das ist hier die Regel, weil das mittlerweile ein Haifischbecken 
geworden ist.

Überlies die unsachlichen Beiträge, antworte nicht darauf, sonst ist der
Thread in NullkommaNichts von Mist geflutet und Du bekommst keine
brauchbare Antwort mehr.

Adi

[Lenny G. (e_lenny)]

Hatte den Thread schon wieder ganz vergessen, sorry.

Das Problem war der Pull-up am Reset-Pin. Ich wollte mit einem 470k 
(siehe Schematic oben) besonders sparsam sein ... eine Größenordnung 
kleiner hat das Problem gelöst.

[Marc V. (Firma: Vescomp) (logarithmus)]

Lenny G. schrieb:
> Das Problem war der Pull-up am Reset-Pin. Ich wollte mit einem 470k
> (siehe Schematic oben) besonders sparsam sein ... eine Größenordnung
> kleiner hat das Problem gelöst.

 Ähem.
 Sehr unwahrscheinlich, aber wenn du es so sagst...

[Lenny G. (e_lenny)]

Ja, kein Plan, was soll ich sagen? Das war wirklich das einzige, was ich 
geändert habe (Pull-up rausgelötet, anderen rein) und es ging alles wie 
gewünscht ...

[Myxo M. (myxom)]

Danke Lenny für dein Feedback.