Danke erstmal für eure Beteiligung! :D
Adam P. schrieb:
> Das kann, muss aber nicht funktionieren.
> Wenn hinter deinem String nicht zufällig eine \0 ist, dann sendet er
> munter weiter.
Das stimmt, ist mir bisher so aber noch nie passiert. Soweit ich weis
schließt ein String in C immer mit \0 ab? Selbst wenn schon, dann wäre
es nicht schlimm, wichtig ist dass ich überhaupt erstmal was aus dem
UART raus bekomme. Sonst begrenze ich ebend fix den Index.
Peter S schrieb:
> Hilfe sieht irgendwie anders aus.
Haha, danke dafür! :D sowas wollte ich auch schon schreiben :D
Adam P. schrieb:
> Geht es auch ein wenig genauer?
Also der C-Code selbst lässt sich kompilieren, und auf den Controller
laden. Allerdings weigert sich der UART am Pin SERCOM0 PAD[2] (PA04 bzw
Pin 3 am QFN Gehäuse => vgl. S.13)auch nur irgendwas auszugeben.
Bisher habe ich nur avr programmiert. Um den UART dort anzuschmeißen
brauchte man nur die Entsprechenden EN Bits im UART Register zu setzen
und die Baudrate einzustellen.
Ich habe den UART-Abschnitt im SAM Datenblatt mal überflogen und alle
Bits so gesetzt wie es mir sinnvoll erschien. Im Quellcode habe ich das
entsprechend kommentiert.
Aber es geht wie gesagt nicht. Weder meine UART-USB Brücke, noch das
Oszi zeigen ein Signal am Tx-Pin. Ich denke ich habe nur ein Bit
übersehen. Vielleicht ist es hier manchmal auch wichtig in welcher
Reihenfolge Bits gesetzt werden. Hat SERCOM keinen Takt bringt Bits
setzen natürlich auch nichts. Deshalb habe ich gleich oben in der
init_usart()
'REG_PM_APBCMASK|=(1<<2);//Enable Clock for SERCOM0 (S.136/137)'
gesetzt.
Vielleicht habe ich auch einen Fehler in der BAUD-Register Rechnung und
der Taktgenerator will nicht arbeiten. Ich weis es nicht.