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?
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.
...
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?
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?
>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.
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!
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
