Forum: Mikrocontroller und Digitale Elektronik PIN zieht den ganzen Port auf Null?


von Thilo S. (thi_lo)


Lesenswert?

Moin Moin,

als blutiger Anfänger tüftel ich mich seit einiger Zeit durch die Welt 
AVR und bin nun leider an einem Punkt angekommen, den ich mir leider 
patrou nicht erklären, geschweigedenn ihn lösen kann. Daher wende ich 
mich mal vertrauensvoll an euch! :) Mein Bauchgefühl sagt mir, dass das 
ein total dummer Anfängerfehler ist, aber ich fand nichts dazu im Forum 
und bei google.

Es geht darum an 2 Pins je einen Taster zu hängen, die eingelesen 
werden, dann jeweils zugeordnete Unterprogramme aufrufen und damit am 
anderen Ende hängende LED unterschiedlich blinken zu lassen. Wird die 
Taste losgelassen, soll aus dem Programm wieder in die Entprellung 
gesprungen werden. Eigentlich ganz banal... dachte ich ;)

Im Eingangsport (DDRD, 0x00) habe ich die internen Pullups aktiviert 
(PORTD, 0xFF). Die Tasten hängen direkt zwischen GND und PD0 und PD1. 
Die LED hängen an PB0 bis PB5.

Entprellt sind die Tasten mittels der im Tutorial gezeigten 
Tastenentprellung. Davor wird PORTB auf 0xFF gesetzt (Im Wartemodus 
sozusagen). Die Tastenentprellung läuft bis zur Eingabe im loop.

Die Tastenerkennung

Tastenabfrage:
in R16, PIND
cpi r16, 0b0111111
brne Programm1
cpi r16, 0b1011111
brne Programm2
rjmp Entprellung    ;egtl. unnötig, aber "sicherheitshalber" bei 
zittrigem Finger oder pöhsen Pins :/


Das Problem dabei ist, dass, wenn ich einen Pin auf Null lege, der ganze 
PORTD auf null gezogen wird. Dadurch funktioniert die Tastenabfrage 
natürlich nicht und er springt zur Entprellung. Ich stecke gerade auch 
gedanklich in einer Sackgasse und weiß nicht wonach ich noch suchen 
soll.

neuer Controller? selbes Phänomen.
Kurzschluss im Steckbrett? nicht gesteckt und keine "steckbrettbauliche" 
Verbindung der Ports
unterschiedliche Codes, Befehle, Programmstrukturen? selbes Phänomen.
PORTD wird nicht geändert

Woran kann das liegen? Eigentlich solle der µC doch keine Verbindung 
zwischen den Pins haben?!?!

Sicherlich kann man das auch über INT0 und INT1, externe pullups usw. 
lösen und einfacher machen, aber es geht mir ja darum zu kapieren und da 
helfen mir umständige Programme.

Für einen kleinen, zaunpfahligen Wink bin ich äußerst dankbar.
Grüße
Thilo

von Uwe (Gast)


Lesenswert?

Also Schaltplan fehlt. Und
> Die Tasten hängen direkt zwischen GND und PD0 und PD1.
> in R16, PIND
> cpi r16, 0b0111111
> brne Programm1
> cpi r16, 0b1011111
0b1011111 sind nur 7 Bit 8 Bit sind
0b10111111
Und      ^ hier ist Bit 0 !
Die niederwertigen Stelle sind wie bei anderen Zahlensystemen immer 
Rechts.
Bei der Zahl 567 entspricht die 7 den einern (10^0).
                            die 6 den Zehnern(10^1).
                            die 5 den Hundertern(10^2).

von Karl H. (kbuchegg)


Lesenswert?

Zeig doch mal den Rest des Programms.
Deine Fehlerbeschriebung klingt ganz danach, als ob du mit dem Taster 
einen Kurzschluss herstellst, so wie er zb auftreten würde, wenn du den 
Port D auf Ausgang geschaltet hast.

von Sebastian W. (wangnick)


Lesenswert?

Vielleicht bricht AVCC zusammen? Wieviel Strom ziehen die LEDs wenn sie 
angehen?

LG, Sebastian

von Rene H. (Gast)


Lesenswert?

Den Zusammenhang zu AVCC musst Du erklären.  Ich sehe da keinen.

Grüsse,
René

von Sebastian W. (wangnick)


Lesenswert?

Rene H. schrieb:
> Den Zusammenhang zu AVCC musst Du erklären.  Ich sehe da keinen.
>
> Grüsse,
> René

Bei manchen AVR versorgt doch AVCC statt VCC einige Ports. Vielleicht 
bricht AVCC intern ein, und VCC hält den uC trotzdem am Laufen.

Klingt mich jetzt im Nachhinein aber auch ein wenig weit hergeholt ...

LG, Sebastian

von Karl H. (kbuchegg)


Lesenswert?

Sebastian Wangnick schrieb:

> Klingt mich jetzt im Nachhinein aber auch ein wenig weit hergeholt ...

Nicht unbedingt.
Mit den wenigen brauchbaren Informationen muss man spekulieren.

von ASM (Gast)


Lesenswert?

Am AVR bricht nichts zusammen. Warum meinst du das?

Was soll der Code???

Thilo S. schrieb:
> Tastenabfrage:
> in R16, PIND
> cpi r16, 0b0111111
> brne Programm1

Wenn der Vergleich nicht "wahr" ist, also das Bitmuster ungleich ist 
weil die Taste 1 nicht gedrückt wurde, springt er Programm1 an. Du 
wolltest das bestimmt andersherum. Es wird praktisch immer dann zu Prog1 
gesprungen, wenn PIND nicht 0b0111_1111 ist (hab das fehlende Bit mal 
ersetzt)

> cpi r16, 0b1011111
> brne Programm2

Es wird praktisch immer dann zu Programm2 gesprungen, wenn PIND nicht 
0b1011_1111 ist (hab das fehlende Bit mal ersetzt)



> rjmp Entprellung

Sinnlos..

von Thilo S. (thi_lo)


Angehängte Dateien:

Lesenswert?

Nabend,

und...wow! Was ich hier schon öfter las, trifft echt zu! Viele schnelle 
Antworten. Vielen lieben Dank dafür! :)

Uwe schrieb:
> Also Schaltplan fehlt

Am Schaltplan ist nichts besonderes, sondern identisch zum 
Tutorialaufbau und der Übung. Nur dass eben nicht die Taste direkt 
wieder ausgegeben wird, sondern in ein Programm wechselt

                 ___
                |     |
 GND---Taster---|     |----LED---1kOhm---VCC
                |     |----LED---1kOhm---VCC
 GND---Taster---|     |----LED---1kOhm---VCC
                |     |----LED---1kOhm---VCC
                |_____|

Ich bin mit den Symbolen und dem Zeichnen von Schaltplänen in LTSpice 
noch nicht geübt und von Hand sähe es wohl noch schlimmer aus. Kleines 
Bild vom Steckbrett ist angehängt. GND und VCC sind natürlich auch 
beschaltet.

Uwe schrieb:
> Die niederwertigen Stelle sind wie bei anderen Zahlensystemen immer
> Rechts.

OK. Das ist jetzt peinlich. Selbst für mich. Und das schlimme daran ist, 
es löste sogar das Problem, dass ein Pin den ganzen Port auf Null zieht. 
Zumindest ist es heute weg.

ASM schrieb:
> Was soll der Code???

Jap das hatte ich andersrum verstanden. Danke für die Umformulierung. :)

Und irgendwie habe ich gerade nebenbei bemerkt, als ich die Hinweise von 
oben einpflegte, warum das Programm überhaupt nicht laufen wollte und so 
garnicht machte, was ich programmierte. "Build Solution" griff irgendwie 
auf ein anderes Projekt zu und zeigte dies (zum Glück) im Outputfenster 
an. Hätte ich mal eher lesen sollen.
Hat jemand einen Tipp woran das lag?

Einzige unerklärliche Fragen wären nun noch, warum er aus Prog1 nach 
Prog2 springt und Prog1 nicht beendet, wenn ich die Taste wieder 
loslasse. Aber ich hör für heute auf.

Gute Nacht :)

von Fred S. (kogitsune)


Lesenswert?

Wenn ich von einem Atmega48/88/168 ausgehe (welchen AVR verwendest Du?), 
fehlt die Versorgung an Pin20 und GND an Pin 22; stattdessen ist 
fälschlicherwise Pin 21 auf GND gelegt. Zudem sehe ich keine 
Entkopplungskondensatoren an jeder Versorgungsleitung des Prozessors.

: Bearbeitet durch User
von Sebastian W. (wangnick)


Lesenswert?

Hallo Thilo,

funktioniert es jetzt?

LG, Sebastian

von Thilo S. (thi_lo)


Lesenswert?

Moin,

jain ;)

Fred S. schrieb:
> Wenn ich von einem Atmega48/88/168 ausgehe

Ich spiele mit einem ATMEGA8-16PU. VCC und GND sind richtig 
angeschlossen. Auch mit AVCC und den Entkopplungskondensatoren hat sich 
nichts geändert.

Nach der MSB/LSB Peinlichkeit erkennt er den richtigen Pin und springt 
auch in das Unterprogramm.

Ich komme leider nur am WE zum rumbasteln, daher die späte Antwort.

Jetzt werde ich mal gucken, warum er nicht korrekt in den "Wartemodus", 
bzw- die Tastenerkennung zurückspringt.

Grüße
Thilo

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.