µC macht nicht was er soll

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.

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.

Klar, sorry

1

/*

2

 * Buzzer.c

3

 *

4

 * Created: 04.02.2014 16:55:53

5

 *  Author: Paul

6

 */ 

7

8

9

#define F_CPU 1000000UL

10

11

#include <avr/io.h>

12

#include <util/delay.h>

13

14

int main(void)

15

{

16

17

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

18

  PORTB |=  (1<<PB0) | (1<<PB1) | (1<<PB2) | (1<<PB3);  //Port B0-3 interner Pull-Up aktivieren

19

20

  DDRA &= ~(1<<PA0);  //Port A0 als Eingang definieren    //Port A0 als reset-Button

21

  PORTA |= (1<<PA0);  //Port A0 interner Pull-Up aktivieren

22

23

  DDRD |=  (1<<PD0) | (1<<PD1) | (1<<PD2) | (1<<PD3);  //Port D0-3 als Ausgang definieren

24

  PORTD &= ~((1<<PD0) | (1<<PD1) | (1<<PD2) | (1<<PD3));    //Port D0-3 Spannung 0  

25

26

  uint8_t bitChanged = 0;

27

28

  PORTD |= (1<<PD3) | (1<<PD2) | (1<<PD1) | (1<<PD0);

29

  _delay_ms(400);

30

  PORTD &= ~(1<<PD3);

31

  _delay_ms(400);

32

  PORTD &= ~(1<<PD2);

33

  PORTD |= (1<<PD3);

34

  _delay_ms(400);

35

  PORTD &= ~(1<<PD1);

36

  PORTD |= (1<<PD2);

37

  _delay_ms(400);

38

  PORTD &= ~(1<<PD0);

39

  PORTD |= (1<<PD1);

40

  _delay_ms(400);

41

  PORTD |= (1<<PD0);

42

  _delay_ms(400);

43

  PORTD &= ~((1<<PD3) | (1<<PD2) | (1<<PD1) | (1<<PD0));

44

45

    while(1)

46

    {

47

        //TODO:: Please write your application code 

48

49

    if(!(PINB & (1 << PINB0)))

50

    {

51

      PORTD |= (1<<PD3);

52

      bitChanged = 1;

53

    }

54

    else if(!(PINB & (1 << PINB1)))

55

    {

56

      PORTD |= (1<<PD2);

57

      bitChanged = 1;

58

    }

59

    else if(!(PINB & (1 << PINB2)))

60

    {

61

      PORTD |= (1<<PD1);

62

      bitChanged = 1;

63

    }

64

    else if(!(PINB & (1 << PINB3)))

65

    {

66

      PORTD |= (1<<PD0);

67

      bitChanged = 1;

68

    }

69

70

    while(bitChanged == 1)

71

    {

72

      if(!(PINA & (1<<PINA0)))

73

      {

74

        bitChanged = 0;

75

        PORTD &= ~((1<<PD3) | (1<<PD2) | (1<<PD1) | (1<<PD0));

76

77

        PORTD |= (1<<PD3);

78

        _delay_ms(400);

79

        PORTD |= (1<<PD2);

80

        _delay_ms(400);

81

        PORTD |= (1<<PD1);

82

        _delay_ms(400);

83

        PORTD |= (1<<PD0);

84

        _delay_ms(400);

85

86

        PORTD &= ~((1<<PD3) | (1<<PD2) | (1<<PD1) | (1<<PD0));

87

      }

88

    }

89

    }

90

}

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

Hallo,

Warum stehen dort

1

_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

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

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.

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.

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

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.

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

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

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

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

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