Morgen! Um das STK500 zu testen, habe ich auf einem ATtiny13v ein simples Testprogramm laufen lassen, welches einfach alle Pins von Port B auf 0 setzt und PortB mit dem LED-Anschluss verbunden um die LEDs zum leuchten zu bringen. Als das nicht funktioniert hat, habe ich die Spannungen an den Pins gemessen, die befanden sich alle in etwa auf dem Level von GND. Um die LEDs zu testen habe ich die Pins am LED-Anschluss nacheinander mit dem GND von Port B verbunden. Auch da verhielt es sich wie erwartet, die LEDs leuchteten. Nur, wenn ich PortB mit dem LED-Anschluss verbinde leuchtet nichts. Was ist da los?
HAst du bedacht, dass das STK500 bei der Ausgabe invertiert? Steht irgendwo im Manual ..
Ja, darum habe ich die Pins auf 0 gesetzt. Das Problem ist, dass die LEDs trotzdem nicht leuchten, obwohl sie es gegen GND geschaltet tun.
Ja, der Port ist auf Ausgang geschaltet und der ATtiny lässt sich programmieren. Wenn ich alle Ports auf 1 setze, liegt der Pegel von rund 5 V an. An der Pinleiste liegen die Pegel ebenfalls an. Alles verhält sich wie erwartet, außer, dass die mit dem 10-adrigen Kabel angeschlossenen LEDs nicht leuchten. Auch wenn ich das Programm auf einem jungfräulichen ATtiny schibe, ändert sich nichts. Daran kann es auch IMHO nicht liegen, da die Pegel an den Pins ja die Werte haben, die sie haben sollen.
Die Pegel an den Pins des ATtiny sind nur solange korrekt, bis ich PORT B mit den LEDs verbinde. Dann sind sie alle auf High, es fällt also keine Spannung an den LEDs ab. Das sollte nicht so sein, oder?
Du weißt aber, dass die LEDs nicht direkt geschaltet sind sondern über je einen Transistor? Dass die Spannung am Port zusammenbricht, lässt mich vermuten, dass der Port doch nicht richtig auf Ausgang geschaltet ist (DDRB muss auf $FF gesetzt werden), sondern dass Du Die Pegel über die internen PullUp-Widerstände schaltest. ...
Hast du auch nur den ATTiny auf dem Board oder hast du vielleicht auf einem anderen Sockel einen anderen µC. (ist mir schon passier^^)
Und Du weißt auch, dass man zum Flashen eines 8-Pinners ein paar separate Verbindungen mit den beiliegenden Strippen stecken muss? Falls nicht, dann schau mal in die Hilfe. ...
Es befindet sich wirklich und wahrhaftig nur dieser eine Controller auf dem Board und ja, auch die LEDs habe ich, wie bereits erwähnt, mit PORT B verbunden, wenn ich die LEDs leuchten sehen wollte... Der Code sieht so aus, alle Ports sind als Ausgänge konfiguriert, was, wenn ich das Datenblatt richtig verstanden habe, die pull-up Widerstände automatisch ausschaltet, richtig?
1 | .include "tn13def.inc" |
2 | |
3 | .org 0 |
4 | |
5 | ldi r16, 0xFF |
6 | out DDRB, r16 |
7 | |
8 | ldi r16, 0b00000000 |
9 | out PORTB, r16 |
10 | |
11 | ende: rjmp ende |
Ich glaube, mich an einen Fall hier erinnern zu können, wo jemand x-mal versehentlich die falsche Datei gebrannt hat. IIRC war es auch ein AVRStudio-Nutzer. Mangels weiterer Ideen: check das mal.
Das ist es leider auch nicht. Ich habe das schon mehrfach gecheckt und auch jetzt bin ich zu dem Ergebnis gekommen, dass es das nicht sein kann. Dafür spricht auch, dass ich testweise alle Ports auf 1 gesetzt habe und dann nachgemessen habe, was wie erwartet funktioniert hat.
Flash mal das: ldi r16, 0b00001111 out DDRB, r16 ldi r16, 0b11001100 out PORTB, r16 ende: rjmp ende Hier sind alle Kombinationen vertreten. Es müssen zwei benachbarte LEDs leuchten.
also wenn du die leds anschließt und an den pins dann eine spannung misst, liegt es daran, dass die treibertransistoren der leds einen pullup haben. steckt der attiny vllt im falschen sockel o_O?
Er steckt im auf ...D1 endenden Sockel. Da im Datenblatt nicht stand, in welchen Sockel der ATtiny13 gehört, habe ich im Internet recherchiert. Das ist doch der Richtige, oder?
http://www.atmel.com/dyn/resources/prod_documents/doc1925.pdf steht normalerweise im manual. allerdings ist der tiny13 da noch nicht aufgeführt. probier doch einfach mal den andren sockel
nachtrag: da der tiny13 pinkompatibel mit dem im manual aufgeführten tiny11 ist, sollte der D1 schon stimmen.
>Das ist doch der Richtige, oder?
(AVRStudio, STK500) Ein erfolgreiches Flashen des Programms wird ja mit
einigen OK-Meldungen im Programmierfenster bestätigt. Wenn die
ordnungsgemäß erscheinen, steckt der ATtiny13 definitiv im richtigen
Sockel.
Wenn das Prüfen der Signatur und das Verify klappt, dann ist es der richtige Sockel und die richtigen Verbindungen. Ansonsten unter AVRStudio -> Hilfe -> STK500 nachsehen, da ist alles aufgelistet. Um zu überprüfen, ob man wirklich das richtige hex-File brennt, das hex-File löschen, dann muß der Programmer ne Fehlermeldung bringen. Dann neu compilieren und brennen. Peter
Ich benutze zum Übersetzen (unter Linux) den AVRAssembler2, emuliert über wine, da ich avr-gcc bisher noch nicht compiliert bekommen habe und avra sich standhaft geweigert hat den Code zu übersetzen, da es mit bestimmten Direktiven der ATMEL Bibliotheken nicht einverstanden war. Flashen tu ich mit avrdude. Der überprüft den Code nach dem flashen ebenfalls.
Ich benutze das STK500 mit AVR-Studio von ATMEL, also mit der Software, die dafür vorgesehen ist. ...
mikromaik wrote: > Flashen tu ich mit avrdude. Der überprüft den Code nach dem flashen > ebenfalls. Stell ihn mal auf die Probe, mach mal nur Verify und dann ändere was im Code und mach nochmal Verify, ob er dann meckert. Ich hab immer nur AVRStudio benutzt, kann also zu anderen Programmen nichts sagen. Mit AVRStudio hatte ich jedenfalls noch nie Probleme. Peter
Peter Dannegger wrote: > Stell ihn mal auf die Probe, mach mal nur Verify und dann ändere was im > Code und mach nochmal Verify, ob er dann meckert. Ist doch Ulk, Peter. Wenn das verify im AVRDUDE ging, dann ist der Code da auch drin. Mr. mikromaik, wenn du den GCC nicht compiliert bekommst, guck dir mal das Buildscript hier an: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=42631 Wenn das auch nicht funktioniert, dann poste im GCC-Forum die Fehlermeldungen, die du bekommen hast. Ansonsten kannst du ja hier mal das Hexfile posten, mit dem du testest.
Ich habe es jetzt! Endlich! Die AvrAssembler2 defaultmäßig ausspuckt habe ich bisher als raw binary auf den Controller geschoben. Jetzt habe ich statt des default-Formats Intel Hex erzeugt und die Datei dann als eben jene geflasht. Die LEDs leuchten jetzt! Danke euch allen!
Das muss natürlich "Die Datei die AvrAssembler2 defaultmäßig ausspuckt..." heißen... ;)
mikromaik wrote: > Das muss natürlich "Die Datei die AvrAssembler2 defaultmäßig > ausspuckt..." heißen... ;) Ist das ein Lama? Ich möchte diese Sauerei (Spucken) nicht haben... ;-) ...
Jörg Wunsch wrote: >> Stell ihn mal auf die Probe, mach mal nur Verify und dann ändere was im >> Code und mach nochmal Verify, ob er dann meckert. > > Ist doch Ulk, Peter. Wenn das verify im AVRDUDE ging, dann ist der > Code da auch drin. Nö, ist kein Ulk. Dann ist zwar irgendein Code drin, aber ob es auch der ist, an dem er gerade arbeitet ??? Peter
Hallöchen, ich krame diesen Thread mal wieder aus, weil ich in einem der Beiträge gelesen habe, dass das STK die ausgänge invertieren würde... Tatsächlich fällt mir etwas ähnliches auch gerade bei meinem kleinen Programmchen auf, aber in der Anleitung zum STK500 habe ich das wohl bisher übersehen... ...mit anderen Worten: wenn ich mit dem STK500 etwas testweise aufbauen debuggen möchte, dann muss ich für die spätere Umsetzung alles nochmal invertieren? mfg
Noch_ne_Frage schrieb: > ...mit anderen Worten: wenn ich mit dem STK500 etwas testweise aufbauen > debuggen möchte, dann muss ich für die spätere Umsetzung alles nochmal > invertieren? Nö. Du soltest Deine Schaltung doch genauso aufbauen, wie getestet. Bei den Eingängen braucht man dann keine extra Pullups. Peter
Thread beobachten
Seitenaufteilung abschaltenBitte 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.