Hallo,
Ich habe hier ein STK500 mit einem ATtiny13 und die ersten Versuche (LED
zwischen Port und GND) erfolgreich abgeschlossen.
Als nächstes habe ich zwei LEDs antiparallel mit einem gemeinsamen
150Ohm-Widerstand auf einem Steckbrett zusammengesteckt und mit den
Ports PB0 und PB1 des Erweiterungsanschlusses verbunden.
Nun habe ich folgendes Programm erstellt und erfolgreich in den tiny
geschrieben:
#define F_CPU 1200000
#include <avr/io.h>
#include <util/delay.h>
int main(void)
{
int dauer = 1000;
while(1)
{
// LED A on
DDRB = 0b00000001;
PORTB = 0b00000000;
_delay_ms(dauer);
// LED B on
DDRB = 0b00000010;
PORTB = 0b00000000;
_delay_ms(dauer);
}
}
Als "Belohnung" bekomme ich einen Wechselblinker im Sekundentakt.
Funktioniert prima. Wenn ich auf die gleiche Weise PB0 und PB2 oder auch
PB0 und PB3 probiere, klappt das ebenfalls. Wenn ich nun aber PB0 und
PB4 benutzen will, dann blinkt nur die LED an PB4, die andere LED bleibt
dunkel.
Meine Frage dazu: Ist dies nun ein spezielles Verhalten meines Boards
und/oder MCs oder kann jemand dieses Verhalten bestätigen ? Natürlich
interessiert mich, warum es zwischen diesen Ports nicht wechselblinkt?
Vielen Dank und viele Grüsse
Paul
BastelOpa schrieb:> DDRB = 0b00000001;> DDRB = 0b00000010;
Damit schaltet man die PINs zwischen Ausgang und Eingang "hin und her".
Normalerweise würde man die PINs einamlig zu Beginn (vor der while
Schleife) als Ausgang konfigurieren
1
DDRB = 0b00000011;
und dann den Ausgang (in der while Schleife) schalten
1
PORTB = 0b0000001;
2
...
3
PORTB = 0b0000010;
Ob das allerdings Dein Problem löst, weiß ich nicht.
Moin Achim,
deine Bemerkung ist völlig korrekt, hat aber nichts mit meiner Frage
(Warum verhält sich PB4 mit PB0 anders als bspw. PB2 mit PB0 ?) zu tun.
Viele Grüsse
Paul
Ich sehe keinen logischen Grund, warum sich PB4 abweichend verhalten
sollte, und kann die Ursache deshalb nur in irgendeinem ernsthaften
Hardwaredefekt vermuten: PB4 kaputt bei Deinem Controllerexemplar oder
die PB4-Route auf Deinem STK500? Fehler in der Verdrahtung? Das würde
ich alles mal akribisch durchprüfen.
Hi Spess,
der tiny steckt im Sockel 3400D1. Ich habe mit dem Durchgangsprüfer
kontrolliert, ob das dritte Beinchen (also PB4) mit dem
Erweiterungsanschuss PB4 verbunden ist. Das ist der Fall. Hast du
zufällig ein STK500 und einen tiny13 und könntest das Verhalten
nachvollziehen ?
Übrigens, ein einfacher Blinker mit PB4 und GND (beides über den
Erweiterungsanschluss mit der LED plus Widerstand auf dem Steckbrett
vebunden) funktioniert, also ist doch ein prinzipielles Kontaktproblem
auszuschließen, oder ?
Viele Grüsse
Paul
BastelOpa schrieb:> Moin Achim,> deine Bemerkung ist völlig korrekt, hat aber nichts mit meiner Frage> (Warum verhält sich PB4 mit PB0 anders als bspw. PB2 mit PB0 ?) zu tun.>> Viele Grüsse> Paul
Hallo Paul,
ich habe Deine Frage so verstanden, dass Du PB0 und PB4 jeweils einzeln
Blinken lassen kannst, nur nicht zusammen. Also kann Deine Hardware die
beiden LEDs richtig ansteuern und ist somit wohl eher nicht defekt. Mein
Gedanke war, dass dann Dein Code halt etwas "Merkwürdiges" macht. Daher
wollte ich einfach darauf Hinweisen, was Dein Code macht und wie ich
denke, dass man normalerweise LEDs blinken lässt.
Vielleicht hast Du ja Lust, das Programm mit PB0/4 auch zu posten, nicht
dass es nur ein Vertipper ist. Seine eigenen übersieht man ja leider
immer viel eher, als die anderer :-).
Ich selbst habe leider keinen ATTiny13 und kann es daher nicht selber
testen.
Gruß
Achim
Einen Tipp hätte ich noch. "Manchmal blinkt der Reset" :-).
Daher, ändere das Programm so, dass es zu Beginn 3x LED PB0 blinken
lässt und dann erst mit dem eigentlichen Wechselblinken beginnt.
Vielleicht sieht man ja dann, ob es unerwartet Resets gibt. Falls sich
zeigen sollte, dass es sich um Resetprobleme handelt, dann müsstest Du
die Reset/PB5 Beschaltung prüfen. Zumindest am PORTB Header liegend die
PB4 und 5 beieinander. Wer weiß ...
>Als "Belohnung" bekomme ich einen Wechselblinker im Sekundentakt.
Ja, aber unverdient.
Der Grund, warum Dein Programm seinen beabsichtigten Zweck erfüllt,
obwohl es das eigentlich gar nicht kann (*) ist ein durch die
STK500-interne ISP-Treiberstufe bedingter Seiteneffekt: Bei
aufgestecktem ISP-Kabel (hier zwischen den Plugs ISP6PIN und SPROG1)
sind zwei der Programmierpins über je einen 1k-Widerstand mit VCC
verbunden, und einer über einen 47k-Widerstand. Das geht aus dem
Schaltplan des STK500 hervor. Über diese Widerstände fließen die Ströme,
die Deine LEDs leuchten lassen. Zieh also mal das ISP-Kabel ab, damit
Dein Programm das tun kann, was sein Code vorschreibt, nämlich keine LED
an keinem Pin zum Leuchten bringen.
(*) Das kann es nicht, weil in jeder der beiden Blinkphasen einer der
Pins auf DDR=0 und PORT=0 gesetzt ist. Damit ist dieser Pin als Input
konfiguriert (genauer: Input OHNE aktivierten internen
Pullup-Widerstand), und in diesem Zustand kann dieser Pin weder Strom
sourcen noch sinken.
Wenn Du möchtest, dass Deine LEDs auch mit abgezogenem ISP-Kabel
blinken, dann machs richtig:
1
int main(void)
2
{
3
int dauer = 1000;
4
DDRB = 0b00000011; /* oder 0b00010001 */
5
while(1)
6
{
7
// LED A on
8
PORTB = 0b00000001;
9
_delay_ms(dauer);
10
11
// LED B on
12
PORTB = 0b00000010; /* oder 0b00010000 */
13
_delay_ms(dauer);
14
}
15
}
Hier sind die beiden LED-Pins immer Output, nur wechselseitig auf
L/H-Pegel. Wenn Du dieses Programm entsprechend der auskommentierten
Werte abänderst, funktioniert es anstandslos auch mit dem Pinpaar PB0
und PB4.
Moin zusammen,
erstmal die gute Nachricht, nun funktionierts :-)
Nachdem ich auf Anregung vom Achim nochmal alles abgebaut, neu
aufgebaut, neu nachgeschaut, nachgelesen und - ganz wichtig - den
programmierten tiny nach den Brennen raus aus dem STK und direkt auf das
Steckbrett gesetzt, funktionierte nach der Teillösung nun auch das
ursprüngliche Projekt ‚Lauflicht‘.
Jetzt in der Rückschau und dank dem ausgezeichneten Beitrag von
‚LostInMusic‘ klärt sich alles auf. Begonnen hatte es ja damit, dass ich
ein im Netz gefundenes Lauflicht einfach so nachbauen wollte. Aber es
funktioniert eben nicht, besser gesagt, es lief zwar ein ‚Lichtpunkt‘
durch die LEDs, aber es leuchteten immer noch ein oder mehrere LEDs
schwach mit. Im Text stand noch irgendwas von einem Tri-State bei den
Eingängen, also lief ich bei der Suche nach dem Fehler vollends in die
falsche Richtung … Hätte ich das ganze Projekt nicht mit dem STK
probiert, bzw. wie ‚LostInMusic‘ geschrieben, gewusst, wie das STK
intern verdrahtet ist, wäre ich beizeiten fertig gewesen.
Viele Grüße und vielen Dank an alle, die sich beteiligt haben
Paul
