www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Das STK500 verwirrt mich.


Autor: mikromaik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Netbird (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HAst du bedacht, dass das STK500 bei der Ausgabe invertiert? Steht 
irgendwo im Manual ..

Autor: mikromaik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Mahlknecht (pmahlknecht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du Port B als Ausgang geschaltet? DDRB = 0xff ?

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
lässt sich das Programm auf den Chip programmieren?

Autor: mikromaik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mikromaik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

...

Autor: Martin Z. (zilluss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du auch nur den ATTiny auf dem Board oder hast du vielleicht auf 
einem anderen Sockel einen anderen µC. (ist mir schon passier^^)

Autor: Werner A. (homebrew)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast auch den Port mit den LEDs verbunden?

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

...

Autor: AVRFan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Programmcode?

Flachbandkabel versehentlich verdreht?

Autor: mikromaik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?
.include "tn13def.inc"

.org 0

ldi r16, 0xFF
out DDRB, r16

ldi r16, 0b00000000
out PORTB, r16

ende:    rjmp ende

Autor: AVRFan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mikromaik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: AVRFan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: mikromaik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael H* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.atmel.com/dyn/resources/prod_documents/...
steht normalerweise im manual.
allerdings ist der tiny13 da noch nicht aufgeführt. probier doch einfach 
mal den andren sockel

Autor: Michael H* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nachtrag: da der tiny13 pinkompatibel mit dem im manual aufgeführten 
tiny11 ist, sollte der D1 schon stimmen.

Autor: AVRFan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mikromaik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich benutze das STK500 mit AVR-Studio von ATMEL, also mit der Software, 
die dafür vorgesehen ist.

...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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&f...

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.

Autor: mikromaik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: mikromaik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das muss natürlich "Die Datei die AvrAssembler2 defaultmäßig 
ausspuckt..." heißen... ;)

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

;-)

...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Noch_ne_Frage (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.