µC macht nicht was er soll

[Paul R. (pamel)]

Hi ihr alle,

ich bastel gerade an meinem ersten Projekt mit µC und mein Controller 
macht nicht ganz das was er soll.
Ich will mit Hilfe von 4 Tastern 4 LEDs zum Leuchten bringen. Sobald ein 
Taster geschlossen wird soll die jeweilige LED so lange leuchten, bis 
ein 5. Taster geschlossen wird. Die anderen Taster sollen solange 
ignoriert werden.
Das klappt eigentlich auch ganz gut.
Aber bei einem Taster passiert es immer wieder, dass zusätzlich zur 
richtigen auch eine zweite LED angeschalten wird, manchmal sogar nur die 
falsche LED. Die zweite LED ist aber immer die gleiche.
Kann das daran liegen, dass ich meinen µC zum Testen im Programmierboard 
lasse?
Im Code dürften eigentlich keine Fehler sein, dafür ist er zu einfach 
und der Fehler zu spontan unterschiedlich.
Fällt euch sonst noch was ein, woran das liegen könnte?

Danke für eure Hilfe

Gruß
Pamel

[D. V. (mazze69)]

Paul Rummel schrieb:
> Im Code dürften eigentlich keine Fehler sein, dafür ist er zu einfach
> und der Fehler zu spontan unterschiedlich.

Zeig mal den Code.

[Udo S. (urschmitt)]

Paul Rummel schrieb:
> Fällt euch sonst noch was ein, woran das liegen könnte?

Der Fehler findet sich meistens zwischen Bildschirm und Bürostuhl.
Selbst bei Profis.
Also häng dein Sourcecode hier an, und binde dich an deinen Stuhl um den 
Shitstorm zu überleben :-)
Egal, Anfänger dürfen Fehler machen, solange sie wenigstens die 
Grundlagen intus haben.

[Paul R. (pamel)]

Klar, sorry

/*
 * Buzzer.c
 *
 * Created: 04.02.2014 16:55:53
 *  Author: Paul
 */ 


#define F_CPU 1000000UL

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

int main(void)
{

  DDRB &= ~((1<<PB0) | (1<<PB1) | (1<<PB2) | (1<<PB3));  //Port B0-3 als Eingang definieren
  PORTB |=  (1<<PB0) | (1<<PB1) | (1<<PB2) | (1<<PB3);  //Port B0-3 interner Pull-Up aktivieren

  DDRA &= ~(1<<PA0);  //Port A0 als Eingang definieren    //Port A0 als reset-Button
  PORTA |= (1<<PA0);  //Port A0 interner Pull-Up aktivieren

  DDRD |=  (1<<PD0) | (1<<PD1) | (1<<PD2) | (1<<PD3);  //Port D0-3 als Ausgang definieren
  PORTD &= ~((1<<PD0) | (1<<PD1) | (1<<PD2) | (1<<PD3));    //Port D0-3 Spannung 0  
  
  uint8_t bitChanged = 0;
  
  PORTD |= (1<<PD3) | (1<<PD2) | (1<<PD1) | (1<<PD0);
  _delay_ms(400);
  PORTD &= ~(1<<PD3);
  _delay_ms(400);
  PORTD &= ~(1<<PD2);
  PORTD |= (1<<PD3);
  _delay_ms(400);
  PORTD &= ~(1<<PD1);
  PORTD |= (1<<PD2);
  _delay_ms(400);
  PORTD &= ~(1<<PD0);
  PORTD |= (1<<PD1);
  _delay_ms(400);
  PORTD |= (1<<PD0);
  _delay_ms(400);
  PORTD &= ~((1<<PD3) | (1<<PD2) | (1<<PD1) | (1<<PD0));

    while(1)
    {
        //TODO:: Please write your application code 
    
    if(!(PINB & (1 << PINB0)))
    {
      PORTD |= (1<<PD3);
      bitChanged = 1;
    }
    else if(!(PINB & (1 << PINB1)))
    {
      PORTD |= (1<<PD2);
      bitChanged = 1;
    }
    else if(!(PINB & (1 << PINB2)))
    {
      PORTD |= (1<<PD1);
      bitChanged = 1;
    }
    else if(!(PINB & (1 << PINB3)))
    {
      PORTD |= (1<<PD0);
      bitChanged = 1;
    }
    
    while(bitChanged == 1)
    {
      if(!(PINA & (1<<PINA0)))
      {
        bitChanged = 0;
        PORTD &= ~((1<<PD3) | (1<<PD2) | (1<<PD1) | (1<<PD0));
        
        PORTD |= (1<<PD3);
        _delay_ms(400);
        PORTD |= (1<<PD2);
        _delay_ms(400);
        PORTD |= (1<<PD1);
        _delay_ms(400);
        PORTD |= (1<<PD0);
        _delay_ms(400);
        
        PORTD &= ~((1<<PD3) | (1<<PD2) | (1<<PD1) | (1<<PD0));
      }
    }
    }
}

[stefan (Gast)]

Sichwort Pullup...

[Paul R. (pamel)]

muss ich die Pull-Ups für die Ausgänge extra ausschalten?
Wenn ja, wie?

[Uwe (de0508)]

Hallo,

Warum stehen dort

_delay_ms(400);

 ?

verwende doch bitte Macros, um die LEDs mit LED1 = 0 aus und LED1 = 1 
ein zu schalten, so liest das doch keiner und es schleichen sich Fehler 
ein.

siehe sbit.h von PeDa

[Paul R. (pamel)]

Ich hab den Code so formatiert wie ich andre Beispiele im Internet und 
auf der Seite hier gefunden hab.
Die _delay_ms(400); sorgen für ne Pause von 0,4 Sekunden

[Karl H. (kbuchegg)]

Der Code an sich, schaut in Ordnung aus (ohne ihn mal probiert zu 
haben).

Welcher AVR ist denn das? Und was hängt sonst noch am Port B?
Letzte Frage zielt darauf ab, warum du denkst, dass dein 
Programmierboard das Problem verursacht.

[Klaus I. (klauspi)]

Paul Rummel schrieb:
> muss ich die Pull-Ups für die Ausgänge extra ausschalten?
> Wenn ja, wie?

Wenn ich mich recht entsinne steht das sehr ausführlich auf Seite 73 des 
Datenblatts zu einem Mikrocontroller.

[Paul R. (pamel)]

ATtiny 2313
PortB soll im Betrieb ansonnsten leer sein.
Momentan hängen da noch die Verbindungen zum Programmieren drauf. Wie 
sie hier: 
http://www.produktinfo.conrad.com/datenblaetter/150000-174999/154658-an-01-en-ATAVRDRAGON.pdf 
auf Seite 32 beschrieben sind.
Ich weis halt nicht, ob da nach dem Programmieren noch Spannungen 
anliegen. Aber die Pins die ich verwende sind nicht nochmal belegt. Nur 
andere Pins des selben Ports

[Karl H. (kbuchegg)]

Laut Doku vom AVR Dragon sind die Pins tatsächlich nc, also 'not 
connected'.

Wie hast du deinen Hardware-Aufbau gemacht? Fliegende Verdrahtung? Gibt 
es eine Chance für einen ungewollten Kurzschluss zwischen 2 LED 
Leitungen?

Laut deinem Programm gibt es keine Möglichkeit, wie 2 LED je gemeinsam 
leuchten könnten. Durch die if-else_if Cascade ist das ausgeschlossen. 
Das müsste IMHO daher irgendein Hardware Problem sein.

[Paul R. (pamel)]

So weit ich das sehen kann nicht.
Ich hab hier mal zwei Fotos dran gehängt.

[Carsten S. (dg3ycs)]

Hi,

Paul Rummel schrieb:
> So weit ich das sehen kann nicht.
> Ich hab hier mal zwei Fotos dran gehängt.

Manchmal - zumindest wenn die Möglichkeit besteht - kann es nützlich 
sein den µC einfach mal aus der Fassung zu nehmen und an den 
ensprechenden Pins des Sockels mit einer Brücke direkt Ub einzuspeisen. 
(fliegende Verdrahtung, z.B. Messkabel mit zwei Spitzen... Oder einfach 
nur ein Stück draht)
Dann sieht man sofort ob der dort angeschlossene TEil der HArdware 
vernünftig funktioniert. (In deinem Fall ob die LED und wirklich nur die 
LED leuchtet)

Gruß
Carsten

[Paul R. (pamel)]

nein, daran lags nicht
Die physikalische Zuordnung zwischen µC und LEDs funktioniert.

[Paul R. (pamel)]

Könnte sich das bitte nochmal jemand anschaun. Ich weis nicht, was da 
noch falsch sein könnte. Funktioniern tuts aber immer noch nicht.

Danke schonmal

[Paul R. (pamel)]

hat sich erledigt, war scheinbar ein mechanisches Problem.
Hab die Platine grad sauber gemacht und jetzt geht alles.
Danke für euere Hilfe

Gruß
Pamel