-         

Ergebnis 1 bis 5 von 5

Thema: Port(s) umschalten am tiny13 mit Problemen

  1. #1
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    7.557

    Port(s) umschalten am tiny13 mit Problemen

    Anzeige

    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.

    Code:
    ;===================================================================================
    ; 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?
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken tastest91.jpg   lp-_c-kainka.jpg  
    Ciao sagt der JoeamBerg

  2. #2
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    54
    Beiträge
    5.782
    Blog-Einträge
    8
    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

    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

  3. #3
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    7.557
    Zitat Zitat von radbruch
    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):
    Code:
    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
    Ciao sagt der JoeamBerg

  4. #4
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    54
    Beiträge
    5.782
    Blog-Einträge
    8
    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

    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

  5. #5
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    7.557
    @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.
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken mod-img_1387.jpg  
    Ciao sagt der JoeamBerg

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •