Hallo,
ich hab das Problem bei einer SPI-Übertragung, dass nach dem Versenden
des ersten Bytes das SPIF-Flag nicht gesetzt wird und somit auch nicht
in die ISR verzweigt wird.
Eigentlich hatte das Programm schon auf einem ATMega 8 problemlos
funktioniert. Ich musste aber aus Speicherplatzgründen auf einen ATMega
168 umsteigen und seit dem nehmen die Probleme keine Ende :-(
Zum Testen habe ich folgendes kleine Testprogramm eingefügt:
1
.ifdef DEBUG_FLAG
2
.cseg
3
; Set SCK, MOSI and SS1 as output, MISO as input, other don't care
Meine Erwartungshaltung ist, dass auf dem SPI zuerst der Wert 0xA5 und
danach der 0x5A ausgegeben wird. Leider sehe ich nur den ersten Wert
(siehe beiliegenden Screenshot vom LA). Offensichtlich wird das
SPIF-Flag nicht gesetzt (der erste braune Trace: nach einem kurzen
Startimpuls werden vom SPSR b7...b0 ausgegeben. Es sitzt nur das SPX
Bit).
Mir ist nicht klar warum ...
Recherchen im Formum haben ergeben, dass der SS-Pin PB2 ist als Ausgang
konfiguriert sein muss. Das solle gegeben sein und der /SS Pin wechselt
auch wie erwartet seinen Wert (Im Bild der rote Trace (A1), ist auf dem
LA aber invertiert dargestellt).
Was übersehe ich ?
Schon mal vielend Dank vorab für die Hilfe.
Viele Grüße,
Anton
Anton Hermann S. schrieb:> ich hab das Problem bei einer SPI-Übertragung, dass nach dem Versenden> des ersten Bytes das SPIF-Flag nicht gesetzt wird und somit auch nicht> in die ISR verzweigt wird.
Das kann nicht sein. Vollkommen unmöglich.
> Eigentlich hatte das Programm schon auf einem ATMega 8 problemlos> funktioniert. Ich musste aber aus Speicherplatzgründen auf einen ATMega> 168 umsteigen
Dann stimmt wohl einfach der Vector nicht.
Also ich weiß ja nicht: für uns unsichtbare Parameter, ebenfalls
unsichtbar die Routine DEBUG_BYTE, und das hier wird garantiert nicht
assembliert:
> out PORTB, 17
Hallo,
das war es !
Der ATMega 8 belegt nur ein Wort pro Vektor, der ATMega 168 aber zwei.
Bei den nicht benötigten Vektoren stand nur RETI. Dieser Befehl belegt
aber nur ein Wort im Interrupt-Vektor. Ein NOP nach jedem RETI hat's
dann gerichtet:
00002e 9518 reti ; 24: ANALOG_COMP Analog Comperator
44
00002f 0000 nop
45
000030 9518 reti ; 25: TWI I2C Serial Interface
46
000031 0000 nop
47
000032 9518 reti ; 26: SPM_RDY Store Program Memory Ready
48
000033 0000 nop
Dass sich das Testprogramm auch merkwürdig verhalten hatte, konnte ich
dann auch nachvollziehen:
Die Interrupts waren aktiv (SEI), was dazu führte dass der Int-Vektor
richtig angesprungen wurde. Dadurch wurde das SPIF-Flag von der Hardware
gelöscht und nach RETI, das dort durch die Verschiebung
fälschlicherweise stand, war es nach der Rückkehr ins Testprogramm beim
Lesen des SPSR natürlich nicht mehr gesetzt.
Besten Dank für den Tipp und noch ein schönes Wochenende !
Viele Grüße,
Anton
Anton Hermann S. schrieb:> Der ATMega 8 belegt nur ein Wort pro Vektor, der ATMega 168 aber zwei.> Bei den nicht benötigten Vektoren stand nur RETI. Dieser Befehl belegt> aber nur ein Wort im Interrupt-Vektor. Ein NOP nach jedem RETI hat's> dann gerichtet:
Naja, eher ein Workaround. Wenn man es richtig und solide machen will,
nimmt man eine Vektortabelle mit den vordefinierten Namen, siehe
m168def.inc. Oder wenigstens die Adressen für die benutzten Vektoren.
Hallo,
A. M. schrieb:> https://ww1.microchip.com/downloads/en/appnotes/doc2554.pdf
Das Dokument beschreibt mein Ungemach hinreichend gut. Mein Pech, es lag
mir leider bisher nicht vor. Ich hatte mich zu sehr auf das erste
Dokument versteift...
S. Landolt schrieb:> unsichtbar die Routine DEBUG_BYTE, und das hier wird garantiert nicht> assembliert:>>> out PORTB, 17
Nur der Vollständigkeit halber: Die Routine DEBUG_BYTE gibt auf einem
freien Pin das übergeben Byte seriell aus (ein Überbleibsel aus dem
ATMega8 als Debug-Hilfe). Vermutlich bin ich beim Übertragen des
Listing-Auszugs auf die Entf - Taste gekommen, weshalb das r vor der 17
fehlte. Assembliert hatte es...
Falk B. schrieb:> Naja, eher ein Workaround. Wenn man es richtig und solide machen will,> nimmt man eine Vektortabelle mit den vordefinierten Namen, siehe> m168def.inc. Oder wenigstens die Adressen für die benutzten Vektoren.
Ich belasse es aktuell noch beim Workaround, der bez. Namen dem
Umschreiben vom ATMega8 auf den 168er geschuldet ist. Wenn mal alles
wieder läuft, gehts ans Aufhübschen...
An der Stelle nochmal Dank an alle für die Hinweise, Tipps und
Unterstützung.
Viele Grüße,
Anton
> beim Übertragen des Listing-Auszugs auf die Entf - Taste gekommen
Auch bei dem für uns unsichtbaren Befehl sei? Denn:
> dann auch nachvollziehen:> Die Interrupts waren aktiv (SEI), was dazu führte ...
Hätte das sei im Programm gestanden, wäre natürlich sofort die Frage
nach den Interruptvektoren plus ISRs gekommen.
Fazit:
Von den Wahrsager-Fähigkeiten eines c-haters abgesehen, ist es schwer,
fundierte Aussagen zu treffen ohne sehen zu können, was beim
Fragesteller realiter vorliegt.