Bitte Bitte Bitte helft uns arme Tin26 geschädigte!!

[Marcus Maul (Gast)]

Hallo Leute,

da ich anscheinend nicht in der Lage bin den Code der App307 selbst neu
zu schreiben, ohne das er überhaupt nicht mehr das tut, was ich gerne
möchte - einfach ein paar Daten per USI übertragen.

Wäre jemand von Euch, der IAR Workbench erfahren ist, so lieb und würde
die notwendigen Änderungen machen, damit dieser Code auch unter WinAVR
kompiliert?

http://www.atmel.com/dyn/resources/prod_documents/AVR307.zip

Ich (und einige andere auch) verzweifel langsam.

Danke

Marcus

[Jörg Wunsch (Gast)]

Wenn Du mir 'ne Tüte ATtiny26 schenkst und mich anderweitig daran
interessiert, diese zum Laufen zu bekommen, mache ich das.

Ansonsten mußt Du schon mal mit konkreten Fragen kommen, sorry.

[Jörg Wunsch (Gast)]

Mit dem angehängten Patch bekomme ich es zumindest sauber zum
Compilieren.  Testen kann ich es nur, wenn Du mir den ATtiny26
zukommen läßt...

Im Übrigen, so clever wie der Trick aus den alten BSD fortunes
mit Bit_Reverse() auch für 32 bit oder längere Zahlen ist, für
8 Bits lohnt das überhaupt nicht, was sie da getan haben.

[Jörg Wunsch (Gast)]

Da Atmel ja den generierten Assemblercode beilegt, noch weitere
Bemerkungen:

Die Interruptroutine für den timer 0 overflow ist beim IAR ein wenig
kürzer.  Der GCC merkt nicht, daß er sein _zero_reg_ gar nicht
braucht.  Ggf. also besser durch eine handgefeilte Assemblerroutine
ersetzen -- einfach den Compileroutput in eine Assemblerdatei
schreiben und diese als Quelle einbinden.  Möglicherweise mußt Du
sonst die 0x11 `fudge factor' im INTERRUPT_STARTUP_DELAY korrigieren
(keine Ahnung, was sie damit genau machen, aber ich habe mir die
Appnote selbst nicht durchgelesen).

Wie allerdings der IAR darauf kommt:

        IN      R16,0x32
        SUBI    R16,60
                    ^^
        OUT     0x32,R16

wird mir ein Rätsel bleiben.  Der GCC erzeugt:

        in r24,82-0x20
        subi r24,lo8(-(64))
        out 82-0x20,r24

und das erscheint mir auch korrekt, wenn ich den Makro TIMER0_SEED mit
den voreingestellten Werten mit der Hand nachrechne.

Bezüglich meiner Interpretation, wie sie das mit dem USI_UART_TxData
meinen, dürfte ich aber richtig liegen, wenn ich es gegen deren
Assemblercode vergleiche.

[Marcus Maul (Gast)]

Hallo Jörg,

ich muß mir zwar jetzt mal ganz genau anschauen, was Du da alles
geändert hast, aber es FUNKTIONIERT!!!!

Danke!!!Danke!!!Danke!!!Danke!!!Danke!!!Danke!!!Danke!!!Danke!!!Danke!!! 
Danke!!!Danke!!!Danke!!!Danke!!!Danke!!!Danke!!!Danke!!!Danke!!!Danke!!! 
Danke!!!Danke!!!Danke!!!Danke!!!Danke!!!Danke!!!Danke!!!Danke!!!Danke!!! 
Danke!!!Danke!!!Danke!!!Danke!!!Danke!!!

Marcus

[Marcus Maul (Gast)]

Hallo Jörg,

hier habe ich auch mein Problem gefunden:
register unsigned char USI_UART_TxData asm("r2");

Wieso ist das Register r2?

Ich dachte immer USIDR ist r15?

Jetzt verstehe ich auch, warum ´mein Oziloskop zwar etwas anzeigte, die
Baudrate auch stimmte, aber niemals etwas transferiert wurde und auch
kein Shifting erzeugt wird.Die USI überprüft ob das USIDR auch gefüllt
wurde.

Die Danke Zeiel wurde nicht umgebrochen arg

Marcus

[Dieter B (Gast)]

Hallo

register unsigned char USI_UART_TxData asm("r2");

heißt das nicht, das eine Variable "USI_UART_TxData" bekannt gemacht
wird, und diese vom Compiler fest im Register r2 gehalten werden soll
?

MFG
Dieter

[Jörg Wunsch (Gast)]

Genau das heißt es.  Das IAR-Original hat dafür das Register 15
benutzt (nicht das IO-Register 15!), beim AVR-GCC sollte man aber
besser bei r2 aufwärts anfangen.

Über die Funktion des entsprechenden IAR-Statements gibt der der
Appnote beigelegte Assemblercode (*.s90) hinreichend gut Auskunft. ;-)

[Gerrit (Gast)]

Hallo *,

seit gegrüßt! Auch ich habe Probleme mit der Portierung der Appnote.
Die hier aufgeführten Modifikationen habe ich von Hand eingepflegt.
Aber es funktioniert nicht.
Wenn ich mit einem Terminal-Programm testen möchte, erhalte ich für
jede Eingabe ein 'x' zurück. Was kann das sein?
Ich verwende die aktuellste WinAVR-Release.
Viele Grüße,
Gerrit