Hallo allerseits.
Ich habe mir hier ein kleines Breakout-Board für den attiny10 gebaut und
mit einer LED und einem Taster versehen. Der Taster hängt an PB2, also
dem Pin, an dem auch der INT0 anliegt.
Nun versuche ich, über den INT0 (level) die LED einzuschalten und es tut
nicht, vermutlich fehlt mir noch irgendwas banales in der
Initialisierung. Aber was fehlt?
Assembler-Source und Schaltplan ist angehängt, ich übersetze mit avr-as
2.20.1.20100303.
Für Hilfe wäre ich dankbar, ich stehe auf dem Schlauch.
Viele Grüße,
Simon
meckerziege schrieb:> Der Stackpointer ist nicht anständig initialisiert, daher wird das mit> den Interrupts so nicht klappen.
Guter Tip. Ich habe jetzt folgende neue Defines
#define SPH 0x3E
#define SPL 0x3D
und dann nach dem cli in main:
ldi r16, 0x00
out SPH, r16
ldi r16, 0x5f
out SPL, r16
Hilft allerdings nicht. Laut Datenblatt ist SPH/SPL nach dem Reset auch
mit RAMEND initialisiert - von daher sollte das eigentlich nicht nötig
sein...
Viele Grüße,
Simon
Nachtrag: Habe gerade auch nochmal ohne SPH probiert (existiert laut
Datenblatt eigentlich nicht), hat aber auch nichts geändert.
Ich kenne den Attiny10 nicht, ich weiss nur, dass er ein eigenes
Pullup-Widerstand-Register hat - sbi PUEB, KEY_BIT
Was bewirkt denn der Befehl sbi PORTB, KEY_BIT ?
Zur Sicherheit würde ich noch den Tasten Port als Eingang schalten.
Herr Mueller schrieb:> Ich kenne den Attiny10 nicht, ich weiss nur, dass er ein eigenes> Pullup-Widerstand-Register hat - sbi PUEB, KEY_BIT>> Was bewirkt denn der Befehl sbi PORTB, KEY_BIT ?
Laut der Tabelle auf S. 42 des Datenblatts ist der Wert egal. Das war
einer meiner verzweifelten Versuche das zu verstehen... :)
> Zur Sicherheit würde ich noch den Tasten Port als Eingang schalten.
Habe ich getan, hilft nix...
Viele Grüße,
Simon
Nochmal ein Test - in der Schleife am Ende von main teste ich, ob das
Interrupt-Flag von dem INT0 gesetzt ist und schalte ggf. die LED ein
(siehe Anhang).
Die LED leuchtet nicht, egal wie ich den Taster betätige, das Flag wird
offensichtlich nicht gesetzt.
Grüße,
Simon
Allerdings wird INTF0 in EIFR sofort gelöscht, wenn die Interruptroutine
angesprungen wird. (Seite 38). Sonst sehe ich da keine Fehler. Du
solltest evtl. im Interrupt ein beliebiges Bit eines Registers setzen
und dieses dann in der Hauptschleife abfragen, statt dich auf INTF0 zu
verlassen.
Matthias Sch. schrieb:> Allerdings wird INTF0 in EIFR sofort gelöscht, wenn die Interruptroutine> angesprungen wird. (Seite 38). Sonst sehe ich da keine Fehler. Du> solltest evtl. im Interrupt ein beliebiges Bit eines Registers setzen> und dieses dann in der Hauptschleife abfragen, statt dich auf INTF0 zu> verlassen.
Im Interrupt-Handler werte ich INTF0 nicht aus, sondern schalte die LED
direkt ein. Die INTF0-Geschichte hatte ich nur in der Warteschleife am
Ende von main, falls aus irgendwelchen Gründen der Handler trotz
gesetztem INTF0 nicht aufgerufen würde...
Mann, habe ich evtl. ein Problem mit dem Assembler? Muss ich das jetzt
von Hand disassemblieren? Grgh.
Viele Grüße,
Simon
Simon Budig schrieb:> Mann, habe ich evtl. ein Problem mit dem Assembler? Muss ich das jetzt> von Hand disassemblieren? Grgh.
Ich habe das resultierende Hex- und Bin-File mal angehängt. Könnte das
vielleicht mal jemand mit einer anderen Toolchain disassemblieren?
Danke!
Simon
Simon Budig schrieb:> Mann, habe ich evtl. ein Problem mit dem Assembler? Muss ich das jetzt> von Hand disassemblieren?
Der AVR-GCC dürfte ja auch den AVR-AS verwenden und ersterer war nicht
in der Lage mit dem eingeschränkten Registersatz und der Sonderform von
LDS/STS umzugehen. Da kam dann falscher Opcode raus.
Um den den ATiny10 zu programmieren, hatte das AVR-Studio, ich glaub' es
war das 4er, einwandfrei funktioniert.
Simon Budig schrieb:> Im Interrupt-Handler werte ich INTF0 nicht aus, sondern schalte die LED> direkt ein.
Hatte ich übersehen. Ich habs auch nochmal durch den Simulator 2 von AS
4.19 geschickt und auch da sieht alles gut aus. Ist schon merkwürdig.
Mach doch vor die Hauptschleife nochmal eine kleine LED Blinke um den
Port zu checken, so wie MWS schon vorschlägt.
MWS schrieb:> Sieht ok aus.
Danke fürs gegenchecken.
> Kannst Du die Led überhaupt schalten ?
Ja, definitiv. Allerdings bin ich gerade nicht sicher, ob der Taster
ordentlich funktioniert. Der hat mit dieser Hardware definitiv schon
getan, aber im Moment zuckt da nix.
Ich glaube ich fahre nachher mal in die Firma und baue die Hardware
nochmal auf. seufz.
Erstmal danke fürs Anteilnehmen und mitsuchen.
Viele Grüße,
Simon
Das DB sagt zwar SP wird initialisiert, aber mein funktionierender Code
hatte SPL und SPH, letzteren eben mit 0 gesetzt.
Einen Taster testet man doch ganz einfach, indem man in 'ner Loop
einfach den Tastereingang auf den LED-Ausgang schreibt. Da gibt's dann
auch keine Returns und so ist's dann erstmal egal, ob der SP
initialisiert ist.
Hab hier keinen Tiny10 in Hardware, aber der Simulator 2 behauptet auch,
das SPH/SPL mit 0x005f vorbesetzt wird, so wie es im Datenblatt steht.
Warum SPH beim Tiny10 überhaupt vorhanden ist, ist die andere Frage,
hängt aber vermutlich damit zusammen, das sie bei den neuen Chips nicht
nochmal rumwurschteln wollten, um es aus dem Registersatz zu verbannen.
Nur nochmal zur Sicherheit beim SOT23 Gehäuse:
Pin 1 - PB0 |*- | Pin 6 - PB3/Reset
Pin 2 - GND | | Pin 5 - Vcc
Pin 3 - PB1 | - | Pin 4 - PB2
Matthias Sch. schrieb:> Nur nochmal zur Sicherheit beim SOT23 Gehäuse:> Pin 1 - PB0 |*- | Pin 6 - PB3/Reset> Pin 2 - GND | | Pin 5 - Vcc> Pin 3 - PB1 | - | Pin 4 - PB2
Danke. Ich bin mir inzwischen sehr sicher, dass PB2 bei mir kaputt ist.
Ich habe meinen Code auf den Pin-Change-Interrupt umgebaut (wo es
genausowenig tat) und dann PCINT0 statt PCINT2 gesetzt sowie PB0 mit PB2
(bzw. dem Taster) verbunden.
Und siehe da - plötzlich reagiert die LED.
Ich bau dann mal neue Hardware...
Viele Grüße,
Simon
Simon Budig schrieb:> Ich bau dann mal neue Hardware...
Hat sich gelohnt, es funktioniert jetzt.
Sorry, ich bin erst sehr spät auf die Idee gekommen, dass PB2 schuld ist
- ich hatte den wirklich schon in Aktion gesehen...
Vielen Dank für Eure Mithilfe.
Viele Grüße,
Simon
attiny-breakout.png
(2,6 KB)
