Port(s) umschalten am tiny13 mit Problemen

[oberallgeier]

Hallo,

ich kann ein seltsames Phänomen nicht selber lösen. Hinweise in den Foren habe ich dazu nicht gefunden.

Aufgabe: Je eine LED an Port3 und Port4. Eine Taste an Port0 wird abgefragt. Ohne Tastendruck leuchtet nur die eine LED (grün), solange die Taste gedrückt wird, leuchtet nur die andere - rLED. Assembler, AVRStudio, flashen über RS232 nach dem Lernpaket, s.u.

Die Funktion ist korrekt am Experimentierboard (siehe Schaltschema, aus Lernpaket µC, Kainka) solange es an der RS232 hängt. Nach dem Reset leuchtet codegerecht die gLED, durch Tastendruck wird auf die rLED umgeschaltet.

;===================================================================================
; Deklarationen für den Praeprozessor und Konstanten (s.auch oben Speicherbelegung)

#include "tn13def.inc"

#define	a	r16	;Kurzbezeichung für Allzweckregister r16
;
#define taste0	0	;Taste0 auf PB0
#define	rLED	3	;Rote LED (auf Port PB3)
#define gLED	4	;Grüne LED (auf Port PB4)
;===================================================================================
.org	0x0000			;Interrupt Definition / I Handler Tabelle
;	Code	Labels			Comments
	rjmp 	reset		;Reset Handl. power-on, brown-out, watchdog
;===================================================================================
; Hauptprogramm
;===================================================================================
;
reset:		;=== Generelle Initialisierung
	rcall	mc_init
;
hauptpr:	;=== Löse Aufgabe: Teste Port PB0 auf Tastendruck
h2:
	sbis	pinb,taste0	;Wenn Pinb_0 (0..7) = 1, dann rLED/PB3 einschalten
	rjmp	grnan		;  sonst schalte die gLED/PB4 ein
rotan:
	sbi	portb,rLED	;Rote LED/PB3 an
	cbi	portb,gLED	;    gLED/PB4 aus
	rjmp	tastende
grnan:
	cbi	portb,rLED	;Rote LED/PB3 aus
	sbi	portb,gLED	;    gLED/PB4 an
;
tastende:
	rjmp	h2
;
;===================================================================================
; Prozeduren
;===================================================================================
;
;===================================================================================
; Initialisierungen
;===================================================================================
;
mc_init:	;=== Initialisiere Mikrocontroller
		;ALLE Register initialisieren hier := pull-ups einschalten
;
	ldi	a,0b00111000	;Datenrichtung "Eingänge" für ports 0 - 2
	out	ddrb,a		;  und         "Ausgänge" für ports 3 - 5
				;
	ldi	a,0b00111000
	out	portb,a		;  ports aus-(=) oder ein(1)schalten;  low = sink
	ret		;=====----->>>>>
;
;===================================================================================
; Ende des Quellcodes
;===================================================================================

Wenn ich die Schaltung (also die Platine nur umstecke) an einem 9V-Block laufen lasse, leuchtet sofort die rLED auf und lässt sich nicht mehr ausknipsen. Dabei ist es egal, ob ich die 9V am Anschluss RTS einleite oder, wie im Buch zum Lernpaket angegeben an DTR.

Eine Kontrolle der Spannungen ohne Peripherie und µC an der Platine mit angeschlossenem 9V-Block gab keine unerlaubten Spannungen an den 8 Pins.

Das Problem ist eigentlich aufgetaucht bei einer interruptgesteuerten Tastenabfrage mit Signalausgabe an einem Piezo. Daher hatte ich den beschriebenen Versuchsaufbau erstellt.

Der entsprechende Passus im datasheet
ATtiny13 (179 pages, revision H, updated 10/07) auf
http://www.atmel.com/dyn/resources/p...ts/doc2535.pdf
auf S 45, Abschnitt Switching Between Input and Output - oberhalb table 19 - ist mir schon so einigermassen klar - aber ich verstosse offenbar nicht dagegen (Port wird ja nur aus- und eingeschaltet - nicht von in auf out).

Kann mir bitte jemand helfen?

[radbruch]

Hallo Joe

Ich glaube, der Eingang des Tasters hängt frei in der Luft wenn der Taster nicht betätigt ist.

Abhilfe: Entweder du ziehst den PB0 mit einem zusätzlichen Widerstand (10k?) gegen GND, oder du aktivierst den internen PullUp und läßt den Taster gegen GND schalten (mit inverser Logik). In der Initialisierung steht zwar ein Kommentar mit PullUps, aber es werden die selben Bits gesetzt wie im Datenrichtungsregister und das sind ja die Ausgänge. Aber das Bit0 wird nicht gesetzt (PullUp PB0 wenn DDR für PB0 auf Eingang) und der Schalter verbindet mit Vcc, das wird nicht klappen.

PB3/4 sind nicht 3 und 4 sondern 2^3 und 2^4, also 0b00001000 und 0b00010000 bzw: 8 und 16.

Gruß

mic

[oberallgeier]

Ich glaube, der Eingang des Tasters hängt frei in der Luft

und

PB3/4 sind nicht 3 und 4 sondern 2^3 und 2^4, also 0b00001000 und 0b00010000 bzw: 8 und 16.

Mi..mann oh mann. Ich glaube Du hast recht, ich geh gleich nachmittags dran.

Zum 2^3 etc: Die Syntax ist (nach AVRStudio):

Syntax:        Operands:                          Program Counter:

(i)SBI A,b     0 </= A </= 31, 0 </= b </= 7       PC <- PC + 1

(i)SBIS A,b    0 </= A </= 31, 0 </= b </= 7      PC <- PC + 1, Condition false - no skip

... daher hatte ich für diese Befehle die Bitnummer, z.B. 4 (0 .. 7) genommen und nicht die Bitmaske, also 0b00010000 bzw. 16. Das ist dann doch ok!? Oder hab ich seit TAGEN einen Knopf im Gehirn? Zumal ich auch die Table 19 - Port Pin Configurations, wiederholt gelesen habe, aber offenbar manche Stellen dann doch nicht

Jedenfalls - vielen Dank für Deine Mühe

[radbruch]

Hallo

Das ist keine Mühe, ich will es doch selbst auch lernen.

die Bitnummer, z.B. 4 (0 .. 7) genommen und nicht die Bitmaske

Ich kann kein AVR-Assembler. Bei in und out muss man bestimmt Bitmasken angeben, sonst könnte man nicht mehrere Bits auf einmal beeinflussen.

Beim Setzen und Löschen (sbi/cbi) oder bei den bedingten Skips (sbis) muss man scheinbar wirklich die Bitnummer angeben (Datenblatt S.160). Dann wäre deine Tastenabfrage und die LED-Ansteuerung doch richtig und du hast keinen Knopf im Kopf.

Gruß

mic

[oberallgeier]

@radbruch, JAAAAA - es funzt. Genaugenommen müsste ich nachprüfen ob´s wegen des 10K zwischen PB0 und GND funktioniert oder ob es die geänderte Initialisierung war (alle ports auf 0). Aber - es geht perfekt - egal welche Stromquelle. Und auch der Beeper läuft richtig. UND - es ist datasheet-konform, also werd ich nix weiter prüfen. Danke.