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...
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.
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?
die LED am AVR natürlich ohne Vorwiderstand (da sollten doch 20mA oder so rauskommen?) um Mißverständnissen soweit wie möglich vorzubeugen...
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
halt... Freudscher Verschreiber .. Ausgänge auf 1, Eingänge auf 0 .. so
Hast du ja auch, wie ich gerade feststelle. Dann kann ich dir auch nicht helfen, ausser mit meinem Code.
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 !
ach so dann tausche ich mal den AVR u9nd probier das nochmal mit Widerstand. Wieviel Ohm sollte der denn haben?
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
bei 5V kannst du bedenkenlos einen 220 Ohm Widerstand nehmen .. alles nahe daran ist auch ok. so zw. 150 und 330 Ohm sollte gehen.
@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...
Na dann muß ich mich wohl mal direkt an Atmel wenden... Komische Sache jedenfalls.
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!
Hallo "Alisa 1387" schreib mal wie deine Datei genau heisst Gruss Kurt
Moin, stelle doch 'mal das Hexfile das du in den Prozessor lädst, dann probiere ich das 'mal zu Hause aus.
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
Jetzt lässt sich nur das EEPROM nicht flashen. Gibt´s da irgendwelche typischen Anfängerfehler? Beim builden wird nicht gemeckert...
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 !!!
hmm komisch ... (also das der strom nicht begrenzt wird ...) ich kann ja gleich mal nachmessen, was für nen strom fließt ...
@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.
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.