Atmega8: I/O funktioniert nicht vollständig

[tristate (Gast)]

Hallo µC-Gemeinde.

Ich beschäftige mich erst seit Weihnachten mit der µC-Programmierung. 
komme mit der wenigen Zeit die ich habe ganz gut voran, doch nun ists 
Zeit für meinen ersten Beitrag.

Habe jetzt meine erste eigene Schaltung fertig, doch leider macht der 
Atmega8 nicht das was er soll.

An PortD sind 8 Taster und an PortB sind 8 LEDs.
zum Testen habe ich folgendes kleines Programm:

#include <avr/io.h>
#include <inttypes.h>

int main(void)
{
  DDRD = 0b00000000;
  DDRB = 0b11111111;

    while(1)
    {
  uint8_t temp = PIND;
  PORTB = temp;
    }
}

Problem: es leuchten bei Knopfdruck nur die LEDs an PB0, 6 und 7 (Quarz 
ist intern)

Bisherige Erkenntnis: Die Schaltung funktioniert einwandfrei, wenn ich 
ohne µC die entsprechenden Stellen brücke (z.B. von PD3 auf PB3 im 
Sockel), dann leuchten alle LEDs.
Habe 2 verschiedene Atmega8 ausprobiert => beide bringen das gleiche 
Resultat.

Im Forum und auch bei Google ließe sich leider nichts finden, denn dort 
Fragen alle nur nach PB6 und PB7 (Quarz extern auf intern, aber das geht 
ja)

Fuses gibts im Anhang

Hoffe ihr habt einen hilfreichen Tipp für mich.

mfg

Peter

[Der Weise (Gast)]

Hast du vielleicht an die Pins vom PortB noch den Programmer 
angeschlossen?

[Zero V. (Firma: Freelancer) (gnd)]

#include <inttypes.h> ?
Habe ich noch nie explizit eingebunden.

Aber hat deine Schaltung ext. PullUps oder Pulldowns ???

[Krapao (Gast)]

> PortD sind 8 Taster

Nur die Taster oder auch externe Pull-up (wenn die Taster zu GND 
schalten) oder Pull-down Widerstände (wenn die Taster zu Vcc schalten) 
so wie im AVR-GCC-Tutorial beschrieben? Interne Pull-Up Widerstände 
benutzt du ja keine, wie im Code zu sehen ist.

Hast du an den PB-Pins noch etwas anderes als die LEDs (und ihre 
Vorwiderstände) angeschlossen? Vielleicht den ISP-Programmieradapter 
oder einen USB-to-TTL Chip wie auf den Arduinoboards?

Es wäre sicher nicht verkehrt, wenn man deine Schaltung mal sehen 
könnte.

[tristate (Gast)]

oh, das geht ja sehr schnell hier, danke :)
darauf war ich nicht eingestellt.

Im Anhang meine Schaltung

[tristate (Gast)]

entschudligt den doppelpost!

sonst hängt nichts weiter dran, programmiert wird auf einem anderen 
gerät.

[holger (Gast)]

AREF an GND ist ja wohl ein absolutes NO GO;)

[tristate (Gast)]

wo gehört denn sonst der aref hin?
ich habs in beispielen im internet bisher nur so gefunden

[spess53 (Gast)]

Hi

>ich habs in beispielen im internet bisher nur so gefunden

Aber nur über einen Kondensator.

MfG Spess

[g457 (Gast)]

> ich habs in beispielen im internet bisher nur so gefunden

∗hust∗ die einzige verlässliche Quelle anzapfen: den Hersteller. Im 
Speziellen: dessen Dokumentation in Form des Datenplatts.

AREF auf GND gibt einen hüpschen Kurzschluss sobald man AVcc oder Vref 
aktiviert.

[Icke ®. (49636b65)]

Es wäre auch günstiger, die Taster nach Masse schalten zu lassen, statt 
nach VCC. Solltest du nämlich versehentlich die Pins als Ausgang 
konfigurieren, dann macht es leise pfff...

[tristate (Gast)]

reicht abklemmen von AREF denn?
oder wohin soll der?

und löst das das problem mit den 5 fehlenden LEDs?

[tristate (Gast)]

@icke: guter tipp, merk ich mir für die nächste platine :)

[Krapao (Gast)]

Jetzt mit dem Schaltplan bin ich ratlos, besonders zusammen mit diesem 
Statement

> Bisherige Erkenntnis: Die Schaltung funktioniert einwandfrei, wenn ich
> ohne µC die entsprechenden Stellen brücke (z.B. von PD3 auf PB3 im
> Sockel), dann leuchten alle LEDs.

Wenn die LED beim Drücken von SW5 und Drahtbrücke zwischen PD3 und PB3 
funktioniert, sehe ich kein Hindernis, warum es das Programm oben nicht 
auch tun soll.

Als nächster Schritt würde ich prüfen, was aus dem C-Code kompiliert und 
als Arbeitsanweisung in den Atmega8 geschrieben wurde. Vielleicht hat 
sich auf diesem Zwischenstück ein Bug eingeschlichen.

Zum Kontrollieren kann man den Flashinhalt auslesen und die dabei 
entstehende HEX-Datei disassemblieren. Wenn du nicht selbst 
disassemblieren kannst, hänge die ausgelesene HEX-Datei in den Anhang.

[tristate (Gast)]

so... und hier die hex-files kompiliert und ausgelesen.
sind identisch :(

[Krapao (Gast)]

Das disassemblierte Programm macht im Simulator was der C-Code 
vorschreibt. Ein Rätsel!

Jetzt kannst du prüfen, ob Eingangsstufen an PIND oder Ausgangsstufen an 
PORTB zerschossen sind.

Dazu das Programm so schreiben, dass die funktionierenden Eingabepins 
(0,6,7) andere Ausgabepins (1,2,3 oder 3,4,5) aktivieren können.

Und umgekehrt, ob die nicht funktionierende Eingabepins (1,2,3 oder 
3,4,5) funktionierende Ausgabepins (0,6,7) aktivieren können.

Die Ausgabepins kannst du auch leichter prüfen, wenn du mal ein 
Lauflicht drüber laufen lässt (dann aber mit eingeschalteter Optimierung 
kompilieren)

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

int main(void)
{
  uint8_t bit = 0;

  DDRD = 0b00000000;
  DDRB = 0b11111111;

  while(1)
  {
    PORTB = (1<<bit);
    bit += 1;
    bit %= 8;
    delay_ms(250);
  }
}

[tristate (Gast)]

vielen Dank schon mal für deine Mühe, ein ergebnis gibt dann aber jedoch 
leider erst morgen.

arbeit ruft in 7 stunden schon wieder :-D, danach werd ich es sofort 
ausprobieren

[tristate (Gast)]

soo... zurück von der arbeit und gleich ans werk gegangen

ich hab das mal alles so durchgetestet.
die eingänge funktionieren alle, nur die ausgänge nicht
werden wohl defekt sein :'(

aber warum denn dann an zwei controllern genau die selben Pinne?
hoffe mal dass das Evaluationboard keinen knacks hat und mir die µCs 
schrottet

[tristate (Gast)]

so.. nach langer zeit mal ein update.

auf den beiden genannten µCs geht der selbe Code bei gleicher Platine 
nun, was da schiefgelaufen ist vorher weiß ich leider nicht.

trotzdem vielen dank an alle beteiligten