Ports am ATmega 16

Gast #512339
Lesenswert?

Hallo

Ich hab da ein gewisses Problem:

Wenn ich bei DDRx einen output definiere, dann leuchtet die LED gleich, 
obwohl
PORTx =0 ist.

PORTA spinnt bei mir, weil wenn ich einen PAx definiere, leuchtet immer 
die darunterliegende Led.

PORTC tut nix und PORTD auch nichts.

Mfg. D.M
Gast #512419
Lesenswert?

DerPullup im Kontroller läst sich ein und ausschalten.
Den braucht man nur um einen externen zu sparen
bei Abfrage wenn ein Taster am Port ist.

mit:

DDRx  = 0 Port auf eingang
PORTx = 1 Pull up aktiv

Widerstandswert eines aktiven Pull Up's ca. 50-100KOhm

DDRx  = 1 Port auf ausgang
PORTx = 0 LED ist ein
PORTx = 1 LED ist aus
Gast #512451
Lesenswert?

> #include <io.h>

Müßte (zumindest bei avr-gcc und avr-libc) eigentlich eher heißen:

#include <avr/io.h>

Der Rest sieht soweit ok aus. Port B1 wird also als Ausgang definiert, 
und der Wert ist 0. So sollte die LED dann leuchten.
Wenn die auch leuchtet, wenn du PORTB = 0xff machst, ist was faul. Hast 
du den richtigen Controller ausgewählt?
Gast #512487
Lesenswert?

Blöde Tippfehler.....

Jetzt richtig!!!

#include <avr/io.h>

int main (void)
{

  PORTB = 0xFF

  DDRB  = 0xFC // Hatte die "0" vergessen

   while(1)
   {

     /* "leere" Schleife*/;

   }

}

Gib das mal ein.
Danach müssten LED 0 und LED 1 leuchten.
Der Rest ist aus.
Gast #512493
Lesenswert?

Da stimmt grundsätzlich was nicht.

Zieh den Atmel aus der Fassung vorher Board ausschalten.
Flachbandkabel abziehen.
Board wieder einschalten.

Jetzt verbinde nacheinander LED0 Pin am LED Sockel bis LED7 Pin mit 
Masse.
Jedesmal muß eine LED leuchten solange der Pin mit Masse verbunden ist.
#512503
Lesenswert?

Wenn der Controller hoch fährt und werden alle Port standardmässig als 
Input initialisiert, also, wenn dann der PORTB gesetzt wird, dann wird 
damit der Pullup eingeschaltet und wenn danach der Port als Ausgang 
geschaltet wird, dann macht das ganze KEINEN Sinn...

Erst DDRx setzten und dann PORTx!

Also: (<ich> hat die Strichpunkte vergessen)

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

int main (void)
{
  uint16_t i, j;
  DDRB  = (1 << PB0); // PB0 als Ausgang

  PORTB = 0x00;  // Alle Ausgänge von PORTB auf low

  for (;;)
  {
    PORTB ^= (1 << PB0); // Toggle PB0

    // Hier warten
    for (i = 0; i < 65535; i++)
      for (j = 0; j < 5; j++);
  }

  return 1;
}

Daniel:

Zum testen nimm' doch eine Steckbrücke und teste mal eine LED durch. 
Steck das Kabel an LED0 und halte das andere Ende mal an GND und VTG. 
Bei GND sollte die LED leuchten und bei VTG aus sein.

Dann steck das Ende dieser Steckbrücke auf den Ausgang B0 und 
programmier' Deinen Chip mit obigem Code .... dann sollte die LED0 
abhängig von Deiner eingestellten Taktfrequenz blinken.
Gast #512510
Lesenswert?

Ja Ja die Strichpunkte vergesse ich meistens, aber mein Studio
wacht darüber.

Wenn mann die Ports zuerst setzt und dann das DDRx wird der Portpin
beim einschalten sofort auf 1 gesetzt und nicht erst ein kurzer
low Impuls ausgegeben.

Mansche Schaltungen reagieren sonst recht lustig.
Gast #512517
Lesenswert?

@ich: Du schreibst doch selbst, daß man eine 1 schreiben muß, damit die 
LED aus ist, und eine 0, damit sie an ist. Das DDR-Bit muß natürlich 
dann auf 1 stehen.

>   PORTB = 0xFF
>
>   DDRB  = 0xFC // Hatte die "0" vergessen

So sind Port B0 und B1 als Eingang mit aktivem Pull-Up konfiguriert. Die 
LEDs dürften so also nicht leuchten - tun sie auch nicht.

Die restlichen Pins sind als Ausgang auf high eingestellt. Die LEDs 
sollten also ebenfalls aus sein. Sie leuchten, aber nur "schwach".

Klingt jedenfalls nicht so falsch, wie du behauptest.
Gast #512530
Lesenswert?

So jetzt

#include <avr/io.h>

int main (void)
{

  PORTB = 0xFC; //0b00000011 Bitmuster ausgeben
  DDRB  = 0xFF; //PortB auf ausgang schalten

   while(1)
   {

     /* "leere" Schleife*/;

   }

}

Das kommt davon wenn mann 3 Sachen auf einmal machen will.
Ein Teil bleibt dann auf der Strecke.
Oder auch alle.

Asche auf mein Haupt ;-(
#512645
Lesenswert?

Könnte es sein, dass du den Watchdog eingeschaltet hast (Fuse)? Dann 
wird der Controller in einem bestimmten Intervall zurückgesetzt, wobei 
die LEDs nach einem Reset immer ausgeschaltet werden -> schwaches 
glimmen.

Nachmessen mit einem Oszi hilft auch. Oder halt wirklich mal prüfen, ob 
das STK500 und der Controller noch heile sind.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren