Falsche Baudrate bei UART Kommunikation

Chris_CD

Neues Mitglied
05. Sep. 2007
1
0
0
Sprachen
Hallo,

ich habe einen Mega8 mit dem Quellcode im Anhang beaufschlagt. Wenn ich das Programm ablaufen lasse, soll es Daten mit 9600 Baud über die RS232-Schnittstelle an den PC übertragen. Ich muss allerdings die serielle Schnittstelle am PC mit 1200 Baud konfigurieren, um die Daten zu empfangen. Woran liegt das? Kann mir jemand bei diesem Problem helfen?

Danke

Christian
 

Anhänge

  • Fehlercode_9600_Baud.txt
    2,1 KB · Aufrufe: 30
Hallo Christian,
ich habe einen Mega8 mit dem Quellcode im Anhang beaufschlagt. Wenn ich das Programm ablaufen lasse, soll es Daten mit 9600 Baud über die RS232-Schnittstelle an den PC übertragen. Ich muss allerdings die serielle Schnittstelle am PC mit 1200 Baud konfigurieren, um die Daten zu empfangen. Woran liegt das? Kann mir jemand bei diesem Problem helfen?

ich habe mir deinen angehängten C-Code angesehen, mir sind zwei Dinge aufgefallen.

1) Die beiden Register UBBRH und UCSCR liegen im selben IO-Bereich, man muss eine spezielle Vorgehensweise beim Schreiben und Lesen der Register anwenden:

Schreiben in das Register UBBRH: Das höchstwertige Bit muß 0 sein
Schreiben in das Register UCSCR: Das höchstwertige Bit muß 1 sein

Lesen vom Register UBBRH: funktioniert ganz normal
Lesen vom Register UCSCR: erst UBBRH lesen, dann direkt danach UCSCR lesen (Timing ist wichtig, also auf Interrupts achten, die den Lesezyklus unterbrechen könnten)

2.) Du verwechselst Bits im Register UCSCR:

Code:
UCSRC = (UCSRC | [COLOR=DarkRed][B]0x20[/B][/COLOR]);   // Asynchrone Übertragung - Bit 5
UCSRC = (UCSRC | [B][COLOR=DarkRed]0x10[/COLOR][/B]);   // Even Parity - Bit 4 setzen
[COLOR=DarkRed]// Ich glaube du adressierst mit den oberen Befehlen UPM1 und UPM0 (-> Odd Parity)[/COLOR]
UCSRC = (UCSRC & 0xFB);  // 1 Stop Bit  - Bit 3 löschen
[COLOR=DarkRed]// Du adressierst Bit UCSZ1 nicht USBS (Bit4)[/COLOR]
UCSRC = (UCSRC | 0x03);  // 8 Datenbit  - Bit 1&2 setzen
Ich hoffe, ich konnte dir ein bisschen weiterhelfen.

Gruß
Dirk
 
Problem mit Baudrate

Hallo Christian

sieh dir bitte im Programmer mal das Fusebit CKDIV8 an, ist standardmässig aktiv!!
Bei der Usartprogrammierung bin ich zumindest aus Basic darüber gestolpert, da Basic diesen Internen Teiler bei der Baudrateberechnung nicht berücksichtigt.
Dadurch hatte ich den gleichen Effekt, dass die ausgegebene Baudrate zu gering war.
 
Hallo,

ich programmiere die Megas zwar nicht in C aber ich vermute, dass der Define
Code:
#define F_CPU    14745600
die Taktfrequenz des Megas ist, oder?

Hmmmm, hast Du diesen Quarz exakt an Deinem Mega hängen und stimmen die Fuse-Bits? Läuft der Mega auf externem Takt oder könnte dass das Problem sein.

Grüße,
Markus
 
Hallo,



CodeBox Datenblattausschnitt

==============================================
=== ATmega8 - USART-Register UBRRH + UCSRC ===
=== So steht es im Datenblatt von Atmel ===
==============================================

Ausschnitt aus der "Register Summary" ...

+-------------------+-------+-------+-------+------+------+------+-------+-------+-------+-----+
| Address | Name | Bit 7 | Bit 6 |Bit 5 |Bit 4 |Bit 3 | Bit 2 | Bit 1 | Bit 0 |Page |
+-------------------+-------+-------+-------+------+------+------+-------+-------+-------+-----+
| 0x21 (0x41) | WDTCR | – | – | – | WDCE | WDE | WDP2 | WDP1 | WDP0 | 41 |
+-------------------+-------+-------+-------+------+------+------+-------+-------+-------+-----+
| | UBRRH | URSEL | – | – | – | UBRR[11:8] | 155 |
| 0x20(1) (0x40)(1) +-------+-------+-------+------+------+------+-------+-------+-------+-----+
| | UCSRC | URSEL | UMSEL | UPM1 | UPM0 | USBS | UCSZ1 | UCSZ0 | UCPOL | 153 |
+-------------------+-------+-------+-------+------+------+------+-------+-------+-------+-----+
| 0x1F (0x3F) | EEARH | – | – | – | – | – | – | – | EEAR8 | 18 |
+-------------------+-------+-------+-------+------+------+------+-------+-------+-------+-----+
Notes: 1. Refer to the USART description for details on how to access UBRRH and UCSRC.



Ausschnitt aus der "USART Description" ...

==== Accessing UBRRH/UCSRC Registers ====
The UBRRH Register shares the same I/O location as the UCSRC Register. Therefore
some special consideration must be taken when accessing this I/O location.

-- Write Access --
When doing a write access of this I/O location, the high bit of the value written, the
USART Register Select (URSEL) bit, controls which one of the two registers that will be
written. If URSEL is zero during a write operation, the UBRRH value will be updated. If
URSEL is one, the UCSRC setting will be updated.

-- Read Access --
Doing a read access to the UBRRH or the UCSRC Register is a more complex operation.
However, in most applications, it is rarely necessary to read any of these registers.
The read access is controlled by a timed sequence. Reading the I/O location once
returns the UBRRH Register contents. If the register location was read in previous system
clock cycle, reading the register in the current clock cycle will return the UCSRC
contents. Note that the timed sequence for reading the UCSRC is an atomic operation.
Interrupts must therefore be controlled (e.g., by disabling interrupts globally) during the
read operation.



=== Mit PonyProg ausgelesene Fuse-Bits ===

; ========== ATmega8 ==========
;
; * SUT1 und SUT0 (Zustand=11): Start-up Time 65ms nach Reset,
; Einstellung für Quarzoszillator und langsam ansteigende
; Betriebsspannung (Tabelle 5 des Datenblattes)
; * CKSEL3-CKSEL0 (Zustand=1111): Quarzoszillator im Bereich 3-8MHz
; (Tabelle 4 des Datenblattes)
; * CKOPT (Zustand=1): schneller Quarzoszillator (Tabelle 4 des Datenblattes)
; * BODEN (Zustand=0): Brown-out einschalten
; * BODLEVEL (Zustand=1): Brown-out Schwelle auf 2,7V setzen
;
; Unter Beachtung der invertierten Logik der Fuse-Bits sollte man
; also die Fuses so setzen wie im folgenden Bild:
;
; ( )7 ( )6 [ ]BootLock12 [ ]BootLock11 [ ]BootLock02 [ ]BootLock01 [ ]Lock2 [ ]Lock1
;
; [ ]S8535C [ ]WDTON (X)SPIEN [ ]CKOPT [ ]EESAVE [X]BOOTSZ1 [X]BOOTSZ0 [ ]BOOTRST
;
; [ ]BODLEVEL [X]BODEN [ ]SUT1 [ ]SUT0 [ ]CKSEL3 [ ]CKSEL2 [ ]CKSEL1 [ ]CKSEL0
; ______________________
; | |
; | [X] Bit=0 [ ] Bit=1 | ( ) -> Nicht anwaehlbar [ ] -> Anwaehlbar
; | progr. unprogr. |
; |______________________|
;



ich hab mal die wichtigsten Teile aus dem Datenblatt zusammengesucht ...

Im Gegensatz zum ATtiny2313 ...


CodeBox Datenblattausschnitt

==============================================
=== ATtiny2313 - System Clock + Fuse Bits ===
=== So steht es im Datenblatt von Atmel ===
==============================================

== System Clock and Clock Options ==

-- Default Clock Source --
The device is shipped with CKSEL = “0010”, SUT = “10”, and CKDIV8 programmed.
The default clock source setting is the Internal RC Oscillator with longest start-up time
and an initial system clock prescaling of 8. This default setting ensures that all users can
make their desired clock source setting using an In-System or Parallel programmer.


== Fuse Bits ==

Table 69. Fuse Low Byte
+---------------+--------+-------------------+----------------+
| Fuse Low Byte | Bit No | Description | Default Value |
+---------------+--------+-------------------+----------------+
| CKDIV8 | 7 | Divide clock by 8 | 0 (programmed) |
+---------------+--------+-------------------+----------------+

Das sind meine Erkenntnisse aus den Datenblättern. Demnach besitzt der
ATmega8 KEIN CKDIV8-FuseBit. Beim ATtiny2313 ist es jedoch
vorhanden. Auch die Suche im Datenblatt des ATmega8 ergab keinen
Treffer und es gab nirgends im Datenblatt (2 Versionen durchsucht) einen
Hinweis.

Trotzdem sollte man bei "komischem Programmverhalten" an die Existenz des
Bits denken ;)

Edit: Ich hab das Datenblatt des ATmega32(L) auch mal durchsucht. Kein Hinweis
auf ein CKDIV8. Das hätte ich auch spätestens bei meinen Versuchen mit der
USART und dem ATmega32 gemerkt. Den setz ich auch ein. Ich schätze mal,
das Pollin da in der Beschreibung des Bausatzes einiges vermixt hat. :D
Ich hab auch noch mal die Datenblätter des m8515, m8535, m128 durchsucht. NIX !
Bei den Tinys scheint sie aber wohl bei jedem Prozessor vorhanden zu sein.

Gruß
Dino
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)