Atmega128 - Programm wird geladen, aber LED blinkt nicht?

[Heinrich W. (ubik123)]

Hallo,

ich habe folgendes Prgramm für einen Atmega128 geschrieben, dass die LED 
auf PB7 blinken soll:

#include <avr/io.h>
#include <util/delay.h>

int main(void) {

  DDRB = 0x80;

  while(1)
  {
    PORTB ^= 0x80;
      _delay_ms(5000);
  }

  return(0);
}



Das Ganze lade ich mit folgendem Skript über einen AVRISP XPII auf den 
Mikrocontroller:

avr-gcc -Wall -Os -DF_CPU=16000000UL -B 9600 -mmcu=atmega128 -c main.c 
-o main.o
avr-gcc -Wall -Os -DF_CPU=16000000UL -B 9600 -mmcu=atmega128 -o main.elf 
main.o
rm -f main.hex
avr-objcopy -j .text -j .data -O ihex main.elf main.hex
avrdude -c avrispmkII -p m168 -U flash:w:main.hex

Das Skript liefert:


avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 
0.05s

avrdude: Device signature = 0x1e9406
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be 
performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "main.hex"
avrdude: input file main.hex auto detected as Intel Hex
avrdude: writing flash (198 bytes):

Writing | ################################################## | 100% 
3.48s

avrdude: 198 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex auto detected as Intel Hex
avrdude: input file main.hex contains 198 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 
4.44s

avrdude: verifying ...
avrdude: 198 bytes of flash verified

avrdude: safemode: Fuses OK (H:01, E:DF, L:62)

avrdude done.  Thank you.



Also wurde es auf den Mikrocontroller geladen. Warum blinkt dann die LED 
an Port PB7 nicht?

Auf PB7 ist konsten 0.9 V drauf. Was können die Ursachen sein?

[Stefan F. (Gast)]

Eventuell nicht alle VCC und GND Pins angeschlossen?

[Rath Bieter (Gast)]

Heinrich W. schrieb:
> Also wurde es auf den Mikrocontroller geladen. Warum blinkt dann die LED
> an Port PB7 nicht?

Weil du die LED (wie auch immer) falsch angeschlossen hast?

[S. Landolt (Gast)]

"M103C(1) 1 ATmega103 compatibility mode 0 (programmed"?

[S. Landolt (Gast)]

PS:

> avrdude -c avrispmkII -p m168 -U flash:w:main.hex

Ich kenne avrdude nicht, aber "m168" irritiert mich.

[Heinrich W. (ubik123)]

Stefanus F. schrieb:
> Eventuell nicht alle VCC und GND Pins angeschlossen?

Doch, definitiv angeschlossen. Es sind 5.1 V per selbst gebastelten und 
gelötetem USB Kabel an den Microcontroller angeschlossen. Das Messgerät 
liefert auch 5.1 V, wenn ich das USB Kabel an den Microcontroller 
anschließe.

Rath Bieter schrieb:
> Heinrich W. schrieb:
>> Also wurde es auf den Mikrocontroller geladen. Warum blinkt dann die LED
>> an Port PB7 nicht?
>
> Weil du die LED (wie auch immer) falsch angeschlossen hast?

Aber an Port PB7 sind 0.9 V, wenn ich mit dem Messgerät messe. 
Eigentlich viel zu wenig. Da müsste jetzt abwechselnd 5 V und dann 0 V 
jede Sekunde wechseln.

S. Landolt schrieb:
> PS:
>
>> avrdude -c avrispmkII -p m168 -U flash:w:main.hex
>
> Ich kenne avrdude nicht, aber "m168" irritiert mich.

avrdude -c avrispmkII -p  --he
avrdude: AVR Part "--he" not found.

Valid parts are:
  uc3a0512 = AT32UC3A0512
  c128     = AT90CAN128
  c32      = AT90CAN32
  c64      = AT90CAN64
  pwm2     = AT90PWM2
  pwm2b    = AT90PWM2B
  pwm3     = AT90PWM3
  pwm316   = AT90PWM316
  pwm3b    = AT90PWM3B
  1200     = AT90S1200
  2313     = AT90S2313
  2333     = AT90S2333
  2343     = AT90S2343
  4414     = AT90S4414
  4433     = AT90S4433
  4434     = AT90S4434
  8515     = AT90S8515
  8535     = AT90S8535
  usb1286  = AT90USB1286
  usb1287  = AT90USB1287
  usb162   = AT90USB162
  usb646   = AT90USB646
  usb647   = AT90USB647
  usb82    = AT90USB82
  m103     = ATmega103
  m128     = ATmega128


Atmega128 ist also m128.

[Pandur S. (jetztnicht)]

Ja.
Eigentlich müsste das Port als Ausgang geschaltet sein. Da tut es nicht 
von selbst.
Dann sollte die LED einen Vorwiderstand haben. Wie gross ist der ?

[Frank M. (ukw) (Moderator)]

Heinrich W. schrieb:
> Atmega128 ist also m128.

Aber oben schreibst Du:

> avrdude -c avrispmkII -p m168 -U flash:w:main.hex

Da steht m168 und nicht m128.

[Stefan F. (Gast)]

Heinrich W. schrieb:
> Atmega128 ist also m128.

Man kann auch Atmega128 einfach ausschreiben oder den gleichen String 
benutzen, den man auch als gcc parameter MCU verwendet.

[aha-aha (Gast)]

Stefanus F. schrieb:
> Heinrich W. schrieb:
>> Atmega128 ist also m128.
>
> Man kann auch Atmega128 einfach ausschreiben oder den gleichen String
> benutzen, den man auch als gcc parameter MCU verwendet.

Man sollte aber nicht m168 schreiben.

[Stefan F. (Gast)]

aha-aha schrieb:
> Man sollte aber nicht m168 schreiben.

Klaro.

[Jörg W. (dl8dtl) (Moderator)]

Frank M. schrieb:

>> avrdude -c avrispmkII -p m168 -U flash:w:main.hex
>
> Da steht m168 und nicht m128.

… und es gibt keine Beschwerde über eine falsche Signatur. Überdies wird 
die Signatur als 0x1e9406 ausgegeben, was tatsächlich einem ATmega168 
entspricht.

Das legt also den Verdacht sehr nahe, dass das Programm einfach mal für 
einen völlig falschen Controller compiliert worden ist. Dann ist es auch 
nicht verwunderlich, dass es nicht funktioniert.

[jo mei (Gast)]

Jörg W. schrieb:
> Das legt also den Verdacht sehr nahe, dass das Programm einfach mal für
> einen völlig falschen Controller compiliert worden ist.

Heinrich W. schrieb:
> avr-gcc -Wall -Os -DF_CPU=16000000UL -B 9600 -mmcu=atmega128 -c main.c
> -o main.o

[Heinrich W. (ubik123)]

Ach entschuldigung. Es handelt sich definitiv um einen atmega168, nicht 
um 128.

Dann müsste doch die LED blinken?

Aber der Ausgang hat ständig nur 0.8 V.

[Jörg W. (dl8dtl) (Moderator)]

Heinrich W. schrieb:
> Dann müsste doch die LED blinken?

Nur, wenn du das Programm endlich auch mal für einen ATmega168 
compilierst statt für einen ATmega128. Der '128 hat einen geringfügig 
anderen Befehlssatz.

Btw., welche Magie dein "-B 9600" in der Compiler-Kommandozeile bewirken 
soll, bleibt mir ein Rätsel. Vielleicht meintest du ja "-DBAUD=9600"? 
(Wäre allerdings hier nutzlos, da du ja gar keine <util/baudrate.h> oder 
UART überhaupt benutzt.)

[jo mei (Gast)]

Heinrich W. schrieb:
> Ach entschuldigung. Es handelt sich definitiv um einen atmega168, nicht
> um 128.
>
> Dann müsste doch die LED blinken?

Da geht's ja drunter und drüber. Da hilft alle Hilfe nix wenn
man sich auf keine Angaben verlassen kann.

[Heinrich W. (ubik123)]

Das kompilieren geschieht jetzt folgendermaßen:

avr-gcc -Wall -Os -DF_CPU=16000000UL -mmcu=atmega168 -c main.c -o main.o
avr-gcc -Wall -Os -DF_CPU=16000000UL -mmcu=atmega168 -o main.elf main.o
rm -f main.hex
avr-objcopy -j .text -j .data -O ihex main.elf main.hex
avrdude -c avrispmkII -p m168 -U flash:w:main.hex

Aber es passiert nichts. Die LED blinkt nicht.

./compile.sh

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 
0.05s

avrdude: Device signature = 0x1e9406
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be 
performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "main.hex"
avrdude: input file main.hex auto detected as Intel Hex
avrdude: writing flash (178 bytes):

Writing | ################################################## | 100% 
3.13s

avrdude: 178 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex auto detected as Intel Hex
avrdude: input file main.hex contains 178 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 
4.44s

avrdude: verifying ...
avrdude: 178 bytes of flash verified

avrdude: safemode: Fuses OK (H:01, E:DF, L:62)

avrdude done.  Thank you.



Das Programm lautet:

#include <avr/io.h>
#include <util/delay.h>

int main(void) {

  DDRB = 0b00000001;

  while(1)
  {
    PORTB = 0b00000001;          /* Turn on first LED bit/pin in PORTB 
*/
    _delay_ms(1000);                                           /* wait 
*/

    PORTB = 0b00000000;          /* Turn off all B pins, including LED 
*/
    _delay_ms(1000);                                           /* wait 
*/
  }

  return(0);
}

[c-hater (Gast)]

Heinrich W. schrieb:

> avrdude: safemode: Fuses OK (H:01, E:DF, L:62)

Wenn man diese Fuses an den Fusebit-Rechner von Engbedded.com 
verfüttert, dann bekommt man in Rot folgende Warnung (die ich dort noch 
nie zuvor gesehen habe):

> Unreviewed original XML backend database from Atmel. Probably buggy! Please > 
report.

Muss nichts mit deinem Problem zu tun haben, kann aber. Ich würde als 
nächsten Schritt ein Abgleich mit dem DB empfehlen (in der Hoffnung, das 
dieses korrekt ist). Wenn das nicht zur Aufklärung führt, dürfte es 
einigermaßen anstrengend werden...

[Jörg W. (dl8dtl) (Moderator)]

c-hater schrieb:
> Muss nichts mit deinem Problem zu tun haben, kann aber.

Eher nicht, eher ein Problem deines Fuse-Calculators.

Die Fuses sehen OK aus (jungfräulich).

Aber: die Compiler-Kommandozeile behauptet, die CPU würde mit 16 MHz 
laufen, in Wirklichkeit läuft sie mit 1 MHz, denn die Fuses stehen auf 
den Defaultwerten (interner RC-Oszillator einschließlich CKDIV8). Man 
muss da wohl ziemlich lange warten, bis eine LED "blinkt".

Weiterhin wurde die LED im Code jetzt von PB7 auf PB0 "umsortiert" – 
wurde sie das denn auch in der realen Schaltung?

[c-hater (Gast)]

Jörg W. schrieb:

> Eher nicht, eher ein Problem deines Fuse-Calculators.

Das ist nicht "meiner". In keinster Hinsicht. Ich habe ihn allerdings 
schon recht oft benutzt und bisher noch niemals diese Warnung zu sehen 
bekommen. Da habe ich einfach mal angenommen, dass die tatsächlichen 
Verfasser dieser Lösung sich aus irgendeinem Grunde gezwungen gesehen 
haben, diese Warnung zu geben. Aus Langeweile haben die das wohl 
sicherlich nicht getan.

> Aber: die Compiler-Kommandozeile behauptet, die CPU würde mit 16 MHz
> laufen, in Wirklichkeit läuft sie mit 1 MHz

Muss man also 5000*16 msec warten, bis was wackelt. 'ne gute Minute. 
Scheint mir jetzt nicht so superlange, dass es völlig unmöglich wäre, 
einfach mal in der Zeit ein Bier holen zu gehen oder sowas...

[Jörg W. (dl8dtl) (Moderator)]

c-hater schrieb:
> Scheint mir jetzt nicht so superlange, dass es völlig unmöglich wäre,
> einfach mal in der Zeit ein Bier holen zu gehen oder sowas...

Wenn man einschaltet und erwartet, dass das Ding im Sekundenrhythmus 
blinkt, dann bekommt man schon die sprichwörtlichen kalten Füße und wird 
vor Ablauf der 16 Sekunden wohl wieder ausschalten, "geht nicht".

Aber es wäre dem TE natürlich ein deutlich systematischeres Vorgehen 
anzuraten, verbunden mit ein wenig Grundverständnis von dem, was er da 
gerade tut, statt einfach nur auf gut Glück mit copy&paste irgendwas aus 
dem Netz zusammenzukopieren.

[S. Landolt (Gast)]

> Aber der Ausgang hat ständig nur 0.8 V.

Um welchen Anschluss handelt es sich denn nun, B0 wie zuletzt oder B7 
wie eingangs?

[Einer K. (Gast)]

Jörg W. schrieb:
> Die Fuses sehen OK aus (jungfräulich).

Jungfäulich:
-U lfuse:w:0x62:m -U hfuse:w:0xdf:m -U efuse:w:0xf9:m

Gelesen wird aber offensichtlich
Heinrich W. schrieb:
> avrdude: safemode: Fuses OK (H:01, E:DF, L:62)
Was dann zu Problemen führen kann.


ohne Gewähr

[Jörg W. (dl8dtl) (Moderator)]

Arduino Fanboy D. schrieb:
> Jörg W. schrieb:
>> Die Fuses sehen OK aus (jungfräulich).
>
> Jungfäulich:
> -U lfuse:w:0x62:m -U hfuse:w:0xdf:m -U efuse:w:0xf9:m

Allerdings werden die fünf ungenutzten Bits der Extended Fuse in der 
Anzeige ausgeblendet, sodass dort von 11111001 nur eine XXXXX001 = 0x01 
übrig bleibt.

Überdies benutzt der TE eine hornalte Version von AVRDUDE, die einen Bug 
hatte, weshalb die Angabe "H" und "E" in der Ausgabe genau falsch herum 
war (die Reihenfolge dagegen korrekt, also E/H/L). Dieser Bug war zwar 
nur für ein paar Tage im Code drin, aber aus irgendeinem Grunde hält 
sich diese Version außerordentlich hartnäckig im Netz.

Wenn er eine aktuelle Version benutzt hätte, wäre die Ausgabe der 
Signatur auch rückübersetzt worden zu "probably m168".

[Einer K. (Gast)]

Jörg W. schrieb:
> Überdies benutzt der TE eine hornalte Version von AVRDUDE, die einen Bug
> hatte
Ok ....

Dann nehme ich alles zurück, und behaupte ab jetzt das Gegenteil.

[Heinrich W. (ubik123)]

Jörg W. schrieb:
> Weiterhin wurde die LED im Code jetzt von PB7 auf PB0 "umsortiert" –
> wurde sie das denn auch in der realen Schaltung?

Ja, wurde sie :-)

S. Landolt schrieb:
> lchen Anschluss handelt es sich denn nun, B0 wie zuletzt oder B7
> wie eingangs?

Diesmal um B0.



Also ich hab eine Minute gewartet, es kommt nichts. Diesmal ist an dem 
Ausgang 0 V.

Das Programm habe ich nochmal umgeschrieben, sodass die LED ständig 
leuchtet:

#include <avr/io.h>
#include <util/delay.h>

int main(void) {

  DDRB = 0b00000001;

  while(1)
  {
    PORTB = 0b00000001;          /* Turn on first LED bit/pin in PORTB 
*/
/*    _delay_ms(1000);

    PORTB = 0b00000000;
    _delay_ms(1000);
*/  }

  return(0);
}

Klappt aber nicht...

[c-hater (Gast)]

Jörg W. schrieb:

> Überdies benutzt der TE eine hornalte Version von AVRDUDE, die einen Bug
> hatte, weshalb die Angabe "H" und "E" in der Ausgabe genau falsch herum
> war (die Reihenfolge dagegen korrekt, also E/H/L). Dieser Bug war zwar
> nur für ein paar Tage im Code drin, aber aus irgendeinem Grunde hält
> sich diese Version außerordentlich hartnäckig im Netz.

Das liegt daran, dass sowieso keiner dieser unzähligen C&P-Programmierer 
die Ausgaben liest oder gar versteht...

[S. Landolt (Gast)]

> Klappt aber nicht...

Nur um ganz sicher zu sein: welche Spannung wird jetzt an B0 gemessen?

[Stefan F. (Gast)]

S. Landolt schrieb:
> Nur um ganz sicher zu sein: welche Spannung wird jetzt an B0 gemessen?

Vier Messung bitte:

1:      VCC o------(V)-----o PB0


2:      GND o------(V)-----o PB0


3:      GND o------(V)-----o /Reset


4:      GND o------(V)-----o VCC

[Heinrich W. (ubik123)]

Stefanus F. schrieb:
> Vier Messung bitte:
> 1:      VCC o------(V)-----o PB0
>
> 2:      GND o------(V)-----o PB0
>
> 3:      GND o------(V)-----o /Reset
>
> 4:      GND o------(V)-----o VCC


1: Wie soll man das messen? Besser nicht nicht, sonst geht PB0 schrott, 
sind ja zwei Plus Pole.

2: 4 mV

3: 4.15 V

4: 5.09 V

[Stefan F. (Gast)]

Heinrich W. schrieb:
> 1: Wie soll man das messen? Besser nicht nicht, sonst geht PB0 schrott,
> sind ja zwei Plus Pole.

Da geht nichts kaputt, das Multimeter lässt (Im Volt Bereich) nur wenige 
µA fließen. Die Messung würde darüber Aufschluss geben, ob der I/O Pin 
als Ausgang konfiguriert wurde. Wenn ja, muss das Multimeter dann (wegen 
Low Pegel) 5V anzeigen.

Die Messung 3 ist nicht Ok. Das müssen mindestens 4,58V sein. Du bist 
aber weiter darunter, und damit in einer Grauzone in der die Funktion 
des µC nicht mehr sicher ist.

Wie ist denn der Reset Pin beschaltet?

[Heinrich W. (ubik123)]

Stefanus F. schrieb:
> Heinrich W. schrieb:
>> 1: Wie soll man das messen? Besser nicht nicht, sonst geht PB0 schrott,
>> sind ja zwei Plus Pole.
>
> Da geht nichts kaputt, das Multimeter lässt (Im Volt Bereich) nur wenige
> µA fließen. Die Messung würde darüber Aufschluss geben, ob der I/O Pin
> als Ausgang konfiguriert wurde. Wenn ja, muss das Multimeter dann (wegen
> Low Pegel) 5V anzeigen.
>
> Die Messung 3 ist nicht Ok. Das müssen mindestens 4,58V sein. Du bist
> aber weiter darunter, und damit in einer Grauzone in der die Funktion
> des µC nicht mehr sicher ist.
>
> Wie ist denn der Reset Pin beschaltet?

Bei 1: 0 V

Der Reset Pin muss doch gar nicht beschaltet werden, bloß mit dem 
Programmer.

Moment mal.

Ich hab ja diesen USB AVRISP XPII Programmer. Dort sind folgende Kabel:

- Rot: VCC
- Schwarz: GND
- Blau: MOSI
- Grün: SCK
- Gelb: MISO
- Weiß: ???

Was ist denn das weiße Kabel? Normalerweise müsste es ein Violettes 
Kabel sein, das wäre dann der RESET.

Warum hab ich kein violettes Kabel an dem Programmer?

Edit: Wenn ich das weiße Kabel rausziehe, dann sind es bei 3: 5 V

[Stefan F. (Gast)]

Heinrich W. schrieb:
> Wenn ich das weiße Kabel rausziehe, dann sind es bei 3: 5 V

Aha, und wetten dann blinkt die LED auch (sehr langsam)?

Die Sache ist die: Der Reset Pin enthält intern einen sehr schwachen 
Pull-Up Widerstand. Sobald da auch nur ein paar cm Draht dran hängen, 
musst du den Pin mit einem stärkeren Pull-Up Widerstand (z.B. 4,7 kΩ) 
beschalten

> Normalerweise müsste es ein Violettes Kabel sein

Wen interessieren die Farben?

[S. Landolt (Gast)]

Also gar so empfindlich ist es nicht, ich kann hier bei meinem ATmega168 
an Reset bis auf 2.4 V heruntergehen, bei Ucc= 5.0 V.
  Jetzt mal unabhängig davon, was im Datenblatt steht (auf welches ich 
sonst sehr viel Wert lege).

[Heinrich W. (ubik123)]

Stefanus F. schrieb:
> Heinrich W. schrieb:
>> Wenn ich das weiße Kabel rausziehe, dann sind es bei 3: 5 V
>
> Aha, und wetten dann blinkt die LED auch (sehr langsam)?
>
> Die Sache ist die: Der Reset Pin enthält intern einen sehr schwachen
> Pull-Up Widerstand. Sobald da auch nur ein paar cm Draht dran hängen,
> musst du den Pin mit einem stärkeren Pull-Up Widerstand (z.B. 4,7 kΩ)
> beschalten
>
>> Normalerweise müsste es ein Violettes Kabel sein
>
> Wen interessieren die Farben?

Nein, die LED blinkt immer noch nicht.

Komisch, an dem Reset ist, wenn ich das Programmer Kabel rausziehe, 
plötzlich 5.6 V. Naja, egal.

Trotzdem blinkt die LED nicht. Wenn ich die LED mit VCC und GND 
verbinde, dann leuchtet sie.

[Stefan F. (Gast)]

Heinrich W. schrieb:
> Komisch, an dem Reset ist, wenn ich das Programmer Kabel rausziehe,
> plötzlich 5.6 V. Naja, egal.

Das ist gar nicht egal! Wo kommen denn die 5,6V her, wenn dein Netzteil 
nur 5,09V liefert?

Da ist doch irgendwo der Wurm drin, vermutlich schon in der 
Stromversorgung.

[Heinrich W. (ubik123)]

Stefanus F. schrieb:
> Heinrich W. schrieb:
>> Komisch, an dem Reset ist, wenn ich das Programmer Kabel rausziehe,
>> plötzlich 5.6 V. Naja, egal.
>
> Das ist gar nicht egal! Wo kommen denn die 5,6V her, wenn dein Netzteil
> nur 5,09V liefert?
>
> Da ist doch irgendwo der Wurm drin, vermutlich schon in der
> Stromversorgung.

Das ist aber sehr witzig...

Die Stromversorgung liefert 5,09 V an VCC und GND.

Aber zwischen RESET und GND ist 5,8 V...

[Stefan F. (Gast)]

Dir ist schon klar, dass das so, wie es scheint, nicht sein kann?

Zeige doch mal Fotos vom Aufbau mit angeschlossenem Multimeter. Wenn du 
zwei hast, dann messe bitte VCC und Reset gleichzeitig.

[Johann J. (johannjohanson)]

Heinrich W. schrieb:
> Trotzdem blinkt die LED nicht.

Vermutlich schon - Du siehst es nur nicht:

Heinrich W. schrieb:

 while(1)
   {
     PORTB = 0b00000001;          /* Turn on first LED bit/pin in PORTB
 */
 /*    _delay_ms(1000);
 
     PORTB = 0b00000000;          /* UND HIER GELICH WIEDER AUS
     _delay_ms(1000);
 */  }

[Mario (Gast)]

Stefanus F. schrieb:
> 1:      VCC o------(V)-----o PB0
>
> 2:      GND o------(V)-----o PB0

Heinrich W. schrieb:
> Bei 1: 0 V
Heinrich W. schrieb:
> 2: 4 mV


da ist doch der Port Pin nicht als Ausgang definiert, sonst müsste bei 
einer der beiden Messungen Spannung anliegen?!?

[Felix (Gast)]

Wurde ein .lss-File erzeugt? Wenn ja, lade es bitte mal hier hoch. Der 
Assembler-Sourcecode wird offenbaren, ob das Programm korrekt den Pin 
ansteuert.

[Karl (Gast)]

Heinrich W. schrieb:
> #include <avr/io.h>
> #include <util/delay.h>

Mal langsam mit dem Pferden. Nichtgleich alles mögliche versuchen.
Wie sind die Fuse eingestellt und/oder brauche ich einen Quarz?
Erste inbetriebnahme des Prozessors? dann Frequenz korrekt einstellen.
Bleibt bei den Grundlagen und nicht gleich ins volle

[Jörg W. (dl8dtl) (Moderator)]

Karl schrieb:
> Heinrich W. schrieb:
>> #include <avr/io.h>
>> #include <util/delay.h>
>
> Mal langsam mit dem Pferden. Nichtgleich alles mögliche versuchen.

Naja, einen LED-Blinker kann man nun schwerlich als „alles Mögliche“ 
verdammen, das ist ja das „Hello world!“ eines Controllers.

> Wie sind die Fuse eingestellt und/oder brauche ich einen Quarz?

Thread durchgelesen?

Die Fuses stehen auf Default, d.h. das Dingens läuft mit dem internen 
durch 8 geteilten RC-Oszillator mit 1 MHz.

Ohne laufenden Oszillator ließe er sich ja gar nicht erst programmieren.

> Erste inbetriebnahme des Prozessors? dann Frequenz korrekt einstellen.

Sowas von unwichtig: ob die LED nun mit 0,498 Hz oder 0,51 Hz blinkt, 
spielt doch gar keine Rolle. Im Moment „blinkt“ sie mit 0 Hz, und das 
ist gewiss nicht das, was gewollt ist.

[Timo N. (tnn85)]

Bilder vom Aufbau. Ohne das würde ich bei dem Wissensstand vom TO gar 
nicht erst nach Fuses etc. fragen. Das war doch spätestens nach der 
Frage vom TO mit dem fehlenden violetten Programmerkabel klar. @TO: 
nichts für Ungut. War ja nicht böse gemeint.

[Heinrich W. (ubik123)]

Hallo,

im Anhang das Bild der Schaltung.

Leider kann ich nicht gleichzeitig Fotos schießen und messen, weil ich 
nicht keine Klemmen habe.

Aber gemessen habe ich so, dass ich ein weiteres Kabel eingesteckt habe, 
daran den Plus Pol gemessen habe und den Minus Pol am Ende des 
Widerstandes (da wo das blaue Kabel ist).

---

Jetzt habe ich nochmal die Spannung an dem weißen Kabel gemessen und es 
sind 4.2 V. Warum wechselt das?

[jo mei (Gast)]

Heinrich W. schrieb:
> im Anhang das Bild der Schaltung.

Lerne erst mal einen nach Hersteller-Empfehlung fachgerechten
Minimal-Aufbau für so einen Controller zu machen.

OMG!

[Heinrich W. (ubik123)]

jo mei schrieb:
> Heinrich W. schrieb:
>> im Anhang das Bild der Schaltung.
>
> Lerne erst mal einen nach Hersteller-Empfehlung fachgerechten
> Minimal-Aufbau für so einen Controller zu machen.
>
> OMG!

Wieso? So steht es auch im Buch "Make: AVR Programming". Was ist an der 
Schaltung falsch?

[Stefan F. (Gast)]

Die erste Antwort zu deiner Frage war:

Stefanus F. schrieb:
> Eventuell nicht alle VCC und GND Pins angeschlossen?

Heinrich W. schrieb:
> Doch, definitiv angeschlossen.

Und jetzt sehe ich in deinem Foto, dass der rechte (A)VCC Pin nicht 
angeschlossen wurde. Die LED ist übrigens (zur Zeit) auch nicht 
angeschlossen.

Ein Tipp zu den ISP Leitungen: Mach die nicht so lang, wenn du keine 
Lust auf weitere Probleme hast. Das Kabel am Programmieradapter ist aus 
gutem Grund kurz gehalten.

[Jörg W. (dl8dtl) (Moderator)]

Du hast keine Abblockkondensatoren dran, außerdem hast du meiner 
Einschätzung des Fotos nach nicht sowohl Vcc als auch AVcc und beide 
GND-Pins angeschlossen. Zwar sollte sich fehlendes AVcc eher auf Port C 
als auf Port B auswirken, aber gesund ist das auf jeden Fall nicht, denn 
beide Pins dürfen sich nur maximal 0,3 V voneinander unterscheiden.

[Stefan F. (Gast)]

Heinrich W. schrieb:
> Jetzt habe ich nochmal die Spannung an dem weißen Kabel gemessen und es
> sind 4.2 V. Warum wechselt das?

Stefanus F. schrieb:
> Die Sache ist die: Der Reset Pin enthält intern einen sehr schwachen
> Pull-Up Widerstand. Sobald da auch nur ein paar cm Draht dran hängen,
> musst du den Pin mit einem stärkeren Pull-Up Widerstand (z.B. 4,7 kΩ)
> beschalten

[Einer K. (Gast)]

Heinrich W. schrieb:
> Was ist an der
> Schaltung falsch?

Abblockkondensatoren fehlen.
Nur 2 der 4 Versorgungsanschlüsse verwendet.

Heinrich W. schrieb:
> So steht es auch im Buch "Make: AVR Programming".
Das ist nicht das Datenblatt des Herstellers.

[Stefan F. (Gast)]

Heinrich W. schrieb:
> So steht es auch im Buch "Make: AVR Programming".

Kannst die Seite mal fotografieren?

[Heinrich W. (ubik123)]

Stefanus F. schrieb:
> Heinrich W. schrieb:
>> So steht es auch im Buch "Make: AVR Programming".
>
> Kannst die Seite mal fotografieren?

[Stefan F. (Gast)]

Heinrich, diese Seite zeigt lediglich die Pins an, die mit dem 
Programmieradapter verbunden werden sollen.

Das ist gut so, ich hatte schon befürchtet, dass das Buch fehlerhaft 
sei.

Zur Minimalbeschaltung (Versorgungsspannung, Reset und 
Abblock-Kondensatoren) sollte das Buch an anderer Stelle etwas sagen.

[jo mei (Gast)]

Heinrich W. schrieb:
> avr-gcc -Wall -Os -DF_CPU=16000000UL -mmcu=atmega168 -c main.c -o main.o
----------------------------^^^^^^^^^^

Heinrich W. schrieb:
> Was ist an der Schaltung falsch?

Wo ist der Quarz der deinen Prozessor antreiben soll?

OMG!

[Stefan F. (Gast)]

jo mei schrieb:
> Wo ist der Quarz der deinen Prozessor antreiben soll?

Nicht nötig.

Die Falsche F_CPU Angabe hatten wir bereit diskutiert, er hat aber ein 
grundsätzlicheres Problem.

[jo mei (Gast)]

Stefanus F. schrieb:
> er hat aber ein grundsätzlicheres Problem.

Ja, das hat er:

Er will von Null auf hundert in 5 Sekunden,
hat aber kein Auto und geht auf Krücken.

[Stefan F. (Gast)]

jo mei schrieb:
> Er will von Null auf hundert in 5 Sekunden,
> hat aber kein Auto und geht auf Krücken.

Quatsch. Womit solle r denn sonst anfangen, als mit einem LED Blinker?

Er hat ein Auto (µC) und statt Krücken hat er genug Steckbretter, 
ordentliche Dupont Kabel und einen hochwertigen Programmieradapter.

[Gaby (Gast)]

Wo kommt die Versorgungsspannung her?
Der Programmer liefert die nicht.

[Jörg W. (dl8dtl) (Moderator)]

Gaby schrieb:
> Wo kommt die Versorgungsspannung her?

Von rechts unterm Schreibtisch. :)

[Stefan F. (Gast)]

Willst du nicht den Abblock-Kondensator und Pull-Up Widerstand 
hinzufügen?

Abblock-Kondensator heisst: 1x 100nF lins und einmal 100nF rechts and 
(A)VCC und GND direkt neben den µC stecken.

Pull-Up Widerstand: 1k bis 10k Ω von Reset nach VCC.

[Jörg W. (dl8dtl) (Moderator)]

Wobei der Pullup nebensächlich ist, es muss auch ohne funktionieren. Ist 
ja schließlich ein interner Pullup dran.

[Stefan F. (Gast)]

Jörg W. schrieb:
> Wobei der Pullup nebensächlich ist, es muss auch ohne
> funktionieren. Ist
> ja schließlich ein interner Pullup dran.

Er hat 4,1V gemessen, wenn der Programmieradapter noch dran hängt. Das 
ist laut Datenblatt ein ungültiger Pegel. Beim Reset Pin gelten andere 
Grenzwerte, als bei normalen I/O Pins.

[Bernd (Gast)]

Stefanus F. schrieb:

> Er hat 4,1V gemessen, wenn der Programmieradapter noch dran hängt.

Aber nur weil er ein Kabel des Programmers (weiß, violett, o. s.) mit 
dem Reset-Pin verbunden hatte.

[Jörg W. (dl8dtl) (Moderator)]

Stefanus F. schrieb:
> Er hat 4,1V gemessen, wenn der Programmieradapter noch dran hängt.

Dennoch habe ich schon oft genug irgendwo einen AVRISP2 ohne Pullups 
benutzt, das funktioniert. Ist sicher nicht besonders schön, aber 
daran liegt sein Problem sehr wahrscheinlich nicht.

Ich habe gerade keinen ATmega*8 rumliegen, um einen vergleichbaren 
Testaufbau zu machen.

[Heinrich W. (ubik123)]

Hallo,

danke für die vielen Antworten.

Also was soll ich als nächstes machen?

Den Kondensator mit VCC und GND verbinden? Warum muss eigentlich ein 
Kondensator zwischen VCC und GND geschaltet werden? Um eine gleichmäßige 
Stromversorgung zu gewährleisten?


Was mir noch aufgefallen ist:

Das erste mal, als ich mit dem AVRisp XPII den Microchip flashen wollte, 
konnte ich das ohne externe Spannungsversorgung tun. Nun aber 
funktioniert das flashen nur noch mit externer Spannungsversorgung (also 
mit den 5 V aus dem USB Kabel).


Soll ich den jetzigen Microcontroller wegschmeißen? Ich hab mir 4 Stück 
bei Ebay gekauft. Vielleicht funktionieren Sie deswegen nicht richtig... 
:-)

Ich hab schon einen ausgetauscht, hat aber nichts gebracht.

Das ist das erste Mal, dass ich etwas mit Microcontrollern mache, von 
daher seid mir nicht böse.

[Frank M. (ukw) (Moderator)]

Heinrich W. schrieb:
> Den Kondensator mit VCC und GND verbinden?

Jepp. Am besten 100nF (Keramik).

> Warum muss eigentlich ein
> Kondensator zwischen VCC und GND geschaltet werden? Um eine gleichmäßige
> Stromversorgung zu gewährleisten?

https://de.wikipedia.org/wiki/Blockkondensator

Der erste Abschnitt sagt eigentlich alles wichtige:

Blockkondensator (auch Abblockkondensator, Stützkondensator oder 
Siebkondensator) bezeichnet in der Elektrotechnik einen Kondensator, der 
in einer Schaltung die Betriebsspannung an lokalen Schaltkreisen 
aufrechterhält. Die Betriebsspannung bricht bei Schaltvorgängen 
impulsartig ein. Diese werden durch den Kondensator aufgefangen bzw. 
blockiert, indem er Energie aufnimmt oder zuvor gespeicherte Energie 
abgibt und so gegen Spannungseinbrüche schützt.

[Jörg W. (dl8dtl) (Moderator)]

Heinrich W. schrieb:

> Den Kondensator mit VCC und GND verbinden?

Auf jeden Fall, und auch den zweiten GND-Pin sowie AVcc anschließen.

> Warum muss eigentlich ein
> Kondensator zwischen VCC und GND geschaltet werden? Um eine gleichmäßige
> Stromversorgung zu gewährleisten?

Um Stromspitzen abzufangen, die beim Umschalten von CMOS-Gattern 
auftreten und zu Spannungseinbrüchen führen.

> Das erste mal, als ich mit dem AVRisp XPII

Das Teil heißt übrigens AVRISPmkII oder einfach AVRISP2.

> den Microchip flashen wollte,
> konnte ich das ohne externe Spannungsversorgung tun.

Das ist hochgradig mysteriös. Da musst du wohl ein Perpetuum Mobile 
erfunden haben, denn das AVRISPmkII liefert definitiv keine 
Stromversorgung. Sein Pin 2 dient lediglich dazu, die an den Leitungen 
befindlichen Pegelwandler so zu betreiben, dass sie die Adaptierung 
zwischen den Pegeln deines Controllers (der ja je nach Controller ab 1,8 
V bis maximal 5,5 V betrieben werden kann) und dem des AVRISP vornehmen, 
welches intern mit 5 V arbeitet (vom USB).

> Soll ich den jetzigen Microcontroller wegschmeißen?

Nicht deswegen. Wenn du ihn geschrottet hast, dann höchstens durch das 
Nichtanschließen von AVcc, denn damit verletzt du die Grenzwerte des 
Datenblatts. Allerdings habe ich bislang noch nicht gehört, dass 
deswegen jemandem ein AVR gestorben wäre.

[Frank M. (ukw) (Moderator)]

Jörg W. schrieb:
> Das ist hochgradig mysteriös. Da musst du wohl ein Perpetuum Mobile
> erfunden haben, denn das AVRISPmkII liefert definitiv keine
> Stromversorgung.

Korrekt. Hier wird nur die Betriebsspannung gemessen.

Vermutlich wurde der µC durch die Schutzdioden über die Datenleitungen 
mit Strom versorgt. Das ist mir auch schon mal passiert, als ich 
nachträglich bemerkte, dass die Spannungsversorgung gar nicht richtig 
angeschlossen, der µC aber trotzdem korrekt geflasht war.

[Jörg W. (dl8dtl) (Moderator)]

Frank M. schrieb:
> Vermutlich wurde der µC durch die Schutzdioden über die Datenleitungen
> mit Strom versorgt.

Hmm, aber dass man ihn damit auch erfolgreich programmieren könnte, wäre 
schon ziemlich unwahrscheinlich, denn dann müsste ja stets wenigstens 
eine der Leitungen MOSI oder SCK High-Potenzial haben (/RESET ist 
während der Programmierung dauerhaft low). Selbst, wenn man nur 1-Bits 
programmieren möchte, müssen ja zwischendrin Opcodes gesendet werden, 
die auch mal 0-Bits enthalten.

[Frank M. (ukw) (Moderator)]

Jörg W. schrieb:
> Hmm, aber dass man ihn damit auch erfolgreich programmieren könnte, wäre
> schon ziemlich unwahrscheinlich, denn dann müsste ja stets wenigstens
> eine der Leitungen MOSI oder SCK High-Potenzial haben (/RESET ist
> während der Programmierung dauerhaft low).

Ja, genau das kam mir damals auch spanisch vor. Hat aber 
(reproduzierbar) funktioniert. Auch der Verify ging durch. Ich habe aber 
trotzdem zur Sicherheit nochmal mit angeschlossener Versorgungsspannung 
geflasht, als ich den Fehler bemerkte.

Passiert ist mir das damals mit dem Pollin-AVR-Evaluationsboard. Dort 
sind die Abblockkondensatoren aber ausreichend vorhanden - für jeden 
AVR-Sockel (3 insgesamt). Ob diese dem µC über die Low-Pegel 
hinweggeholfen haben?

[malsehen (Gast)]

Programmieren ohne Versorgungsspannung
hatte ich auch schon.
War ein Tiny mit 100nF und 10µF, sonst nichts.
Programmer definitiv ohne Versorgung
der Schaltung.

[Jörg W. (dl8dtl) (Moderator)]

Frank M. schrieb:
> Ob diese dem µC über die Low-Pegel hinweggeholfen haben?

Das kann ich mir schon vorstellen.

[Stefan F. (Gast)]

Heinrich W. schrieb:
> Also was soll ich als nächstes machen?

Das hat man Dir gefühlt 10x geschrieben. Warum baust du die 
Kondensatoren nicht ein? Und warum informierst du dich nicht erstmal 
selbst, wozu die gut sind? Wir können dich nicht schlau machen, das 
musst du selber tun.

> Nun aber funktioniert das flashen nur noch mit externer
> Spannungsversorgung

Logisch, ergibt sich aus dem Aufbau deines Programmieradapters und es 
steht unmissverständlich in dessen Bedienungsanleitung.

Wo deine weiter oben genannten 5,6V herkommen, ist immer noch ungeklärt. 
Du solltest das herausfinden. Damit klärt sich vielleicht auf die Frage, 
wieso du den Chip ohne Stromversorgung programmieren konntest.

Ich bin ein bisschen enttäuscht, dass du unsere Ratschläge so zögerlich 
bis gar nicht angenommen hast.

[Alexander S. (alesi)]

Heinrich W. schrieb:
> Also was soll ich als nächstes machen?
>
> Den Kondensator mit VCC und GND verbinden?

Hallo, evtl. hilft dieses Bild
https://www.mikrocontroller.net/wikifiles/2/22/Tutorial_grundschaltung_breadboard.jpg
aus dem AVR-Tutorial
https://www.mikrocontroller.net/articles/AVR-Tutorial:_Equipment#Beispielhafter_Aufbau_auf_einem_Steckbrett

Den Quarz und den Spannungsregler brauchst Du bei Deinem Aufbau erstmal 
nicht. Vorausgesetzt Deine Stromversorgung ist ausreichend stabil.

[Raph (Gast)]

Frank M. schrieb:
> Abblockkondensator

ist was für Anfänger und Moderatoren :)

[Heinrich W. (ubik123)]

Hallo,

ich werde mich am Wochenende melden. Bis dahin habe ich leider zu tun.

Aber: Was soll den der Kondensator denn bewirken? Ist er unbedingt sooo 
wichtig? Ich meine: Wenn ich doch über ein USB Kabel mit Strom versorge, 
dann kann ich mir doch ziemlich sicher sein, dass die 5.1 V konstant 
sind.

[c-hater (Gast)]

Heinrich W. schrieb:
> Hallo,
>
> ich werde mich am Wochenende melden. Bis dahin habe ich leider zu tun.
>
> Aber: Was soll den der Kondensator denn bewirken? Ist er unbedingt sooo
> wichtig? Ich meine: Wenn ich doch über ein USB Kabel mit Strom versorge,
> dann kann ich mir doch ziemlich sicher sein, dass die 5.1 V konstant
> sind.

Harharhar...

Lies' einfach mal die USB-Specs. Da steht, wessen du dir sicher sein 
kannst. Und das auch nur, wenn alle sich dran halten. Was eigentlich 
niemals in der Geschichte von USB jemals wirklich der Fall war...

[Jörg W. (dl8dtl) (Moderator)]

Heinrich W. schrieb:
> Wenn ich doch über ein USB Kabel mit Strom versorge

… dann hast du da einige µH Induktivität drin.

Es geht um Stromspitzen, und die möchte man möglichst nahe am Chip 
puffern, ansonsten bricht dem Chip (kurzzeitig) die Spannung ein. Die 
Folge davon ist das, was ein Compilerbauer „undefined behaviour“ nennen 
würde, da können dann schon auch mal beide Ausgänge eines Flipflops den 
gleichen Pegel haben oder sowas. Es gibt dann schlicht keine 
Funktionsgarantie mehr auf irgendwas.

[Rat Vermeider (Gast)]

Heinrich W. schrieb:
> Was soll den der Kondensator denn bewirken?

Du bist offensichtlich der Fachmann. Du weisst alles,
bekommst deine Hardware auch sofort zum Laufen und brauchst
daher unsere Ratschläge nicht. Daher schreibst du ja auch
hier im Forum.

Und da du unsere Ratschläge nicht brauchst, kannst du auch
getrost jeglichen Kondensator weglassen den man dir nahelegt.

[Stefan F. (Gast)]

Du solltest bedenken, dass CMOS Chips kurzzeitig richtig viel Strom 
ziehen, und zwar immer dann, wenn Signale ihre Pegel wechseln. Das 
können durchaus einige hundert Milliampere sein!

Wenn der Chip z.B. Pulsweise 500mA aufnimmt und das Kabel samt Stecker 
1Ω Innenwiderstand hat, dann hast du (ohne Kondensatoren) schon 
Schwankungen um 500mV!

1Ω x 500mA = 500mV

Dazu kommt, das jedes Kabel eine gewisse induktive Komponente enthält - 
wie bei Spulen. Spulen haben die Eigenschaft, die Stromstärke zu 
stabilisieren, aber die Spannung zu destabilisieren. Denn sie haben für 
hohe Frequenzen (kurze Impulse) einen hohen Widerstand.

Da kann dann so ein 500mA Puls schnell dafür sorgen, dass die Spannung 
um mehrere Volt absackt. Rechne das mal beispielhaft für 10µH aus:

2 x pi x 16Mhz x 10µH = 1005Ω

und

1005Ω x 500mA = 500 Volt

-> Also ein Totalausfall. Den hättest du sogar schon bei 0,1µH!

Das ist jetzt alles noch stark vereinfacht dargestellt, aber es 
verdeutlicht den Kern der Problematik.

[Joe G. (feinmechaniker)]

Hallo Heinrich,

erfahrungsgemäß wird eine Fehlersuche um so komplexer, je mehr 
Komponenten daran beteiligt sind. Deshalb würde ich mich an deiner Stele 
zunächst auf eine funktionierende Hardware beschränken. Erst wenn diese 
funktioniert, kannst du dich beruhigt der Software zuwenden. Um das 
Henne-Ei Problem zu lösen, habe ich dir eine kleine HEX-Datei beigefügt. 
Diese lässt eine LED an PortB.0 im Sekundentakt blinken.

Systemeinstellungen:
- Chip ATmega168p
- interner Oszillator, 1 MHz
- PortB.0 Output

Viel Erfolg!

[Heinrich W. (ubik123)]

@Joe:

Ich hab die Datei geladen, aber es passiert nichts.


avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 
0.06s

avrdude: Device signature = 0x1e9406
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be 
performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "Test.hex"
avrdude: input file Test.hex auto detected as Intel Hex
avrdude: writing flash (234 bytes):

Writing | ################################################## | 100% 
4.10s

avrdude: 234 bytes of flash written
avrdude: verifying flash memory against Test.hex:
avrdude: load data flash data from input file Test.hex:
avrdude: input file Test.hex auto detected as Intel Hex
avrdude: input file Test.hex contains 234 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 
4.44s

avrdude: verifying ...
avrdude: 234 bytes of flash verified

avrdude: safemode: Fuses OK (H:01, E:DF, L:62)

avrdude done.  Thank you.




Die LED blinkt nicht.

Ich habe den Kondensator hinzugefügt, aber auch das hat nichts gebracht.

Ich habe mal an jedem Ausgang die Spannung gemessen und es kommt überall 
1 Volt raus, bis auf bei der Stromversorgung, dem weißen Kabel und bei 
PB0.

Bei PB0 kommt 0 Volt raus.

Ich weiß nicht, wieso eine einfache Sache scheinbar so schwierig ist...

[Frank M. (ukw) (Moderator)]

Heinrich W. schrieb:
> Ich habe den Kondensator hinzugefügt, aber auch das hat nichts gebracht.

Wer hat da auch von einem Elko gesprochen? Die Rede war von einem 100nF 
Keramikkondensator (Kerko) - und zwar jeweils an allen 
Spannungsanschlüssen. Dazu gehört auch AVcc!

> Ich weiß nicht, wieso eine einfache Sache scheinbar so schwierig ist...

Auf dem Bild kann man so gut wie nichts erkennen. Einmal, weil es 
unscharf ist, außerdem, weil der µC irgendwo hinten in der Ecke lungert.

Kannst Du bitte mal eine scharfe(!) Nahaufnahme machen, damit man 
nachvollziehen kann, was da überhaupt verdrahtet ist?

Versorgst Du überhaupt AVcc mit 5V, wie oben schon mehrfach angesprochen 
wurde?

[Stefan F. (Gast)]

Immer noch kein Pull-Up Widerstand am Reset Pin?
Wenn er jetzt 5V hat, dann will ich nicht meckern. Aber vor ein paar 
Tagen waren es ja noch ungültige 4,1V.

Kontrolliere das. So ein AVR hat nämlich eigentlich nur ganz wenige 
Voraussetzungen, um zu funktionieren:

- Stromversorgung and alle (A)VCC und GND Pins (2,8 - 5,5V und stabil)
- Reset Pin muss High sein (>0,9 x VCC)
- Fuses richtig eingestellt (checked)
- Programm ist im Flash (checked)

Das war es schon. Wenn er damit nicht funktioniert, ist er kaputt.

[Joe G. (feinmechaniker)]

Hier mal eine Datei, die die Pins PortD0-PortD3 blinken läßt. Nur für 
den Fall, dass PortB defekt ist.

[Joe G. (feinmechaniker)]

Zum Schluss noch eine Variante mit

PortB.0
PortB.1
PortC.0
PortC.1
PortD.0
PortD.1

Sie blinken bei mir alle wunderbar im 1 Sekunden Takt. Ich habe extra 
einen Atmega168 rausgekramt.

[Frickler Assistent (Gast)]

Ich verstehe wirklich nicht warum man sich oft mit Händen und Füssen 
töricht sträubt sich an die Hersteller Empfehlungen im DaBla. und App. 
Notes zu halten und Vieles besser glaubt zu wissen.

Gerade am Anfang, wenn man noch mit der Beherrschung des uC und der 
Sprache programmatisch zu kämpfen hat, sollte man sich zumindest total 
auf die HW verlassen können. Zweifrontenkrieg oder gar schlimmer lohnt 
sich in den wenigsten Fällen wie die Geschichte beweist.

Ich bin auch der Meinung, daß man das Programmieren auf verläßlicher HW 
machen sollte um sich besser und schneller mit den Eigenheiten des uC 
und der Programmiersprache vertraut machen zu können. Sich tagelang mit 
unnötigen Problemen herumschlagen zu müssen erhöht nur das generelle 
Frust Niveau.

Viele der vesprochenen uC und Elektronik Probleme hier im Forum sind 
unnötig und oft durch Ignoranz und "Ich weiß es besser" Einstellung in 
die Welt gerufen und verschwenden deshalb viel Zeit die man besser zum 
wirklichen und produktiven Lernen ausnützen könnte.

[Olaf B. (Firma: OBUP) (obrecht)]

@FricklerAssistent:
  + Mecker nicht rum!
  + jeder hat mit Null Wissen angefangen.

- oder kannst Du den TS auswendig?
- sämtliche Spez.  Errate  DaBl. - z.B. ARM v7 - im Kopp?
- fliegender Aufbau ohne Fehler - auch mit Fädeldraht

Hast Du was Konstruktives beizutragen?
Falls nein - trolle woanders...

@TO:
  - Schaltungsaufbau liefern - so wie verdrahtet auf BB.
  - macht einiges leichter, muß  man nicht raten
  - Vorschläge Vorredner ausgeführt?
  - langt auch als Zeichnung per Din A4 - aber so wie jetzt als 
Schaltung   aufgebaut
  - LA zur Hand f. Visualisierung Signale µC

[Joe G. (feinmechaniker)]

Ich vermute eher ein generelles Problem. Die AVR’s sind unglaublich 
robust. Die hier erfolgten Hinweise sind zwar alle recht nützlich im 
späteren Schaltungsdesign, doch für eine grundsätzliche Fehlersuche 
zunächst nicht nötig. Ich habe gerade mal einen ATmega8 auf ein 
Steckbrett gefädelt, ohne Abblockkondensatoren, ohne Reset-Beschaltung, 
mit langen Leitungen, ohne Aref nur einmal Vcc und GND auf einer Seite, 
eigentlich alles was man falsch machen kann. Was soll ich sagen? Alle 5 
IC’s die ich noch habe lassen sich programmieren und blinken wunderbar 
im Sekundentakt an B0.

[jo mei (Gast)]

Joe G. schrieb:
> Was soll ich sagen? Alle 5
> IC’s die ich noch habe lassen sich programmieren und blinken wunderbar
> im Sekundentakt an B0.

Du hast deine Stromversorgung weder gezeigt noch spezifiziert.

Aber ich wette du hast genau das gleiche Netzteil wie der TO,
nicht wahr (gelle)? Und natürlich auch genau die gleiche
Verdrahtung und Leitungslängen und das gleiche Steckbrett
und ....

[Olaf B. (Firma: OBUP) (obrecht)]

@Joe G.:
Glaube ich Dir.

AVRs sind robust designt. Verzeihen Dir viele Fehler - vor allem im 
Bereich HW. Anders bei PICs & ARMs
Die Basics einer Beschaltung µC gem DaBl. sollte man trotzdem 
beherzigen.
Hilft viel bei Umstellung auf andere - komplexere - µC.

Sollte vielleicht doch an Tausch µC denken. Alles verträgt selbst ein 
AVR nicht. :-)

[Joe G. (feinmechaniker)]

jo mei schrieb:
> Du hast deine Stromversorgung weder gezeigt noch spezifiziert.

5V vom USB-Port des PC mit 2.5m USB-Kabellänge. Aber das ist nicht der 
eigentliche Punkt. Für eine systematische Fehlersuche ist es zunächst 
unerheblich um 100n oder 200n oder Aref… Hier scheint generell ein 
Fehler vorzuliegen – und genau dieser sollte gefunden werden.

Mein Vorschlag zur Fehlereingrenzung.
1. AVR mit BCD.HEX flashen und rücklesen wenn OK dann
2. AVR nur mit 5V und GND verbinden sowie Vorwiderstand und LED an PB0. 
Kein Blinken, dann
3. Vorwiderstand und LED an PC0. Kein Blinken, dann
4. Vorwiderstand und LED an PD0.  Kein Blinken, dann…

LED defekt? LED nicht korrekt gepolt? LED nicht an Vcc?

[Olaf B. (Firma: OBUP) (obrecht)]

Joe G. schrieb:
> AVR mit BCD.HEX flashen und rücklesen

übernimmt doch avrdude bei flashen...

Möglichkeit µC putt auch in Betracht ziehen.

Ansonsten minimale Beschaltung gem. DaBl auf BB aufbauen, flashen & 
testen.

[Johann J. (johannjohanson)]

Heinrich W. schrieb:
> Warum hab ich kein violettes Kabel an dem Programmer?

Vermutlich gefiel den Herstellern die Farbe nicht.

[Olaf B. (Firma: OBUP) (obrecht)]

was soll der Scheiss...

Ist das hilfreich?

[Johann J. (johannjohanson)]

Olaf B. schrieb:
> Ist das hilfreich?

Ist Dein Beitrag hilfreich?

Aber speziell für Dich: Schau die mal die Farbe(n) an den Kabeln des 
"Pogrammers" (ISP Mk II) an und frage Dich wo da ein violettes Kabel 
sein sollte (welches nicht da sein soll).

Beitrag "Re: Atmega128 - Programm wird geladen, aber LED blinkt nicht?"

Trollig.

[Olaf B. (Firma: OBUP) (obrecht)]

Mich interessiert nicht die Farbe eines Kabels bei einer 
Steckerbelegung, sondern das Signal, die Info was damit übertragen 
werden soll.

Erinnert mich irgendwie an Entschärfung v. Bomben: welches Kabel hättens 
denn gerne - rot || grün

[Alexander S. (alesi)]

Heinrich W. schrieb:
> Ich hab die Datei geladen, aber es passiert nichts.

Hallo Heinrich,

kannst Du die LED näher am AVR plazieren und ein Foto nur vom AVR und 
seiner näheren Umgebung machen, ähnlich wie hier?

Beitrag "Re: Atmega128 - Programm wird geladen, aber LED blinkt nicht?"

Lässt Du den AVR-ISP nach dem Brennen angeschlossen?

[Heinrich W. (ubik123)]

Joe G. schrieb:
> Hier mal eine Datei, die die Pins PortD0-PortD3 blinken läßt. Nur für
> den Fall, dass PortB defekt ist.

Ha, siehe da, es blinkt! :-)

Ehm. Kannst du hier den Quellcode posten und wie oder womit das 
kompiliert hast?

[Johann J. (johannjohanson)]

Olaf B. schrieb:
> Mich interessiert nicht die Farbe eines Kabels bei einer
> Steckerbelegung, sondern das Signal, die Info was damit übertragen
> werden soll.
>
> Erinnert mich irgendwie an Entschärfung v. Bomben: welches Kabel hättens
> denn gerne - rot || grün

Johann J. schrieb:
> Ist Dein Beitrag hilfreich?

[Alexander S. (alesi)]

Joe G. schrieb:
> Ich habe gerade mal einen ATmega8 auf ein
> Steckbrett gefädelt, ohne Abblockkondensatoren,

Und ich habe einmal einen ATmega auf einem Steckbrett über 2 Jumperkabel 
mit 5 V und GND von einem STK500 versorgt: ohne dicken Elko (>1000 uF) 
auf dem Steckbrett hat die Schaltung nicht funktioniert.

[Frickler Assistent (Gast)]

Olaf B. schrieb:
> @FricklerAssistent:
>   + Mecker nicht rum!
>   + jeder hat mit Null Wissen angefangen.
>
> - oder kannst Du den TS auswendig?
> - sämtliche Spez.  Errate  DaBl. - z.B. ARM v7 - im Kopp?
> - fliegender Aufbau ohne Fehler - auch mit Fädeldraht
>
> Hast Du was Konstruktives beizutragen?
> Falls nein - trolle woanders...
>
> @TO:
>   - Schaltungsaufbau liefern - so wie verdrahtet auf BB.
>   - macht einiges leichter, muß  man nicht raten
>   - Vorschläge Vorredner ausgeführt?
>   - langt auch als Zeichnung per Din A4 - aber so wie jetzt als
> Schaltung   aufgebaut
>   - LA zur Hand f. Visualisierung Signale µC

Was ist an meinem Kommentar so verwerflich? Sich an die DaBla 
Empfehlungen und App Notes zu halten ist das mindeste was der Hersteller 
von seinen Kunden erwarten kann. Davon ist auch der Anfänger nicht 
entschuldigt. Und wenn er was nicht versteht, dann ist das Forum hier 
Zur möglichen Hilfe.

Es ist unstreitbar die Tatsache, daß viele der im Forum aufgeworfenen 
Fragen und Probleme vieler Personen durch Nichtbeachtung fundamentaler 
und lange etablierter Fakten der Elektronik resultieren.

Man braucht nicht das ganze DaBla und Errata auswendig zu kennen. Die 
Errata sollte man aber zumindest einmal durchfliegen um relevante 
Hardware der Anwendung im Griff zu haben. Aber die 
Anwendungsspezifischen HW Hinweise sollte man als Neuling zumindest 
versucht studiert haben. Der Rest ist Referenzmaterial. Ob das ein AVR, 
PIC oder ein ARM7 ist spielt kaum eine Rolle. Ohne Fleiß kein Preis.

Auch hilft es ein Laborbuch zu führen wo Praxishinweise helfen Fakten 
zugreifsbereit zu haben.

Habe ich was Konstruktives beizutragen? Habe ich hier schon oft getan. 
Und wenn nicht hilft das Datenblatt.

Auch mit Fädeldraht kann man gut funktionierende Schaltungen aufbauen.

Das war absolut nicht als Trollbeitrag beabsichtigt. Aber wie dem auch 
sei; dann bin ich halt ein Troll und werde die schwere Würde tragen:-)

[Stefan F. (Gast)]

Frickler Assistent schrieb:
> Auch hilft es ein Laborbuch zu führen

Was ist das?

[Frickler Assistent (Gast)]

Stefanus F. schrieb:
> Frickler Assistent schrieb:
>> Auch hilft es ein Laborbuch zu führen
>
> Was ist das?

Die Wiki trifft das ziemlich gut:

https://de.m.wikipedia.org/wiki/Laborjournal

[Heinrich W. (ubik123)]

@Joe G.:

Hallo Joe,

deine Programme haben die LED erfolgreich zum blinken gebracht.

Mich würde nur interessieren, wie der Quelltextcode aussieht und mit 
welchen Befehlen du kompiliert hast. :-)

[Joe G. (feinmechaniker)]

Heinrich W. schrieb:
> Hallo Joe,
> deine Programme haben die LED erfolgreich zum blinken gebracht.

Prima, das ist doch schon ein Fortschritt. Dann ist deine Hardware 
zunächst funktionsfähig. Zum zweiten Schritt, der Software, kann ich nur 
bedingt behilflich sein, da ich kein C verwendet haben. Prinzipiell ist 
die Funktion jedoch auch in meinem Programm ersichtlich.

[Einer K. (Gast)]

avr-objdump -m avr -D dateiname.hex

[Joe G. (feinmechaniker)]

Hallo Heinrich,

hier mal die Variante in C. Hier blinkt allerdings nur PB0.

[Einer K. (Gast)]

> PORTB = 0b00000000;  // PB5 = Low
Ist an der Stelle sowohl falsch, als auch richtig.

Empfehlung:
Besser keine, als falsche/verwirrende, Kommentare

[Joe G. (feinmechaniker)]

Vielen Dank für den Hinweis auf den Fehler im Kommentar.
Es sollte PB0 = Low lauten.

[Heinrich W. (ubik123)]

Oh man, ihr werdet nicht glauben, was die Ursache war, dass die LED 
nicht geleuchtet hat.

Der PIN B0 war auf der Platine verbogen... Jetzt hab ich ihn gerade 
gebogen und es klappt alles.

Trotzdem danke und entschuldigung für die Umstände.

[Einer K. (Gast)]

Das ist ganz normal.

> Der Weg in die Hölle ist mit falschen Annahmen gepflastert.

Hier die nicht in Zweifel gezogene Kausalkette:
> Ich habe den AVR ins Breadboard gesteckt, also
> haben auch alle Pins eine Verbindung mit dem Board.

Tipp:
Ordne allen Annahmen eine Wahrscheinlichkeit zu.
(oder mache bessere Fotos)

[Johann J. (johannjohanson)]

Heinrich W. schrieb:
> auf der Platine

nö - Breadboard - und bei guten Fotos hätte das auch jeder erkennen 
können.

[Joe G. (feinmechaniker)]

Heinrich W. schrieb:
> Trotzdem danke und entschuldigung für die Umstände.

Keine Ursache, genau dafür ist doch ein Forum wie dieses da :-)

[Stefan F. (Gast)]

Arduino Fanboy D. schrieb:
>> PORTB = 0b00000000;  // PB5 = Low

Joe G. schrieb:
> Vielen Dank für den Hinweis auf den Fehler im Kommentar.
> Es sollte PB0 = Low lauten.

Facepalm. Der Kommentar muss korrekt lauten: PB alle Pins = Low