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...
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?
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
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.
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 !
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
@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.
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 ..
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)
@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...
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!
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!
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 ...
@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
@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?
"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
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?
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 !!!
@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 ;)
"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
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.
