ATMega1284P LED geht nicht

Sorry mein Fehler:
In der Verzweiflung habe ich bereits beides ausprobiert. Also PA0 auf 
Masse gegen VCC und umgekehrt.

Ist ne 5V LED mit integriertem Vorwiderstand. Funktioniert an einem 
ATMega32 problemlos!

Daniel B. schrieb:
> 1.Nachdem Du auf das Quarz umgeschaltet hast in den Fuses,
> konntest Du
> dann noch erfolgreich programmieren?

Jup.

> 2.Falls ja, probiere folgendes Programm:
> #include <avr/io.h>
>
> int main(void)
> {
>   //PORTS
>   DDRA |= (1<<DDA0);
>   PORTA |= (1<<PORTA0);
>     while(1)
>     {
>
>     }
> }

Habe dafür die LED wieder gegen GND gedreht. Hat aber leider auch nicht 
funktioniert.

> 3. Falls es dann immernoch nicht funktioniert: Hardware checken.
> Insbesondere ob die LED richtig gepolt und angeschlossen ist, gegen
> Masse geschaltet ist und an sich funktioniert.

Wenn ich PA0 aktiv mit VCC verbinde, leuchtet sie. Beide GND sind an 
Masse angeschlossen, VCC, AREF und AVCC an 5V. 1k zwischen Reset und 
VCC, 22p zwischen GND und XTAL1 bzw. XTAL2. 1 16MHz Quarz zwischen XTAL1 
und XTAL2.

Julian schrieb:
> In der Verzweiflung habe ich bereits beides ausprobiert. Also PA0 auf
> Masse gegen VCC und umgekehrt.

Wildes Probieren ist in Sachen Elektronik oft ein schlechter Ratgeber. 
Es gib Bauelemente, die das gar nicht mögen.

Damit es nicht gar so schwierig wird, könntest du am Port ein 
Rechtecksignal ausgeben, z.B. indem du in deiner Hauptschleife den Pin 
abwechselnd auf 0 oder 1 schaltest - verziert mit ein paar 
delay()-Aufrufen. Und statt LED könntest du auch mal einen 
Spannungsmesser dran halten.

Aber vielleicht hast du deine Ports auch systematisch durch probieren 
gekillt :-(

Julian schrieb:
> Wenn ich PA0 aktiv mit VCC verbinde

und er eigendlich auf GND programmiert ist kannst Du schonmal ein neues 
IC bestellen.
Einen Port der auf Ausgang steht von Außen hart mit GND oder Vcc zu 
verbinden ist keine gute Idee. Die erlaubten 40mA sind da schneller 
überschritten als Du hinsehen kannst.

Thomas W. schrieb:
> Wildes Probieren ist in Sachen Elektronik oft ein schlechter Ratgeber.
> Es gib Bauelemente, die das gar nicht mögen.

Wildes Probieren lass ich mir nicht vorwerfen. Bei LED mit Vorwiderstand 
bei 5V ist simples kurzzeitiges umpolen kein Problem. Ich habe den IC zu 
Anfang, in meine mit einem ATMega32 funktionierende Platine, gesteckt 
und da hätte die LED direkt leuchten sollen, was sie auch nicht tat!

> Damit es nicht gar so schwierig wird, könntest du am Port ein
> Rechtecksignal ausgeben, z.B. indem du in deiner Hauptschleife den Pin
> abwechselnd auf 0 oder 1 schaltest - verziert mit ein paar
> delay()-Aufrufen. Und statt LED könntest du auch mal einen
> Spannungsmesser dran halten.

Braucht gar nicht so komplex. Eine Spannungsmessung (auch bei kompletten 
Port ein) hat erneut ergeben, dass überall ca. 0,2V anliegen. Auch an 
anderen Ports, die nicht beschaltet sind!

Guest schrieb:
> Julian schrieb:
>> Wenn ich PA0 aktiv mit VCC verbinde
>
> und er eigendlich auf GND programmiert ist kannst Du schonmal ein neues
> IC bestellen.
> Einen Port der auf Ausgang steht von Außen hart mit GND oder Vcc zu
> verbinden ist keine gute Idee. Die erlaubten 40mA sind da schneller
> überschritten als Du hinsehen kannst.

Prinzipiell korrekt. Praktisch sind die Pins im hochohmig und es fließt 
kein Strom. Wie gesagt, am Anfang in eine bereits funktionierende 
Schaltung eingebaut und kein Ergebnis. Hätte es daran gelegen, dass ich 
da VCC oder GND rangebe, hätte er zu Anfang funktionieren müssen ;)

Mal davon abgesehen, hast du prinzipiell recht, auch wenn man ein PORT 
m.E. so schnell nicht zerschießt. Strom aus dem Labornetzteil ist auf 
ca. 100mA begrenzt.

Daniel B. schrieb:
> Noch ein Versuch, was mir mal mit dem Atmel Studio passiert ist:
>
> Checke mal, ob Du überhaupt ein aktuelles Compilat programmierst.

Die Hex Datei ist korrekt ausgewählt und ist laut Windows im Moment vor 
der Programmierung aktualisiert worden. Habe die Datein auch mal 
gelöscht und neu kompiliert, leider kein Unterschied :/

Julian schrieb:
> Mal davon abgesehen, hast du prinzipiell recht, auch wenn man ein PORT
> m.E. so schnell nicht zerschießt.

Das stellt man oft erst später an unerklärlichem Verhalten fest. Solche 
Versuche sollte man nur mit einem Widerstand (hier wohl 330 Ohm) 
durchführen.

Julian schrieb:
> Strom aus dem Labornetzteil ist auf ca. 100mA begrenzt.
Und damit zweieinhalb Mal so hoch wie es ein Port nach Datenblatt 
maximal ab kann.

Du hast den Prozessortyp im Atmelstudio aber vor dem Compilieren 
angepasst?

Ich habe das Gefühl, dass der IC das Programm überhaupt gar nicht erst 
ausführt! Denn würde er den PORT auf Ausgang schalten, würden da keine 
wackligen 0,2V anliegen. Kann das sein, dass der Programmzeiger evtl. 
durch Fuses noch speziell gesetzt werden muss? Btw. JTAGGEN, Brown Out, 
CKDIV8 ist gesetzt.

Das wird nichts ändern, JTAG liegt auf PortC.

Ich bin mir nicht ganz sicher, reicht es, im "AVRISP mkII in ISP mode 
with ATmega1284P"-Fenster einfach den IC auszuwählen? Read-Signature 
meldet match.

Habe sicherheitshalber, nachdem es nicht funktioniert, ein neues Projekt 
erstellt und dort direkt den IC gewählt. Demenstprechend denke ich 
schon.

Julian schrieb:
> Ich bin mir nicht ganz sicher, reicht es, im "AVRISP mkII in ISP mode
> with ATmega1284P"-Fenster einfach den IC auszuwählen?

Nein, Du mußt in den Projekteigenschaften den richtigen Prozessor 
wählen, Du hast nur die Programmierfunktion angepasst.

ähh, AVcc hast Du aber auch angeschlossen oder?

Guest schrieb:
> Nein, Du mußt in den Projekteigenschaften den richtigen Prozessor
> wählen, Du hast nur die Programmierfunktion angepasst.

Danke!!! Das war der entscheidende Hinweis. Wieso auch immer stand er da 
auf ATMega128 -.-

Wozu muss ich denn zweimal angeben, was für ein IC ich nutze? Müssen die 
Optionen nicht zwangsweise immer gleich eingestellt sein?

Julian schrieb:

> Wozu muss ich denn zweimal angeben, was für ein IC ich nutze? Müssen die
> Optionen nicht zwangsweise immer gleich eingestellt sein?

Nein, die Flasherei ist weitestgehend unabhängig von der 
Programmerstellung. Du kannst z.B. problemlos Hex-Dateien flashen, von 
denen du nichtmal den Quelltext hast.

Zwar hat Atmel eine Möglichkeit vorgesehen, den Programmer entsprechend 
dem aktuellen Projekt einzustellen (das muß aber erstmal aktiviert 
werden und funktioniert auch eher schlecht bis garnicht), aber 
umgekehrt, daß also die Programmerstellung sich nach den Einstellungen 
des Programmers richtet, dafür gibt es keine Möglichkeit.

Und es widerspräche ja auch völlig der Kausalität. Zuerst schreibt man 
das Programm, dann wird geflasht. Also macht nur eine Parameterübergabe 
in Richtung der Flash-Mimik irgendeinen Sinn.