Hallo, vorweg sei gesagt: Bin absoluter Anfaenger. Habe zwar schonmal etwas mit Assembler herumgespielt, allerdings versagen hier meine Kenntnisse. Gleichzeitig vermute ich das Problem auch eher irgendwo im elektronischen Bereich. Anyway, ich beschreib 'mal worum es geht: Besitze ein STK500 mit einem AT90S8515. Eigentlich geht es mir nur darum, alle (!) der 8 LEDs (LED0-LED7) anzusteuern. Nichts schwieriges, sollte man meinen. Nungut, ich habe also mein Nullmodemkabel angeschlossen, und eine Verbindung zwischen den PBX-Registern (ist Register der korrekte Begriff) und den Anschluessen fuer die LEDs auf dem Board hergestellt. (Sorry fuer die moeglicherweise falsche Ausdrucksweise, ich hoffe ihr wisst, was ich meine). Zum besseren Verstaendnis habe ich den Aufbau nochmal als Bild hochgeladen: http://www.flickr.com/photos/66358509@N00/59076167/ Habe aus einem Gespraech mit mehreren Leuten im IRC gestern Nacht folgenden, aus dem Tutorial abgewandelten, Source kreiert. Nach den Angaben im IRC sollten hiermit alle acht LEDs leuchten: --snip-- .include "8515def.inc" ;Definitionsdatei einbinden, ggf. durch ;2333def.inc ersetzen ldi r16,0xFF ;0xFF ins Arbeitsregister r16 laden out DDRB, r16 ;Inhalt von r16 ins IO-Register DDRB ausgeben ; ldi r16, 0b11111100 ;0b11111100 in r16 laden ldi r16,0b01010101 out PORTB, r16 ;r16 ins IO-Register PORTB ausgeben ende: rjmp ende ;Sprung zur Marke "ende" -> Endlosschleife --snap-- Kommentare bitte ignorieren, ist einfach aus dem Tutorial uebernommen und nicht abgeaendert. Ebenfalls habe ich mir den Sourcecode aus dem AVR-ASM-Tutorial aus der Linksammlung geschnappt: http://www.avr-asm-tutorial.net/avr_de/quellen/test1.asm Leider leuchten auch mit diesem Source nicht alle Lampen; ebenfalls blinken sie nicht. Stattdessen ist, wie auf dem Foto zu sehen, konstant LED1 an. Ich versteh das nicht .. Ich hab derzeit absolut keinen Ansatzpunkt, warum das nicht funktioniert. Als ich das Multimeter an die LED PBX Ports angelegt habe, kamen auch einige interessante Werte raus. Waehrend PB0 gute 5V (schaetze so etwa 5,4V) liefert, liefern alle anderen PBs nur knapp unter 5V (etwa 4,5V) (sorry, habe nur ein analoges Multimeter, wo man das net so ganz gescheit ablesen kann). Mag sein, dass ich das falsch sehe, aber sollten die LEDs nicht trotzdem zumindest ansatzweise (schwach) leuchten? Irgendwelche Ansatzpunkte, wo ich nun fortsetzen koennte, wo ich nach (Denk-)fehlern suchen koennte? Vielen Dank im Voraus und Entschuldigung fuer die vermutlich daemliche Frage, phil
Gast
#256974
ldi r16,0
Gast
#256975
Phil, ldi r16,0xFF ;0xFF ins Arbeitsregister r16 laden out DDRB, r16 stellt die Datenrichtung von Port B so ein, dass alle pins Ausgaenge sind. ldi r16,0b01010101 out PORTB, r16 schreibt nun auf Port B das Bitmuster 01010101. Damit werden jede zweite LED eingeschaltet, die anderen bleiben ausgesschaltet. Mit ende: rjmp ende schickst du den uC in die Endlosschleife, er macht also NIX mehr ausser Strom zu verbrauchen. Das heisst, nachdem der Prozessor einmal Port B initialisiert hat tut er nix mehr. Damit die LEDs blinken muss er aber ein Schleife abarbeiten und sie abwechselnd an- und ausschalten. Nix für Ungut, ich empfehle dir, erstmal die Grundlagen des Programmierens zu erlernen, dann dich mit dem AVR Assembler (Tutorial gibts hier und bei Atmel) zu befassen und dann mit den Details der uC hardware. Daz
Gast
#256976
Hi, Wenn Dein Link-Bild tatsächlich Dein Aufbau zeigt, ist klar, warum nur eine Led leuchtet. Du hast das Kabel zu den Leds verdreht. Die rote Markierung am Kabel sollte immer an Pin 1 sein ( an beiden Seiten). Bitte überprüfen. Das Programm ist so schon ok, ausser dass es nicht blinkt. Beim Blinken auf jeden Fall an Zeitverzögerung denken, sonst sieht man nix. Gruss Christian
Gast
#256977
Hier ein einfaches Blinkprogramm mit einer Pause .include "8515def.inc" ldi r16,$ff out ddrb,r16 main: ldi r16,$00 out portb,r16 pause1: inc r17 brne pause1 inc r18 brne pause1 inc r19 cpi r19,$70 brne pause1 clr r19 ldi r16,$ff out portb,r16 pause2: inc r17 brne pause2 inc r18 brne pause2 inc r19 cpi r19,$70 brne pause2 clr r19 rjmp main
Wie eben auch im IRC festgestellt, habe ich die Kabel nun vertauscht. Anscheinend nun korrekt: http://img120.imageshack.us/img120/2280/cimg36890pv.jpg Jetzt leuchtet allerdings nichts mehr.
Mit Florians Programm passiert leider das gleiche. Naemlich nichts. :(
Gast
#256980
Es kann natürlich sein, dass der 8515 nicht mehr funktioniert, da Du wohl laengere Zeit die Ports mit Vcc und GND kurzgeschlossen hast.
Gast
#256981
Ich kenne das stk 500 leider nicht und daher weiß ich auch nicht, auf welchem Port die Leds angeschlossen sind.... probiere mal anstatt portb -->porta und anstatt ddrb --> ddra einfach im code umändern.. kann aber auch portc und ddrc oder portd und ddrd sein... Keine Ahnung... Gruß Florian
Hat leider auch keine Aenderung gebracht. :-(
Gast
#256983
Wie spielst du denn das Programm rüber? Mit dem PonyProg? Oder hat da Atmel etwas eigenes?
Mit dem AVRstudio ("Program FLASH").
Gast
#256985
Steht bei den Leds nichts aufgedruckt? z.B.: PB0 PB1?
Gast
#256986
ups... Port B...habs gerade gesehen
Gast
#256987
@Florian Beim STK500 sind alle Ports auf Pfostenstecker gelegt und werden dann je nach Bedarf mit dem LED-Stecker verbunden. Da aber wohl längere Zeit das Kabel verdreht war, lag in der Zeit an PB0 +5V und an PB1 Masse (Led leuchtete). Wenn PB0 als Ausgang auf 0 lag, gab es wohl einen längeren Kurzschluss. Es waere möglich, dass das der Prozessor nicht mochte.
Gast
#256988
ok, dann ab mit ihm in den µ-controller Himmel, :-) Ein letztes Gebet noch... und tschüss
Problem geloest. Danke an alle hier und an alle Leute im IRC, im speziellen c-logic. :) Lag einmal daran, dass das Kabel zum ISP nicht/falsch aufgesetzt war, und dass ich die diesbezuegliche Einstellung im AVRstudio falsch gesetzt hatte.
Gast
#256990
Dann hast Du tatsächlich Glück gehabt, dass das Programm mit falsch aufgestecktem Portkabel nicht geladen wurde und der Port nicht auf Ausgang ging. Viel Spass beim weiteren Testen christian
Gast
#256991
Ja, Glück im Unglück....
Ist zwar OT, aber vielleicht hilft es ja etwas: http://www.mikrocontroller.net/forum/read-1-38592.html#250868 Bit- & Bytebruch... ...HanneS...
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.