STM32F4 Discovery UART RS232

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Guten Morgen allerseits!

Bin gerade dabei per USB-VCP Daten (Steuerbefehle) in den µC zu schicken 
und diese von dort aus direkt per UART (RS232) weiter an einen 
Frequenzumrichter. Das Problem ist, dass aus dem UART nicht das 
rauskommt, was rauskommen soll. Einen Pegelwandler habe ich noch nicht, 
für Testzwecke lese ich das TX am UART per USB-Oszilloskop aus. Die 
Oszi-Software kann die Daten direkt entschüsseln und zeigt mir diese an. 
Wenn ich nun beispielsweise mit "USART_SendData(USART2, 220)" 
rausschicke, kommt am Oszilloskop, laut Decoder, eine 163 an.

Ich benutze die SPL von ST und die Crossworks IDE. Folgende 
Einstellungen sind getroffen worden:

Clocks:

*=============================================================================
  *                    Supported STM32F40xxx/41xxx devices
  *-----------------------------------------------------------------------------
  *        System Clock source                    | PLL (HSE)
  *-----------------------------------------------------------------------------
  *        SYSCLK(Hz)                             | 168000000
  *-----------------------------------------------------------------------------
  *        HCLK(Hz)                               | 168000000
  *-----------------------------------------------------------------------------
  *        AHB Prescaler                          | 1
  *-----------------------------------------------------------------------------
  *        APB1 Prescaler                         | 4
  *-----------------------------------------------------------------------------
  *        APB2 Prescaler                         | 2
  *-----------------------------------------------------------------------------
  *        HSE Frequency(Hz)                      | 8000000
  *-----------------------------------------------------------------------------
  *        PLL_M                                  | 8
  *-----------------------------------------------------------------------------
  *        PLL_N                                  | 336
  *-----------------------------------------------------------------------------
  *        PLL_P                                  | 2
  *-----------------------------------------------------------------------------
  *        PLL_Q                                  | 7
  *-----------------------------------------------------------------------------

USART:

USART_InitStruct.USART_BaudRate    = 9600;
    USART_InitStruct.USART_HardwareFlowControl  = USART_HardwareFlowControl_None;
    USART_InitStruct.USART_Mode                 = USART_Mode_Rx | USART_Mode_Tx;
    USART_InitStruct.USART_Parity    = USART_Parity_Even;
    USART_InitStruct.USART_StopBits    = USART_StopBits_1;
    USART_InitStruct.USART_WordLength           = USART_WordLength_8b;
    USART_Init(USART2, &USART_InitStruct);

Der Decoder der Oszi-Software ist folgendermaßen eingestellt:
- Baudrate 9600
- Threshold 1 2V, Threshold 2 2V
- Parity Even
- Protocol Bit Order LSB
- Invert Packet Bits NO (Das hier verstehe ich nicht so ganz)
- Packet Start Edge Falling (Wenn keine Daten übertragen werden, liegen 
3V auf der TX-Leitung an, bei LOW 0V)
- Data Bits 8
- Parity Bits 1
- Stop Bits 1

Vielleicht sieht ja jemand hier schon groben Unfug, den ich angestellt 
habe. Anbei noch ein Bild des Decoders. Mit ihm habe ich schon oft 
RS232-Leitungen dekodiert, also funktionieren tut er auf jeden Fall. 
Vielleicht habe ich nur was in den Einstellungen verbockt?

[Clemens L. (c_l)]

Das Start-Bit ist 0, das Stop-Bit 1.
220 ist binär 00111011 (LSB zuerst).
163 ist binär 11000101.

Anscheined invertiert der Decoder, wo er nicht sollte.

Das letzte Bit stimmt nicht. Ersetzt der STM32 das 8. Bit mit dem 
Parity-Bit, oder sendet er es als 9. Bit?

[m.n. (Gast)]

Man kann natürlich den Text eines ganzen Buches ausgeben und mit einem 
Entschlüsselungsprogramm wieder restaurieren.
Aber warum sendest Du nicht einfach einmal 0x55, 0xaa, ... und siehst 
Dir an, was davon übrig bleibt?

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Clemens L. schrieb:
> Das Start-Bit ist 0, das Stop-Bit 1.
> 220 ist binär 00111011 (LSB zuerst).
> 163 ist binär 11000101.
>
> Anscheined invertiert der Decoder, wo er nicht sollte.
>
> Das letzte Bit stimmt nicht. Ersetzt der STM32 das 8. Bit mit dem
> Parity-Bit, oder sendet er es als 9. Bit?

OK, warum ist das Start-Bit 0 :> Sollte doch eigentlich 1 sein? Nach 
(kurzem) Studium des ReferenceManuals bin ich da auch nicht wirklich 
schlauer geworden. Ich möchte ja StartBit1 | 8Databits + 1Paritybit | 
StopBit1 haben. Müsste ich USART also mit 9Databits definieren 
(USART_WordLength_9b)? So langsam merke ich, dass die Register direkt zu 
beschreiben, manchmal wohl der bessere Weg ist. Vielleicht sollte ich 
mich da doch etwas einarbeiten.

m.n. schrieb:
> Man kann natürlich den Text eines ganzen Buches ausgeben und mit einem
> Entschlüsselungsprogramm wieder restaurieren.
> Aber warum sendest Du nicht einfach einmal 0x55, 0xaa, ... und siehst
> Dir an, was davon übrig bleibt?

Ich sende die "220" ja als decimal, nicht als char.

[guest (Gast)]

Reginald L. schrieb:
> Einen Pegelwandler habe ich noch nicht,

Was erwartet Ihr denn eigentlich? Ist doch alles wie es sein soll. Ohne 
den Pegelwandler sind die Signale nun mal invertiert.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Meine MAX232N sind gerade eingetroffen, ich pflanz die jetzt erst mal 
ein.

[guest (Gast)]

Das der MAX232 invertiert sieht man übrigens auch im durch das Forum 
verlinkten Datenblatt gleich auf der ersten Seite:
"4 Simplified Schematic"
Man beachte die kleinen Kreise an den Symbolen.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

guest schrieb:
> Das der MAX232 invertiert sieht man übrigens auch im durch das Forum
> verlinkten Datenblatt gleich auf der ersten Seite:
> "4 Simplified Schematic"
> Man beachte die kleinen Kreise an den Symbolen.

Aaaaah, OK, laut Theorie müsste am Ende also alles passen. Komisch ist 
nur, dass ich meinen Decoder nicht zum Decodieren von UART bekomme. Es 
gibt dort ja die Option für UART. Naja, da arbeite ich mich rein, wenn 
ichs dann benötige.

Vielen Dank an alle!

[guest (Gast)]

Grad erst gesehen: "Invert Packet Bits NO"
Ich kenne Dein Oszi nicht, aber Du könntest versuchen, das mal auf YES 
zu setzen.

Hier im Forum gibt es auch einen Artikel zu RS232:
http://www.mikrocontroller.net/articles/RS-232
Der liefert dann z.B. auch die Erklärung, was es mit der "Invertierung" 
auf sich hat:

RS-232 arbeitet mit Signalpegeln im Bereich
von +3 ... +15 V zur Darstellung einer logischen 0 (SPACE)
und -3 ... -15 V zur Darstellung einer logischen 1 (MARK).

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Das habe ich auch schon versucht. Ich belasse es jetzt dabei, wenn ich 
mich an allem aufhalten würde, was ich nicht verstehe, dann wäre ich nur 
am Lesen ;) Irgendwo muss man eben auch mal ins kalte Wasser.

Wo wir gerade bei RS232 sind, im Datenblatt des MAX232 steht, man solle 
Tantals oder Kerkos für die Pumpe nehmen. Ist es ein "spürbarer" 
unterschied im Gegensatz zu "normalen Standard-Alu-Elkos"? Habe hier eh 
schon eine Ladungspumpe am Laufen, allerdings mit Alu-Elkos. Bin jetzt 
nicht sonderlich zufrieden, da ich auf der -5V Leitung einen Ripple von 
etwa 100mV habe. Allerdings "rippled" er mir eher nach oben.

Frage deshalb, da ich gerade nur Alu-Elkos bzw nur Kerkos bis 0.1µF da 
habe.

[Reginald L. (Firma: HEGRO GmbH) (reggie)]

Also, es funktioniert (fast) alles wie es soll. Hat es vorher auch 
schon. Was nicht funktioniert hat, war die PicoScope Software die ich 
als Decoder benutzt habe. Warum, weiß ich jetzt auch nicht... Wie 
gesagt, wenns notwendig wird, arbeite ich mich da rein :)

Was mich allerdings wundert, wo ist das ParityBit?! Ich sehe nur das 
Startbit, 8Datenbits und das Stoppbit.

EDIT: OK, ich glaube ich checks jetzt: Startbit ist logisch 0, also 
RS232 Leitung auf +. Stoppbit logisch 1, Leitung -. Ich nehme dann mal 
an, "low" heißt in dem Fall auf -, also logisch 1? Boah, da kommste 
durcheinander :>