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
Der Stackpointer ist nicht anständig initialisiert, daher wird das mit den Interrupts so nicht klappen.
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.
Sieht ok aus.
1 | +00000000: C00A RJMP PC+0x000B Relative jump |
2 | +00000001: C018 RJMP PC+0x0019 Relative jump |
3 | +00000002: 9518 RETI Interrupt return |
4 | +00000003: 9518 RETI Interrupt return |
5 | +00000004: 9518 RETI Interrupt return |
6 | +00000005: 9518 RETI Interrupt return |
7 | +00000006: 9518 RETI Interrupt return |
8 | +00000007: 9518 RETI Interrupt return |
9 | +00000008: 9518 RETI Interrupt return |
10 | +00000009: 9518 RETI Interrupt return |
11 | +0000000A: 9518 RETI Interrupt return |
12 | +0000000B: E50F LDI R16,0x5F Load immediate |
13 | +0000000C: BF0D OUT 0x3D,R16 Out to I/O location |
14 | +0000000D: 9A09 SBI 0x01,1 Set bit in I/O register |
15 | +0000000E: 9A11 SBI 0x02,1 Set bit in I/O register |
16 | +0000000F: 980A CBI 0x01,2 Clear bit in I/O register |
17 | +00000010: 9A1A SBI 0x03,2 Set bit in I/O register |
18 | +00000011: E001 LDI R16,0x01 Load immediate |
19 | +00000012: BB05 OUT 0x15,R16 Out to I/O location |
20 | +00000013: E001 LDI R16,0x01 Load immediate |
21 | +00000014: BB03 OUT 0x13,R16 Out to I/O location |
22 | +00000015: 9AA0 SBI 0x14,0 Set bit in I/O register |
23 | +00000016: 9478 SEI Global Interrupt Enable |
24 | +00000017: 99A0 SBIC 0x14,0 Skip if bit in I/O register cleared |
25 | +00000018: 9811 CBI 0x02,1 Clear bit in I/O register |
26 | +00000019: CFFD RJMP PC-0x0002 Relative jump |
27 | +0000001A: 9811 CBI 0x02,1 Clear bit in I/O register |
28 | +0000001B: 9518 RETI Interrupt return |
SPL wird übrigens per Initial Value bereits auf RAMEND gesetzt, sagt zumindest das DB. Kannst Du die Led überhaupt schalten ?
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
Bitte 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.