ATmega 328PB Blinklicht

Schaue dir mal die Zuweisungen ans DDRB-Register an. Wird da nicht was 
überschrieben?

Led4 kaputt, falsch rum eingelötet, falsches Programm geflasht, was auch 
immer.

Oliver

Oliver S. schrieb:
> Led4 kaputt, falsch rum eingelötet, falsches Programm geflasht,
> was auch
> immer.
>
> Oliver

Nein. dass kann nicht sein. Ich benutze ein Simulationsprogramm!

DDRB = (1 << PB4) | (1 << PB5);

Matthias L. schrieb:
> DDRB=(1<<PB4);  //LED4 als Ausgang definiert
>   DDRB=(1<<PB5); //LED3 als Ausgang definiert
>
> Im Ergebnis ist nur PB5 auf Ausgang gesetzt. Und deshalb funktioniert
> nur die daran angeschlossene LED.
>
> So ists korrekt:  DDRB |= (1<<PB4);  //LED4 als Ausgang definiert
>   DDRB |= (1<<PB5); //LED3 als Ausgang definiert

Das ist auf jeden Fall schon mal ein Fehler! Danke!!
Leider leuchtet immer noch nur LED3! Ich kann es mir nicht erklären.
Auch wenn ich die delay- Zeit erhöhe, blinkt die LED3 unverändert 
weiter.
Habe ich im Programm sonst alles richtig?

Matthias L. schrieb:
> Mans A. schrieb:
>> Habe ich im Programm sonst alles richtig?
>
> Dann zeige das angepasste Programm doch nochmal

1

#define F_CPU 16000000UL

2

#include <avr/io.h>

3

#include <util/delay.h>

4

5

6

int main(void)

7

{

8

9

  DDRB|=(1<<PB4);  //LED4 als Ausgang definiert

10

  DDRB|=(1<<PB5); //LED3 als Ausgang definiert

11

12

13

    while (1) 

14

    {

15

    PORTB|=(1<<PB4);//LED4 an

16

17

    _delay_ms(250.0);

18

19

    PORTB &= ~(1<<PB4);//LED4 aus

20

21

    PORTB|=(1<<PB5);//LED3 an

22

23

    _delay_ms(250.0);

24

25

    PORTB &= ~(1<<PB5);//LED3 aus

26

27

28

    }

29

  return 0;

30

}

Mans A. schrieb:
> Habe ich im Programm sonst alles richtig?

LED "verpolt" ?

Warum schreibst Du "_delay_ms(250.0);" und nicht einfach 
"_delay_ms(250);" ?

Mans A. schrieb:
> Nein. dass kann nicht sein. Ich benutze ein Simulationsprogramm!

Zu spät gesehen - da kannst Du lange warten, bis die delays abgearbeitet 
worden sind. Stelle (für die Simulation) mal 1 ms ein und freue Dich, 
was passiert :-)

Wolfgang schrieb:
> Geht sie auch wieder aus?

Ja.

Mans A. schrieb:
> Auch wenn ich die delay- Zeit erhöhe, blinkt die LED3 unverändert
> weiter.

Damit hast Du hier vermutlich nicht nur mich in die Irre geführt. LED3 
"blinkt" nicht - sie ist (längere Zeit - im Simulator) unverändert "an".

Für den Simulator setze ich delays - wenn ich sie denn verwende - immer 
auf ein Minimum. Du kannst die angegebene Wartezeit für den Simulator 
locker * 1000 nehmen ... (bei mir zumindest), da es einiges an Code "zu 
simulieren" gilt.

HildeK schrieb:
> Wenn es in deinem Simulator nicht so funktioniert, dann machst du bei
> dessen Bedienung etwas falsch.

Nein - nicht bei der Bedienung (es sei Denn, Du meinst dass "nicht ca. 5 
Minuten auf ein _delay_ms(250) warten zu wollen/können" falsche 
Bedienung ist :-) )

HildeK schrieb:
> Bei mir funktioniert auch das Durchsteppen im Simulator problemlos. Da
> muss man keine 5 Minuten warten ...

Ja.

Da habe ich zu hoch geschätzt (aus der kurzen Durchlaufzeit mit 
delay_ms(1)).

Im Microchip-Studio (WIN 10) sind es 1 Minute 42 Sekunden, im 
AtmelStudio 6.2 (XP) in einer virtuellen Maschine sind es knapp 54 
Sekunden (jeweils mit dem "originalen" _delay_ms(250.0); ).

Welchen Simulator (in welcher IDE) nutzt Du?

HildeK schrieb:
> Ich hatte ihn mit 1MHz übersetzt (und auf den Tiny26 gebrannt), damit
> wird es etwas schneller als in Echtzeit bei Autostep.

Klar - je nachdem, wie Du übersetzt (F_CPU bestimmt die delay-Cycles) 
geht es auch schneller. Aber so schnell wie in Deinem Video? Den Test 
(eine WIN 7 VM habe ich auch noch) mache (mit AS 4.18) ich noch (heute 
oder morgen) - ich melde mich ...

HildeK schrieb:
> Und meine Quadcore CPU hat auch schon einige Jahre auf dem Buckel:
> i7-4770 ...

Prozessor  Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz, 2668 MHz, 4 
Kern(e), 8 logische(r) Prozessor(en)

Ich bin gespannt auf 4.18 :-)

Kannst Du bitte Dein Projekt hier einhängen?