www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Programmierung von ATmega8-16PU macht Probleme


Autor: Christian W. (christian_w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich hab eine kleine Platine aufgebaut mit einem ATmega8-16PU. Ich kann 
diesen aber leider nicht programmieren, PonyProg sagt mir "Device 
missing or unknown Device (-24)". Ein Klick auf "Ignorieren" bringt auch 
nichts, nach einigen Sekunden heißt es "Write failed". Ich habe den 
Quellcode in C mit AVR Studio 4 erstellt und mit PonyProg dann die 
hex-Datei geöffnet, und versucht auf den IC zu schreiben.

Hier mal einige Informationen:

- Alle +5V Spannungsversorgen liegen an den Chip-Beinchen an (5V kommen 
von einem 7805)
- Alle Masseverbindungen des ICs sind beschaltet
- Ich verwende an den PINS 9 und 10 einen 4.0000 Mhz Quarz mit zwei 22pF 
Kondensatoren
- Der ATmega ist nagelneu
- Alle Kontakte auf dem IC-Sockel haben einwandfreie Verbindung
- Alle PINs von der Programmierbuchse (Wannenstecker) gehen zu den 
richtigen PINs am ATmega. Spannungsversorgung +5V am Programmierstecker 
liegt ebenfalls an.

Hat jemand eine Idee?

Mir fällt als Fehlerquelle folgendes ein:

- falscher serieller Adapter? Dieser hier: 
http://www.anvilex.de/Extern/Datasheets/DS_P009_10.pdf
- fehlende Kondensatoren direkt an den Spannungseingängen am IC (100nF)?
- Falscher Quarz? Ich verwende einen 4,0000 statt 3,6864?

Vielleicht ist es auch nur ein ganz einfacher Anfängerfehler, ich hab 
noch nie einen ATmega programmiert...

Danke

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian W. schrieb:
> - Der ATmega ist nagelneu

Das könnte das Problem sein. Hast Du schon Fuses setzen können? Neue 
ATmegas laufen mit internem 8 MHz Takt und Takteiler 8. Resultat sind 1 
MHz Taktfrequenz. Das ist beim Programmieren mittels ISP zu beachten, da 
die maximale Frequenz der ISP-Clock um einen gewissen Teiler kleiner 
sein muss. Leider habe ich den Teiler gerade nicht im Kopf (4?).

Christian W. schrieb:
> - Falscher Quarz? Ich verwende einen 4,0000 statt 3,6864?

Der Quarz geht einem nagelneuen ATmega am Boppes vorbei. ;) Der läuft - 
solange die Fuses diesbezüglich nicht gesetzt sind - mit 1 MHz (8 MHz 
interner Takt mit Taktteiler 8).

Christian W. schrieb:
> - fehlende Kondensatoren direkt an den Spannungseingängen am IC (100nF)?

Sollte nicht Ursache für Dein Problem sein, solche Kondensatoren sind 
aber sehr empfehlenswert.

Autor: Klaus De lisson (kolisson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo  Christian W. ,

>   Ein Klick auf "Ignorieren" bringt auch nichts

das haben auch schon viele Hasen gesagt, die dann im Schlund des Adlers 
endeten.

Leider konnten wir diese Hasen nicht mehr befragen!

 Gastino G. sagte schon was  dazu.

schritt 1:
einen kleinen Messpin an GND des Prozessors löten
schritt 2
Minuskabel des  Multimeters an diesen Messpin
schritt 3 :
Mit Multimetre dann messen an VCC und dann an RESET

beide müssen High sein
RESET fällt kurz auf LOW bei jedem versuch zu programmieren (kann man 
messen)

TIPP:
meistens sind MISO oder MOSI vertauscht

grussi klausi

Autor: Christian W. (christian_w)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, danke für die Beiträge. Ich werd das alles mal testen. Fusebits 
kann ich leider nicht setzen, geschweige denn auslesen aus dem Chip, 
jedesmal kommt diese "Device missing..." Meldung.

Hab mal einen Schaltplan angehängt, wie die Platine momentan aussieht, 
vielleicht hat jemand Lust, mal kurz drüberzuschauen.

Danke

Christian

Autor: \0 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du im Ponyprog-Einstellungsfenster "Siprog-API" ausgewählt?
Pullup an /Reset vorhanden? Falsche Reset-Polarität ausgewählt?
"Calibration"durchgeführt?
Manchmal hilft ein kleiner Kondensator in der SCK-Leitung, dann kommt 
der Clock "leicht verzögert" am Mega8 an. Eine Hausnummer wie groß der 
sein soll, hab ich jetzt leider nicht im Kopf, lief bei mir immer ohne.
Richtiger COM-Port ausgewählt?

\0

Autor: Klaus De lisson (kolisson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo Christian W.,

hast du denn ein Oscilloscope zur Hand ?

gruss

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ad Schaltplan: Du Hast die ∗Bezeichnungen∗ von MOSI und MISO vertauscht, 
und zwar sowohl am Header als auch am µC, die ∗Verdrahtung∗ dagegen 
passt laut Plan. Überprüf nochmal, ob die auch in der Schaltung so 
stimmt.

Autor: Christian W. (christian_w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

danke für die schnellen Nachrichten.

Im PonyProg ist momentan der Siprog API gewählt, COM Schnittstelle 
stimmt auch. Ich hab auch schon andere Adapter im PonyProg getestet aber 
ohne Erfolg.

Ein Pullup-Widerstand am Reset-PIN ist nicht vorhanden, der PIN geht 
direkt an den Wannenstecker mit einem Draht.

Oszi hab ich keines...

Die MOSI MISO Belegungen stimmen auf der Platine 1:1.

Hab mal ein Digitalmultimeter angesteckt. Da ergibt sich folgendes:

- Platine ohne Stromversorgung und mit angesteckter serieller 
Schnittstelle: Reset PIN hat -0,35V

- Platine MIT Stromversorgung und mit angesteckter serieller 
Schnittstelle: Reset PIn hat + 4,73V

- Die 4,73 V ändern sich auch dann nicht, wenn ich versuche zu 
Programmieren oder etwas aus dem IC auszulesen.

Kann das tatsächlich sein, dass das Programmierinterface Schrott ist? 
Das hab ich mir fertig gekauft.

Kann ich während des Programmiervorgangs mit einer Krokoklemme den 
Reset-PIN auf Masse ziehen oder geht da was kaputt?

Danke

Christian

Autor: Klaus De lisson (kolisson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

> Kann ich während des Programmiervorgangs mit einer Krokoklemme den
> Reset-PIN auf Masse ziehen oder geht da was kaputt?

Das kannst du und es geht nix kaputt...  leider nützt es aber auch nix.
Der Reset geht beim Proggen ja nur kurz auf Low um den Vorgang 
einzuleiten.
Dauerreset verhindert also das proggen.

Das du an die Fuses nicht herankommst ist unter diesen Umständen auch 
klar.
.. eigentlich benötigt man diese in deinem Stadium auch ersteinmal 
nicht.

.. anderen Prozessor versucht (wegen der Pferde vor der Apotheke)

gruss K.

p.s.
am Anfang sind es oft Einstellungen bezüglich des Programmers .. 
respektive
der PC Hardware, die , falls falsch, Probleme machen.

zudem solltest Du in diesem Stadium eher versuchen die Fuses auszulesen 
als irgendwas zu proggen.

Autor: Christian W. (christian_w)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ok danke für die antworten.

ich werde bei der pc hardware ansetzen mit fehlersuchen, da mir der 
programmieradapter den ich verwende ziemlich komisch vorkommt. weil: im 
sub-d-steckergehäuse sitzt ein kleiner smd-ic, der da meiner meinung 
nach nicht hingehört und vielleicht den direkten datenaustausch zwischen 
pc und atmel verhindert. eigentlich müssten ja ein paar widerstände und 
ein transistor reichen?

kann ich diesen programmieradapter wie in der grafik angehängt 
verwenden? ich verwende PonyProg 2.07c Beta.

danke

christian

Autor: Gregor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ohne PulUp (10k gegen Vcc)auf dem RESET wird der Mega8 meines Wissens 
nicht laufen; und nicht programmierbar sein.

Gregor

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>ohne PulUp (10k gegen Vcc)auf dem RESET wird der Mega8 meines Wissens
>nicht laufen; und nicht programmierbar sein.

Das Reset-Pin hat einen internen Pull-Up.

MfG Spess

Autor: Christian W. (christian_w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

danke für die Nachricht.

Ich hab jetzt einen 10k Widerstand gegen VCC an Reset gehängt, zwar ist 
die Spannung am Reset PIN geringfügig auf 4,91 V gestiegen, aber auch 
beim Programmieren bleiben die 5 V und ändern sich nicht, auch nicht 
sehr kurz. (Wie lange wird der PIN auf Masse gezogen beim 
Programmiervorgang? Merkt man das mit einem Digitalmulti überhaupt?)

Fazit: Auch mit dem 10k Pullup lässt sich der Prozessor nicht 
programmieren. Als nächstes werd ich mal einen seriellen Adapter bauen 
und diesen dann statt des jetzigen Testen.

Christian

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gregor schrieb:
> Hallo,
>
> ohne PulUp (10k gegen Vcc)auf dem RESET wird der Mega8 meines Wissens
> nicht laufen; und nicht programmierbar sein.

Genauso ist es. Der Kollektor des Transistors ist bei dem Programmer an 
Reset beschaltet  - ohne Pull-up kann das gar nicht funktionieren.

Edit: Zu spät. :)

@Spess: Ist der interne Pull-Up am Reset-Port von Anfang an aktiv? Im 
Datenblatt (ATmega48) steht bei der Beschreibung des Reset-Pins nichts 
dazu:

"RESET, Reset pin: When the RSTDISBL Fuse is programmed, this pin 
functions as a normal I/O
pin, and the part will have to rely on Power-on Reset and Brown-out 
Reset as its reset sources.
When the RSTDISBL Fuse is unprogrammed, the reset circuitry is connected 
to the pin, and the
pin can not be used as an I/O pin.
If PC6 is used as a reset pin, DDC6, PORTC6 and PINC6 will all read 0.
PCINT14: Pin Change Interrupt source 14. The PC6 pin can serve as an 
external interrupt
source."

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich nehme alles zurück, im Datenblatt ist die RESET-Logik abgebildet und 
da befindet sich natürlich ein pull-up.

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch wenns öfters falsch beschrieben wird ändert sich doch nix daran: 
Der /RESET bleibt während des gesamten [1] (seriellen) 
Programmiervorgangs LOW [2]. D.h. man kann ihn durchaus per 
Krokoklemme/.. von Hand auf LOW ziehen.

Aaber: Das muss der Programmieradapter können. Wenn der das nicht 
schafft, dann ist irgendwo der Wurm drin. Entweder ein Kurzschluss am 
/RESET, ein defekter Programmieradapter, das Kabel ist falsch 
angeschlossen oder es hat keinen Durchgang.

Viel Erfolg!

[1] Ausnahme: Manch Software macht nach einem Chip-Erase nochmal einen 
'neuen' Reset.
[2] ..wo versteckt sich das Datenblatt zum m8? .. behelfsweise das vom 
m8A: http://atmel.com/dyn/resources/prod_documents/doc8159.pdf Kapitel 
24.8 'Serial downloading'.

Autor: Christian W. (christian_w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#include <avr/io.h> /* Standardregister */

// Hauptprogramm
int main(void)
{

  // Datenrichtung festlegen
  // DDRD = Gesamter B Port ist Ausgang
  DDRD = 0xff;

  // Alle LEDs an
  PORTD |= (1 << 0); /* PIN aktivieren */
  PORTD |= (1 << 1);
  PORTD |= (1 << 2);
  PORTD |= (1 << 3);
  PORTD |= (1 << 4);
  PORTD |= (1 << 5);
  PORTD |= (1 << 6);
  PORTD |= (1 << 7);

  return 0;
}

Christian

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>  DDRB = 0xff;

>  // Alle LEDs an
>  PORTC |= (1 << 0); /* PIN aktivieren */

Wenn du zu Ausgabe PortC nimmst, solltest du auch DDRC auf Ausgang 
setzen.

MfG Spess

Autor: Christian W. (christian_w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, sorry habs grade korrigiert...
geht aber immer noch nicht...

Kann das sein dass der gesamte HEX-Code im Speicherchip des 
Programmieradapters festhängt?

Ich hab mir grade den Originalen USB Programmieradapter bestellt, 
vielleicht klappts ja dann mit dem besser...?

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> return 0;

..die LED(s) dürfte(n) damit höchstens glimmen. Mach da mal noch eine 
Endlosschleife 'while(1);' davor..

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Kann das sein dass der gesamte HEX-Code im Speicherchip des
>Programmieradapters festhängt?

Was für ein Speicherchip? Da ist maximal ein Pegelwandler drin.

MfG Spess

Autor: Christian W. (christian_w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wow geil ich habs grade geschafft.

Hab alle Programme geschlossen, alles abgesteckt, neu gestartet,

dann den Reset PIN auf Masse gelegt

dann programmiert

dann den Reset-Masse-PIN wieder von Masse genommen

Alle LEDs leuchten!

Wie geil


Vielen Dank euch allen für die schnelle Hilfe :-)

Viele Grüße

Christian

Autor: Gregor R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian W. schrieb:
> Wow geil ich habs grade geschafft.
>
> Hab alle Programme geschlossen, alles abgesteckt, neu gestartet,
>
> dann den Reset PIN auf Masse gelegt
>
> dann programmiert
>
> dann den Reset-Masse-PIN wieder von Masse genommen
>
> Alle LEDs leuchten!

Gratuliere.

Nun wissen wir, dass der Programmieradapter prinzipell funktioniert. 
Außer, dass der Reset Pin während des Programmierens nicht auf Low 
gezogen wird.

* Suche nochmal nach Unterbrechungen der Resetleitung vom Programmer zum 
AVR.
* Kurzschlüsse kann man ausschließen, denn sonst hätte dein manuelles 
auf Low ziehen nicht funktioniert (kurzschluss mit 5V) und andererseits 
hättest du nicht 4,9V im Betrieb messen können (bei Kurzschluss mit 
GND).

* Was du noch versuchen könntest ist einen 100nF Kondensator zwischen 
Reset und GND anzuschließen. Den verwende ich jedenfalls in allen meinen 
Schaltungen grundsätzlich, und man sollte es prizipell auch so machen.

MfG Gregor

Autor: Christian W. (christian_w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok werd ich machen...

was mich noch interessiert ist, warum manchmal meine leds angehen, und 
manchmal nicht?

teilweise ist es so, dass alle leds bis auf eine brennen.

ist mein 22k basiswiderstand am transistor vielleicht zu groß?
welchen widerstand kann man hier empfehlen?

danke

christian

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian W. schrieb:

> ist mein 22k basiswiderstand am transistor vielleicht zu groß?
> welchen widerstand kann man hier empfehlen?

Mit 10k wirst Du nicht viel falsch machen. 22k sind tatsächlich etwas 
groß.

Autor: Gregor R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian W. schrieb:
> was mich noch interessiert ist, warum manchmal meine leds angehen, und
> manchmal nicht?

Das mit dem Basiswiderstand kann schon stimmen. Was ich jedoch vermute 
ist, dass der AVR einfach keinen gründlichen Reset bekommt. Fürs 
Programmieren dürfte es ja mit nur einem Widerstand am Reset 
funktionieren. Für den Normalbetrieb würde ich dir jedoch sehr raten 
eine Serienschaltung aus 10k Pullup gegen Versorgungsspannung und einem 
100nF Kondensator gegen Masse zu verwenden. Der Kondensator hält den AVR 
nach dem Einschalten so lange im Reset- Zustand bis sich alle Spannungen 
stabilisiert haben. Das kann sich je nach dem welche Spannungsversorgung 
du verwendest einige ms Dauern. Wenn die Spannungsversorgung nicht sehr 
Spannungssteif ist erzeugt das Einschalten einen Spannungseinbruch. Wenn 
der AVR aber schon vom ersten Moment an anfängt sein Programm 
abzuarbeiten, wenn aber noch keine stabilen Spannungsverhältnisse 
vorherrschen kann es auch zu unerklärlichen Fehlfunktionen kommen. Zumal 
hast du auch an den Versorgungspins auf jegliche Pufferkondensatoren 
(100nF) verzichtet, was man sowieso nicht sollte.

MfG Gregor

Autor: Christian W. (christian_w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich hab jetzt mal alle Basiswiderstände durch 8k6 ersetzt und außerdem 
an der +5V Leitung direkt am IC Sockel einen 0,1uF Elko angebracht... Es 
ändert sich aber leider nichts an der Situation dass einige LEDs dunkel 
bleiben.

Was mir auffällt: Ich habe ein Programm geschrieben, dass alle LEDs 
nacheinander aufleuchten lässt. LED Nr. 6 an Ausgang PD5 geht zwar an, 
erlischt aber in dem Moment wenn die nächste LED Nr. 7 angeht. Sowas hab 
ich aber nicht programmiert. Sehr komisch... LED1 geht überhaupt nicht 
an, lässt sich aber einschalten, wenn man mit einer Hilfsspannung an der 
Basis den Transistor mit der Hand durchschaltet.

Kann mir jemand sagen, wie ich über die Fuse-Bits den 4 MHz Oszillator 
aktiviere? Momentan rennt der IC noch mit 1 MHz. Vielleicht liegts ja 
daran, dass der externe Quarz "reinpfuscht"...

Danke

Christian

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ad Programm: herzeigen (komplett).

Ad Quarz: Nein, der pfuscht Dir nicht rein, weil der nicht mal getrieben 
wird :-)

Ad Fuses: Zuallerserst(!) ins Datenblatt schauen, was ∗genau∗ Du willst, 
dann zusammenstöpseln, wie die Fuses wohl aussehen müssen, nochmals auf 
Plausibilität prüfen, ggf. mit [1] abgleichen, dann Programmieren :-)

Es gibt auch Rechner, die behilflich sind, z.B. [2], aber unter keinen 
Umständen blind nutzen ohne vorher das Datenblatt gelesen zu haben - da 
sperrt man sich nämlich ganz leicht selbst aus.

HTH

[1] http://www.mikrocontroller.net/articles/AVR_Fuses
[2] http://www.engbedded.com/fusecalc/

Autor: Christian W. (christian_w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier wäre mal mein C-Code

// 8-Kanal-Lauflicht

#include <avr/io.h> 
#define F_CPU 1000000UL // Takt
#include <util/delay.h> 

int main(void) 
{ 
  // als Ausgang festlegen
    DDRD = 0xff; 

  // Warten vor dem Start
  _delay_ms(1000);

  // Pause zwischen den LEDs
  int zeit = 100;

  // Alles nacheinander einschalten
    PORTD |= (1 << PD1); _delay_ms(zeit);
    PORTD |= (1 << PD2); _delay_ms(zeit);
    PORTD |= (1 << PD3); _delay_ms(zeit);
    PORTD |= (1 << PD4); _delay_ms(zeit);
    PORTD |= (1 << PD5); _delay_ms(zeit);
    PORTD |= (1 << PD6); _delay_ms(zeit);
    PORTD |= (1 << PD7); _delay_ms(zeit);  
  
  // Warten
  _delay_ms(1000);

  // Alles ausschalten 
  PORTD &= ~(1 << PD1); 
    PORTD &= ~(1 << PD2); 
    PORTD &= ~(1 << PD3); 
    PORTD &= ~(1 << PD4);  
    PORTD &= ~(1 << PD5); 
    PORTD &= ~(1 << PD6);  
    PORTD &= ~(1 << PD7); 

    // Warten
  _delay_ms(500);

  // Pause zwischen den LEDs 
  int pause = 100;

    // Programmschleife
    while(1) 
      { 

        PORTD |= (1 << PD0); //  aktivieren 
            _delay_ms(pause); 
            PORTD &= ~(1 << PD0); //  deaktivieren 

            PORTD |= (1 << PD1); //  aktivieren 
            _delay_ms(pause); 
            PORTD &= ~(1 << PD1); //  deaktivieren 
    
            PORTD |= (1 << PD2); //  aktivieren 
            _delay_ms(pause); 
            PORTD &= ~(1 << PD2); //  deaktivieren 

            PORTD |= (1 << PD3); //  aktivieren 
            _delay_ms(pause); 
            PORTD &= ~(1 << PD3); //  deaktivieren 

            PORTD |= (1 << PD4); //  aktivieren 
            _delay_ms(pause); 
            PORTD &= ~(1 << PD4); //  deaktivieren 

            PORTD |= (1 << PD5); //  aktivieren 
            _delay_ms(pause); 
            PORTD &= ~(1 << PD5); //  deaktivieren 

            PORTD |= (1 << PD6); //  aktivieren 
            _delay_ms(pause); 
            PORTD &= ~(1 << PD6); //  deaktivieren 

            PORTD |= (1 << PD7); //  aktivieren 
            _delay_ms(pause); 
            PORTD &= ~(1 << PD7); //  deaktivieren 

            PORTD |= (1 << PD6); //  aktivieren 
            _delay_ms(pause); 
            PORTD &= ~(1 << PD6); //  deaktivieren 

            PORTD |= (1 << PD5); //  aktivieren 
            _delay_ms(pause); 
            PORTD &= ~(1 << PD5); //  deaktivieren 

            PORTD |= (1 << PD4); //  aktivieren 
            _delay_ms(pause); 
            PORTD &= ~(1 << PD4); //  deaktivieren 

            PORTD |= (1 << PD3); //  aktivieren 
            _delay_ms(pause); 
            PORTD &= ~(1 << PD3); //  deaktivieren 

            PORTD |= (1 << PD2); //  aktivieren 
            _delay_ms(pause); 
            PORTD &= ~(1 << PD2); //  deaktivieren 

            PORTD |= (1 << PD1); //  aktivieren 
            _delay_ms(pause); 
            PORTD &= ~(1 << PD1); //  deaktivieren 
              
    } // Ende while

    return 0;

} // Ende main

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So auf die Schnelle:

Alles aus- bzw. einschalten könntest Du natürlich auch einfacher mittels
//aus
PORTD = 0x00;
//ein
PORTD = 0xff;

Die Delay-Funktionen erwarten ein Double als Argument (wenn ich mich 
recht erinnere).
Hast Du beim Kompilieren eine Optimierungsstufe eingestellt?

In der while-Schleife gehen natürlich die jeweiligen LEDs aus, wenn Du 
die nächste einschaltest.

Wie sind die LEDs verschaltet? Kann man an Deinem Schaltplan oben ja 
nicht sehen.

Autor: Christian W. (christian_w)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, das Wort Optimierungsstufe glaub ich klingt schon mal sehr gut 
für mein Problem, ich weiß aber nicht was da eingestellt ist, ich hab 
alles auf den Einstellungen wie bei der Programm-Installation belassen. 
Kann man auch ohne Optimierung den Code Hexen? Würd ich nämlich gerne 
mal testen und sehen was dabei rauskommt.

Das was konkret nicht passt, ist folgendes:

Ich programmiere:
// Alles nacheinander einschalten
    PORTD |= (1 << PD1); _delay_ms(zeit);
    PORTD |= (1 << PD2); _delay_ms(zeit);
    PORTD |= (1 << PD3); _delay_ms(zeit);
    PORTD |= (1 << PD4); _delay_ms(zeit);
    PORTD |= (1 << PD5); _delay_ms(zeit);
    PORTD |= (1 << PD6); _delay_ms(zeit);
    PORTD |= (1 << PD7); _delay_ms(zeit);  

Und der Controller macht das hier mit den 8 LEDs:

AUS-EIN-EIN-EIN-EIN-AUS-EIN-EIN

Wie gesagt, wenn die while-Schleife durchläuft, funktionieren alle 8 
LEDs ohne Probleme.

Anbei noch eine Grafik, wie meine LEDs am Controller hängen.

Christian

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian W. schrieb:
> Und der Controller macht das hier mit den 8 LEDs:
>
> AUS-EIN-EIN-EIN-EIN-AUS-EIN-EIN
>
> Wie gesagt, wenn die while-Schleife durchläuft, funktionieren alle 8
> LEDs ohne Probleme.

PD0 programmierst Du ja nicht, insofern ist das erste AUS erklärbar. Das 
andere ist durch den Code nicht wirklich erklärbar, prüfe daher nochmal 
die Verschaltung an dem Pin.

Die Optimierungsstufe des Compilers schaltet man in den 
Compiler-Optionen ein (ergibt dann beim Aufruf des gcc -O0, -O1, -O2 
oder -O3). Ohne Optimierung kann der Compiler die Delay-Zyklen nicht 
bestimmen.

Autor: Christian W. (christian_w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aha, das bei PD0 sieht mir nach Leichtsinnsfehler aus... Sch**ße...

Das mit der Optimierung werd ich mal testen.

Danke

Christian

Autor: Christian W. (christian_w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

hab alles im Griff. Die Led Nr. 6 leuchtete deswegen nicht mehr wenn Nr. 
7 anging, weil hinten auf der Platine ein Lötfehler war. Von der einen 
Led war der Plus mit dem Minus der benachbarten Led verbunden. Das 
erklärt auch, warum Led Nr. 6 zwar alleine leuchtete, aber dann ausging, 
wenn alle anderen auch leuchteten, am Minuspol war plötzlich 
Plus-Potential und durch die Led floss kein Strom mehr.

Von der Programmierung her klappt jetzt alles einwandfrei. Hab heute den 
originalen AVR USB Programmieradapter bekommen. Der billige serielle 
Adapter den ich zu erst verwendet habe ist nicht zu gebrauchen. Da muss 
man immer per Hand den Reset Pin auf Null ziehen, das ist Sch**ße...

Vielen Dank für alle Tipps. War sehr hilfreich.

Viele Grüße

Christian

Autor: anvilex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

Bei seriellem Programmieradapter wird Reset-Pin mit Hilfe einer 
Transistor zu GND gezogen. d.H. auf dem Traget sollte ein Pull-up 
Widerstand vorhanden sein. Die grösse sollte im Bereich 3k3..10k liegen. 
Falls Target ist so konzipiert, dass nach dem Programmieren RESET-Pin 
als Ausgang verwendet wird - ein serieller Widerstand zwischen 
ISP-Stecker und Reset-Pin ist ein pflicht. Sonst wird Transistor beim 
Programmieradapter zerstört (Gleiches passiert, wenn Reset-Pin extern zu 
VCC Verbunden ist/wird).

MfG Konstantin

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.