Ich habe ein Beispielprogramm aus dem Tutorial zum Laufen gebracht,
welches über die serielle Schnittstelle liest und zurücksendet.
Funktionierte einwandfrei und auf Anhieb.
Mich wundert bloß, dass im Original Programm das UCSRC Bit für die
Wortlänge nicht gesetzt wird, und es trotzdem mit 8Bit Wortlänge
funktioniert. Müsste ich nicht explizit setzen:
UCSRC = (1<<URSEL)|(1 << UCSZ1)|(1 << UCSZ0); // Asynchron 8N1
Egal ob ich diese beiden Bits setze, es funktioniert einfach immer
richtig. Wieso, wenn doch die Wortlänge 5 Bits sein sollte, wenn die
Bits auf 0 stehen ... grübel
Kann mich da jemand aufklären?
Danke!
AVR Anfänger schrieb im Beitrag #3146732:
> Ich habe ein Beispielprogramm aus dem Tutorial zum Laufen gebracht,> welches über die serielle Schnittstelle liest und zurücksendet.>> Funktionierte einwandfrei und auf Anhieb.>> Mich wundert bloß, dass im Original Programm das UCSRC Bit für die> Wortlänge nicht gesetzt wird, und es trotzdem mit 8Bit Wortlänge> funktioniert. Müsste ich nicht explizit setzen:
Hol dir das Datenblatt und sieh nach welches die Standardeinstellung
nach einem Reset ist. :-)
> richtig. Wieso, wenn doch die Wortlänge 5 Bits sein sollte, wenn die> Bits auf 0 stehen ... *grübel*
Tun sie das? Stehen die nach einem Reset wirklich auf 0? Hast du das im
Datenblatt nachgesehen, oder nimmst du es nur an?
>Wieso, wenn doch die Wortlänge 5 Bits sein sollte, wenn die>Bits auf 0 stehen ... grübel
Die stehen nach Reset auf 1 und nicht auf 0.
Steht auch im Datenblatt.
Karl Heinz Buchegger schrieb:> Tun sie das? Stehen die nach einem Reset wirklich auf 0? Hast du das im> Datenblatt nachgesehen, oder nimmst du es nur an?
Aha, ... danke für den Tip!
also ich ging davon aus, dass sie nicht gesetzt sind, da in meinem AVR
Studio auf der rechten Seite eine IO View ist, wo alle Bits des UCSRC
auf Null stehen. Wird diese Info womöglich nicht aktualisiert?
Aus dem AVR Manual:
With the I/O view the user can display and edit all the peripheral and
I/O memory values in debug stop mode. All values are updated in the
display when a break occurs, and changed values for visible items are
painted with a red color.
Und genau nach einem Break, steht das Register UCSRC auf 0x00
Wieso, wenn es doch auf einem Default <> 0 stehen sollte?
AVR Anfänger schrieb im Beitrag #3146752:
> Und genau nach einem Break, steht das Register UCSRC auf 0x00
Der Simulator hat so manchen Fehler.
Da allerdings der Simulator sowieso keine funktionierende UART aufbauen
kann, ist das dort auch ziemlich egal.
Deine Bibel heißt "Datenblatt". Das ist die einzige wahre Autorität mit
der Befugnis Streitfragen zu klären.
Karl Heinz Buchegger schrieb:> AVR Anfänger schrieb im Beitrag #3146752:>>> Und genau nach einem Break, steht das Register UCSRC auf 0x00>> Der Simulator hat so manchen Fehler.> Da allerdings der Simulator sowieso keine funktionierende UART aufbauen> kann, ist das dort auch ziemlich egal.>> Deine Bibel heißt "Datenblatt". Das ist die einzige wahre Autorität mit> der Befugnis Streitfragen zu klären.
Ich hab's nun zwar verstanden, aber ich habe eigentlich geglaubt, dass
mir die IO Anzeige im AVR Studio nach einem Break die aktuellen
Registerinhalte anzeigt- und zwar die echten vom Controller, nicht die
simulierten...ist diese Annahme falsch und es ist alles nur eine
Simulation?
AVR Anfänger schrieb im Beitrag #3146773:
> Karl Heinz Buchegger schrieb:>> AVR Anfänger schrieb im Beitrag #3146752:>>>>> Und genau nach einem Break, steht das Register UCSRC auf 0x00>>>> Der Simulator hat so manchen Fehler.>> Da allerdings der Simulator sowieso keine funktionierende UART aufbauen>> kann, ist das dort auch ziemlich egal.>>>> Deine Bibel heißt "Datenblatt". Das ist die einzige wahre Autorität mit>> der Befugnis Streitfragen zu klären.>> Ich hab's nun zwar verstanden, aber ich habe eigentlich geglaubt, dass> mir die IO Anzeige im AVR Studio nach einem Break die aktuellen> Registerinhalte anzeigt- und zwar die echten vom Controller, nicht die> simulierten...
moment - welche Hardware verwendest du?
Kann die das überhaupt, den µC im Einzelschrittbetrieb durchzusteppen
(bzw. auf einen Breakpoint auflaufen zu lassen) und Registerinhalte
direkt vom µC auslesen?
Karl Heinz Buchegger schrieb:> moment - welche Hardware verwendest du?> Kann die das überhaupt, den µC im Einzelschrittbetrieb durchzusteppen> (bzw. auf einen Breakpoint auflaufen zu lassen) und Registerinhalte> direkt vom µC auslesen?
Ich habe einen JTAG ICE von Olimex. Ich weiß, dass der nicht das Gelbe
vom Ei sein soll, aber es hat alles noch funktioniert (Debuggen,
Einzelschritt, Breaks, bis auf diese kleine Unstimmigkeit halt).
Man sieht anhand des Snapshots (zum Zeitpunkt steht das Programm am
gelben Pfeil), dass zwar das UCSRB aktualisiert wird, jedoch UCSRC auf
Null steht, obwohl ich zwei Bits gesetzt habe. Hier stimmt tatsächlich
etwas nicht mit der Anzeige der Bits...
Stefan Ernst schrieb:> Schreibe mal was anderes nach UBRRH als 0. Dann wirst du wohl auch> gesetzte Bits in UCSRC sehen. Und dann denk mal darüber nach, warum das> so ist.
Ach, da wird ein Register geteilt. UBRRH und UCSRC sind gleich, und
müssen über spezielle Kunstgriffe unterschieden werden... Wozu macht man
denn sowas? Das sind -zig Register in dem Ding drin, und dann kommt es
auf eines an?
Grüße, Michael
Hi
>Wozu macht man>denn sowas? Das sind -zig Register in dem Ding drin, und dann kommt es>auf eines an?
Ja. Mit den IO-Befehlen 'in/out' (1 Byte-Befehle) können nur 64
IO-Register angesprochen werden. Und der Bereich ist beim ATMega32
(über)voll. Neuere AVRs haben zusätzlich Extended I/O-Register die dann
wie RAM behandelt werden. Die dazu notwendigen Befehle 'lds/sts' sind
aber dann 2-Byte-Befehle.
MfG Spess
