Hallo Leute, Sorry, bin ein Mikrocontroller neuling, deswegen: mal eine allgemeine verständnissfrage, wenn ich bei meinem ATMega16, einen Port als Output definiere, dann werden alle Pins dieses Ports auf High gesetzt. Um jetzt alle Pins auf low zu setzen, muss ich dem Port den Hexwert &HFF zuweisen. Meines wissens bedeutet das aber, das die Pins auf High gesetzt werden. Um nun laut meines Datenblattes vom LCD die entsprechenden Ports auf 0 zu setzen und die anderen auf 1 zu lassen, muss ich die Ports, die 0 werden sollen den Hexwert mit 1 zuweisen. Bsp.: (Hex) &HFF -> Bedeutet eigentlich 11111111 (Binär) im Output aber 00000000 Laut Datenblatt sollen alle Ports auf 0 gesetzt werden, also muss ich dem Port den wert &HFF zuweisen. Ist das so richtig ??? Danke im Vorraus.
Wie kommst du da drauf? Bist du vielleicht durch das DDR Register verwirrt? Das ist kein Port Register sondern gibt die Datenrichtung an (DDR=Data Direction Register). DDRA=0x0F heisst dass die Bits 0-3 von Port A ein Ausgang sind, die Bits 4-7 sind als Eingang geschaltet. Das brauchst du nur einmal am Programmanfang machen. Wenn ein Pin als Ausgang geschaltet ist, dann kannst du mit sbi(PORTA,0) den Pin 0 auf High schalten, mit cbi(PORTA,0) schaltest du das auf Low. Oder PORTA=0x03 setzt Bit 0 und 1 auf High, alles andere auf Low. Ist z.B. Pin 7 als Eingang geschaltet, kannst du mit x=PINA & 0x70 ihn auf High testen.
Falls du avrgcc benutzt, vergiss cbi () und sbi (). Benutze statt dessen das Makro _BV(...)
Danke erstmal für die schnelle Antwort, ich hab mir jetzt mal eine kleine Testschaltung auf meinem STK500 aufgebaut. Mein Problem ist jetzt, wenn ich irgendeinen Port z.B. Portb als Ausgang definiere, dann setzt das Board die LEDs bei CBI auf eingeschaltet (dementsprechend 1 oder High) und bei SBI auf low. Meines wissens aber sollte er sie bei SBI auf high setzten und bei cbi auf low.(danke auch nochmal an Fritz) Habe ich jetzt einen Denkfehler oder macht das Board die ganze sache einfach umgedreht?
Beim STK500 werden die LED über einen Transistor geschaltet und leuchten, wenn der entsprechende AVR-Ausgang auf Low-Pegel gesetzt wird. Es ist also in der Tat eine inverse Logik. Gruß, Frank
Hi... Hast du die LEDs gegen GND oder gegen +5V geschaltet? Leuchten sie also bei H oder L am Portpin des AVR?? Bit- & Bytebruch... - ...HanneS...
@Alex "Falls du avrgcc benutzt, vergiss cbi () und sbi (). Benutze statt dessen das Makro _BV(...)" Wieso soll das eigentlich verschwinden? Ich finde cbi und sbi bei einzelnen bits übersichtlicher, und es ist nix anderes als: #define sbi ( sfr, bit ) (_SFR_BYTE(sfr) |= _BV(bit)) Also macht es genau dasselbe. Und wenn man einzelne Bits setzt macht der Compiler eh wieder ein sbi draus: 225:lkw.c **** PORTD |= _BV (7); 515 .LM58: 516 014e 979A sbi 50-0x20,7
Danke für eure antworten, ich hab auf die Antwort von Frank nochmal das Datenblatt für das STK500 durchgesehen. Es liegt wirklich daran, das sie gegen einen Transistor geschalten sind. Trotzdem danke. P.S. Ich finde SBI und CDI auch sehr gut, um einzelne Bits zu setzen.
Ich nochmal, hab jetzt die ganze sache mal auf einem eigenem Board ausprobiert, dort stehe ich vor dem gleichen Problem. Bei SBI erlischt mein LED und bei CBI geht es wieder an. Es sollte doch eigentlich umgedreht sein. Code: ------------------- Ddrb = &B11111111 sbi portb,0 Schaltung: ------------------- Portb.0 ----|>------ 5V Pin LED Stromquelle
Du willst ja, dass die LED leuchtet, wenn dein Pin auf HIGH ist. Dementsprechend muss die Anode deiner LED am Pin und die Kathode an Masse (Vorwiderstand nicht vergessen).
Ok, hab ich geradeebend auch festgestellt, hab den fehler gemacht, das ich das LED einfach nur drehen brauch. Dementsprechend war bei HIGH das LED in Sperrichtung geschaltet. Danke nochmal, denkfehler von mir.
NEIN!!! Nicht drehen, sondern die Kathode an Masse. Allerdings solltest du unbedingt noch einen Vorwiderstand mit mind. 150Ohm in Serie schalten.
Ich glaube er meinte, dass er vorhin den Irrtum gemacht hat, dass er die Diode drehte, aber vergass an er an den anderen Pin nun statt Vcc jetzt GND anzuschliessen.
>Wieso soll das eigentlich verschwinden? Ich finde cbi und sbi bei >einzelnen bits übersichtlicher, und es ist nix anderes als: > #define sbi ( sfr, > bit ) (_SFR_BYTE(sfr) |= _BV(bit)) > >Also macht es genau dasselbe. Weil es verschwinden wird! Ab- und zu sollte man doch mal in die Doku der avr-libc schauen, dann bleiben einem einige Überraschungen erspart! http://www.nongnu.org/avr-libc/user-manual/deprecated.html >Und wenn man einzelne Bits setzt macht der Compiler eh wieder ein sbi >draus: > >225:lkw.c **** PORTD |= _BV (7); > 515 .LM58: > 516 014e 979A sbi 50-0x20,7 Das ist nicht zwangsweise so. In diesem einen Beispiel macht der Compiler ein sbi daraus. Zitat JW, ( http://www.mikrocontroller.net/forum/read-2-92478.html#92603 ): >Sofern yourtriggerbit zur >Compilezeit konstant ist, würde der AVR-GCC daraus übrigens (bei >eingeschalteter Optimierung) SBI und CBI Anweisungen zimmern.
> Beim STK500 werden die LED über einen Transistor geschaltet und > leuchten, wenn der entsprechende AVR-Ausgang auf Low-Pegel gesetzt > wird. Es ist also in der Tat eine inverse Logik. > > Gruß, Frank Hallo Frank, der Transistor beim STK500 dient nicht zum schalten der jeweiligen LED, er sorgt dafür daß sich die LEDs bei jedem zulässigen VTG Wert wohl fühlen.. Im weiteren endet die Kathode jeder LED dann auch wieder im AVR. Gruß, Sascha
Hallo Sascha, Du hast recht; habe gerade im Datenblatt nachgesehen. Ich hatte nur noch im Kopf, dass da ein Transistor im Spiel ist und die LED gegen VCC betrieben wird. Warum, wieso und weshalb war mir entfallen <blush>. Gruß, Frank
Da mein letzter Post ein wenig für verwirrung gesorg hat... ich meinte das mit dem LED drehen so... Schaltplan: Pin vom MC o------>|------o Masse LED Funktioniert auch... Und den Rv natürlich nicht vergessen....
da die LED aber so um die 20mA zum Leuchten benötigt, dürfte das Dein Portpin nicht lange mitmachen! Schau mal in die maximum ratings im Datenblatt...
Hi OldBug, DC Current per I/O Pin ............................ 40.0 mA und Although each I/O port can source more than the test conditions (20 mA at Vcc = 5V, 10 mA at Vcc = 3V) under steady state conditions (non-transient), the following must be observed: PDIP Package: 1] The sum of all IOH, for all ports, should not exceed 400 mA. 2] The sum of all IOH, for port A0 - A7, should not exceed 200 mA. 3] The sum of all IOH, for ports B0 - B7,C0 - C7, D0 - D7 and XTAL2, should not exceed 300 mA. ;-) Gunter
@Chris, was die Jungens meinen ist: Ein Pin des AVR's kann mehr Stom ziehen als Strom treiben. Deshalb schaltet man die LEDs meisten von Vcc nach Pin nach Masse, und demzufolge ist die Logik invertiert. In diesem Moment fließt der Stom von Vcc durch die LED durch den Pin nach Masse, der Pin zieht Strom. Man kann aber die LED auch von Pin nach Masse schalten. In diesem Moment treib der Pin, d.h. der Strom fließt von Vcc über Pin durch LED nach Masse. Die Logik der Softwaremäßigen Ansteuerung der Pins wäre dann aber nicht invertiert. Sorry, wenn ich dies mal so primitiv erklärt habe. Gruß Hagen
Hallo Hagen,
>Ein Pin des AVR's kann mehr Stom ziehen als Strom treiben
Da muß ich leider auch widersprechen:
Although each I/O port can sink more than the test conditions (20 mA at
Vcc = 5V, 10 mA at Vcc = 3V)
...
Although each I/O port can source more than the test conditions (20 mA
at Vcc = 5V, 10 mA at Vcc = 3V)
Obwohl es sicher nicht die "feine Art ist" und ich grundsätzlich
eine Treiber Transistor benutze.
Schöne Grüße
Gunter
Hallo, früher, in den guten alten Zeiten ..., konnten die AVRs mehr Strom sinken als sourcen. So war es bei der AT90 Reihe, mit der ATMEGA und ATTINY Serie hat sich das dann in Wohlgefallen aufgelöst, somit ist diese 'Wie herum dran mit der LED?'-Frage für alle ATMEGA/ATTINY Benutzer recht trivial. Gruß, Sascha
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.