mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik LEDs des STK-500 leuchten nicht, obwohl User Guide gelesen!


Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

nachdem einerseits meine ersten Algorithmen in der Simulation schon
laufen und ich es andererseits nichtmal geschafft habe, eines der LEDs
aufm STK-500 zum leuchten zu bringen (!), habe ich jetzt mal die
"example application" aus "Section 9" des "User Guide" ins Studio
getippt.

Die Sache ist, das (wie auch schon bei meinem eigenen Programm und
meinem Versuch, einfach nur ne LED des Boards zu erleuchten) das Prog
korrekt geflashed wird (EEPROM brauch ja wohl nicht wenn man es nicht
benutzt oder liege ich da falsch?)

Also im Studio scheint alles OK zu sein, Simulation sieht auch schön
aus, Flashen klappt. Jedoch die LEDs auf dem Board bleiben alle
dunkel.

Die Ports sind korrekt initialisiert (vorausgesetzt, die example
application ist korrekt). Die Jumper sind so gesetzt, wie im Handbuch
beschrieben. Die VTarget-Spannung ist auch korrekt.

Die Port-Verbindungskabel sind wie auf dem Foto im User Guide (und
nicht wie im Troubleshooting Guide Rev. 1925C-AVR-3/03 - dort ist die
Anschluß-Beschreibung vertauscht)

Der Zielprozessor ist ein (parallel programmierter) ATMEGA16. Beim
Proggen waren die Port-Kabel nur mit den Programmierschnittstellen auf
dem STK verbunden. Beim Ausprobieren sind nur die Switch- und
LED-Header verbunden.

Den Referenzspannungs-Jumper auf dem Board hatte ich beim flashen nicht
drauf (ich dachte den würd ich erstmal eh nicht brauchen), hab ihn dann
zum testen (nachdem´s nicht ging) draufgesetzt (um die im Handbuch
beschriebene Situation herbeizuführen).

Die Masse ist 0V und nicht -0V. Dadurch geht das STK am Mikroschalter
ufm Board nicht aus. Laut User Guide soll man entweder -0V nehmen oder
das Board per Stecker rausziehen ausschalten. Ich verwende letztere
Methode.

Hat jemand ne Ahnung, wieso nichtmal das example laufen tut? Woran
könnte das liegen?

Habe schon haufenweise STK-500-Threads gelesen und keinen Hinweis
gefunden...

Autor: Eumel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,
hast du auch Port B auf die LEDs und Port D auf die Schalter gesteckt?
Das Foto im User-Guide zeigt eine andere Konfiguration.

Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja hab ich. Hab das extra noch im Code überprüft weil es im
Troubleshooting falsch herum angegeben war.

Bald krieg ich ne AVR-Psychose ;)

Um endlich die Erfahrung zu machen, das überhaupt irgend etwas aus dem
Ding rauskommt hab ich folgenden 6-Zeiler in den AVR geflashed:

include "m16def.inc"
reset:
SBI DDRC,0
main:
SBI PortC
jmp main

Pin 0 soll als Ausgang geschaltet werden und in einen High Zustand
versetzt werden. Nach dem Flashen habe ich eine LED an PortC Pin0 gegen
0V angeschlossen. Die LED wurde auf Funktion und korrekte Einbaurichtung
geprüft und für einwandfrei befunden. Sie leuchtet über 300 Ohm direkt
an 5 Volt angeschlossen, doch am AVR leider nicht. Ich habe auch mal
versucht ob ich aufgrund von Unwissenheit einen invertierten Output
oder sowas erzeugt habe. Doch auch ein low an PortC,0 oder ein CBI an
DDRC,0 brachte keine Veränderung.

Alle Kabel hab ich auch korrekt abgezogen (je nachdem ob gerade testen
oder flashen angesagt war)

Also irgendwas läuft da doch schief und bei einem Sechszeiler wird mir
hier doch hoffentlich jemand sagen können was es ist bzw. sein könnte?

Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die LED am AVR natürlich ohne Vorwiderstand (da sollten doch 20mA oder
so rauskommen?)

um Mißverständnissen soweit wie möglich vorzubeugen...

Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und die Clock des AVR hab ich auch noch vorsichtshalber auch mal auf
"intern" geschaltet.

Autor: Timo (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Alisa.
Also erstmal glaube ich, das Ausgänge im DDR immer auf 1 gesetzt werden
müssen (hab ich jedenfalls so bei mir und klappt). Ausgänge
dementsprechend auf 0.
Zweitens bin ich nicht so der Profi, benutze aber auch einen ATMega16
und hänge deswegen mal mein 100%tig funktonierendes Programm für diesen
uC an. Ich benutze auch das STK500. Wenn das bei dir keinen defekt hat
und du es richtig konfiguriert hast (und danach siehts erstmal aus)
müsste es dann auch funzen.
Habs aber per serieller Schnittstelle (ISP) programmiert. Find ich
einfacher, weil du testen und programmieren kannst, ohne etwas zu
verändern.

Zum Anhang:
Nimm das bitte nicht als das beste Programmierbeispiel. Es ist zwar gut
kommentiert, aber meine Tasterentprellung ist wohl nicht gut erdacht.
Dennoch, sie funktioniert, jedenfalls auf dem ATMega16. Bei meinem
ATtiny12 schon nicht mehr so reibungslos.

Probiers mal aus und viel Spaß

Grüße

Timo

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
halt... Freudscher Verschreiber ..
Ausgänge auf 1, Eingänge auf 0 ..
so

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du ja auch, wie ich gerade feststelle. Dann kann ich dir auch nicht
helfen, ausser mit meinem Code.

Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Timo

"Ausgänge auf 1, Eingänge auf 0 .."

genau das sollte hier doch passieren (und tut´s laut Simulator auch):

SBI DDRC,0  ;setze Bit 0 im PortC-Datenrichtungsregister

Danke für den Code. Der benutzt auch die Taster & LEDs vom STK-500,
oder?

Allerdings weiß ich nicht ob ich den
noch probieren sollte wenn nichtmal ein Pin auf high geht. Wenn in den
6 Zeilen tatsächlich kein Fehler zu entdecken ist dann sollte ich wohl
eher mal den Controller auswechseln.

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, da fällt mir noch etwas ..
Der AVR ist in der Lage, 20mA zu liefern. Alles darüber ist thermisch
sicher ungesund für ihn. Der Strom wird sicher nicht vom AVR begrenzt
und deshalb ist ein Vorwiderstand unerlässlich, um nicht Gefahr zu
laufen, den uC zu zerstören. Die LED's auf dem Board haben auch
Vorwiderstände, wenn man genau hinsieht.
Also, keine LED ohne Vorwiderstand. Nicht mal, wenn die
Versorgungsspannung gleich der Durchbruchspannung ist !

Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ach so dann tausche ich mal den AVR u9nd probier das nochmal mit
Widerstand. Wieviel Ohm sollte der denn haben?

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal ein kleines Testprogramm:

include "m16def.inc"

ldi r16, 0xFF
ldi r17, 0xAA
out DDRA, r16
out PORTA, r17
out DDRB, r16
out PORTB, r17
out DDRC, r16
out PORTC, r17
out DDRD, r16
out PORTD, r17
rjmp PC

Es sollte jede 2. LED leuchten, egal welcher Port.

Peter

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei 5V kannst du bedenkenlos einen 220 Ohm Widerstand nehmen .. alles
nahe daran ist auch ok. so zw. 150 und 330 Ohm sollte gehen.

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@alisa

zu deinem Beitrag etwas weiter oben.
Ja, ich benutze Taster und Ports vom STK. PortD sind die Taster, PortB
die LED's. Aber bedenke, das bei meinem Prog die LED's aus gehen,
wenn sie eigentlich An sein sollten. Das liegt daran, das ich die
LED's nicht auf Masse schalte, sondern den Transistor an der Basis mit
einer RC-Kombination ansteuere, um ein "faden" der LED's zu erhalten.
Auf dem STK geht dafür halt die entsprechende LED aus, weil ich dort ja
den Emitter der Transistoren auf 5,1V lege.
Kaputt gehen kann der Controller durch mein Programm nicht, er läuft
hier schon in mehreren Lampen und das dauerhaft und ohne
Komplikationen. Also teste ruhig mit dem bisherigen und mit einem
neuen. Schätze, der alte hat sich aufgrund der fehlenden
Strombegrenzung verabschiedet.

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Vollständigkeit halber hier noch die simple Formel für den
Vorwiderstand:
R=U/I

I sollte bei LED's (gerade, wenn Batteriebetrieb geplant ist) die 10mA
(0,01A) nicht überschreiten. Für das menschl. Auge ist der
Helligkeitsunterschied kaum wahrnehmbar.
U ergibt sich aus der Differenz zw. Ub (also ca. 5V) und Uf (U forward)
der LED. Bei normalen LED's ca. 1,6-1,9V.
Bleiben also ca. 1,3 V übrig. geteilt durch 0,01A ergibt das 130 Ohm.
Liegen wir also mit den 150 Ohm ganz gut.
Viel spaß beim Löten ..

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mann mann ... wenn man nicht alles zweimal liest. 5V-1,7V ergibt
natürlich 3,3V, und somit sollte der Vorwiderstand bei 330 Ohm
liegen...

Timo
(peinlich berührt)

Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter Dannegger:

Danke für den Testcode. Ich habe bereits zuvor den Prozessor gewechselt
(90S8515) und den "Example Code" nochmals geprüft. Doch das
Atmel-Example tat immer noch nicht.

Jetzt hab ich deinen Testcode geflashed (den include-file-Verweis
natürlich geändert) und den LED-Port mit einem der Prozessorports
verbunden. Immer noch nix passiert. Hätte mich auch gewundert - das
Atmel Beispiel sollte doch ebenso lauffähig sein...

Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na dann muß ich mich wohl mal direkt an Atmel wenden... Komische Sache
jedenfalls.

Autor: Daniel R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich weiß jetzt nicht ob die Frage berechtigt ist, aber einfach mal so:
In welchem Sockel hast du den ATmega16 denn stecken?
Der muss nämlich in den "SCKT3100A3".
Könnte ja sein, dass du den Mega16 in den gleichen Sockel wie den
8515(der standardmäßig auf dem Board steckt) gesteckt hast.
Aber wie gesagt, ich weiß nicht, ob da überhaupt was gehen würde, da
ich es noch nie ausprobiert habe.
Ansonsten fällt mir auch nichts anderes mehr ein.
Gruß Daniel!

Autor: Kurt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo "Alisa 1387"

schreib mal wie deine Datei genau heisst

Gruss Kurt

Autor: Eumel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

stelle doch 'mal das Hexfile das du in den Prozessor lädst, dann
probiere ich das 'mal zu Hause aus.

Autor: Daniel R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
mir ist gerade doch noch mal was eingefallen: Im AVR Studio wird in der
Dialogbox "Program" bei "Flash",
also da, wo man die einzuprogrammierende Datei "einstellen" muss, der
Pfad der Hex-Datei nicht automatisch geändert. Nun kann es sein, dass
der Pfad bei "Flash" noch auf ein Hex-file verweist, welche
vielleicht
ganz was anderes macht, als ne LED an. Mit anderen Worten: Es kann
sein, dass du dem AVR ein uraltes Programm einprogrammierst und es
nicht merkst.
Also, überprüf doch einfach mal den Deteipfad.

Gruß Daniel!

Autor: Hauke Radtki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also der Strom wird vom AVR auf jeden fall auf 20 mA begrenzt
(zumindest, wenn der pin auf 0V liegt), weil sonst wär mein test
controller jetzt schon lange im eimer ... weil zum testen schließe ich
die LEDs immer ohne vorwiderstand an ...

Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Daniel:

Danke für den Tipp mit dem Hex-File, das wars ;) Das kleine
Testprogramm von Peter war das erste, welches LEDs meines STK-500 zum
leuchten brachte...

Also vielen Dank nochmal

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hauke

Wie meinst du das, daß der Strom vom AVR auf 20mA begrenzt wird?

> weil zum testen schließe ich die LEDs immer ohne vorwiderstand an
Eigentlich fatal, oder?

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Also der Strom wird vom AVR auf jeden fall auf 20 mA begrenzt"


Vergiß es !!!

Laut Datenblatt fließen bei 2V Abfall schon 75mA !

Darüber wurde sicherheitshalber gar keine Kennlinie mehr aufgenommen.

Durch die LED fließen also mindestens 75mA (bei 3V an LED), was weder
AVR noch LED besonders mögen (drastisch reduzierte Lebensdauer,
Latch-Up Gefahr).


Peter

Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt lässt sich nur das EEPROM nicht flashen. Gibt´s da irgendwelche
typischen Anfängerfehler? Beim builden wird nicht gemeckert...

Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also es werden 512 (0%) EEPROM-Segment erzeugt. Ich habe jedoch nix im
Eeprom direkt adressiert (zumindest nicht, dass ich wüsste). Habe mir
gerade nochmal einen Haufen Befehle angeschaut und da stand auch nix
davon, dass die das EEPROM verwenden.

Kann mir jemand nen Tipp geben, wofür der EEPROM genutzt werden könnte?
Für Macros wohl nicht, oder? Vielleicht für Konstanten, welche ich z.B.
zum Laden des Zähl-Registers verwende? Liegen die nicht eigentlich im
Datensegment?

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um den EEPROM vorzubelegen, muß man ein extra .eseg erzeugen, nur dann
wird auch ein *.eep file erzeugt, was dann in den EEPROM gebrannt
werden kann.

Der EEPROM wird in der Regel nur zum Speichern von Daten über das
Ausschalten hinweg benutzt.

Dazu muß man aber nicht unbedingt den EEPROM vorbelegen.

Es werden in der Applikation z.B. auf Tastendruck Daten in den EEPROM
gesichert und beim nächsten Einschalten wieder daraus geladen.

Es gibt Bibliotheken dazu oder man macht es laut Datenblatt
(Beispielcode) selber.


Peter


P.S.:
Neue Fragen immer auch als neuen Thread stellen !!!

Autor: Hauke Radtki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm komisch ... (also das der strom nicht begrenzt wird ...) ich kann ja
gleich mal nachmessen, was für nen strom fließt ...

Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter

Danke für die Hinweise... Habe auch gerade festgestellt, dass die
"512" sind die insgesamt zur Verfügung stehende Kapazität sind und
das ich nicht komplett bekloppt bin, sondern das EEPROM gar nicht
genutzt wird.

Ich war nur irritiert, weil ich bereits irgendwie ein (wohl leeres -
wahrscheinlich deshalb nicht flashbares) .eep file erzeugt habe...

Vielen Dank für die "Starthilfe"!

(nächstes Mal auch wieder im passenden Thread ;)

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"hmm komisch"

Das ist nicht komisch, sondern Digitaltechnik (nur 0 und 1).
Man will ja eindeutige Pegel haben und nicht irgendwelche
Zwischenwerte.

Und dazu muß beim Wechsel von 0 auf 1 und umgekehrt die
Schaltungskapazität schön schnell umgeladen werden. Kurzzeitige (wenige
ns) Spitzenströme von über 50mA sind nicht ungewöhnlich, dürfen aber
eben keine Dauerbelastung sein.


Peter

Autor: Eumel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zur "Strombegrenzung"

Es ist einfach eine schlechte Praxis, sich auf nicht spezifizierte
Parameter eines Bausteins zu verlassen bzw. die absoluten elektrischen
Maximalwerte zu nutzen. Das kann bei einer verbesserten Chipversion
dann leicht ins Auge gehen. Wenn in deinem Fall nichts durchbrennt ist
das keine Aussage für andere Bausteinchargen.

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.