Forum: Mikrocontroller und Digitale Elektronik STM32f0xx UART


von pb (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Leute. Ich bin echt ratlos, desswegen wende ich mich an euch.
Ich habe 2 Boards mit je einem STM32F051K4U6 Kontroller, die ich mit 
RS485 UART verbinden muss.
Ich möchte auf dem einen Input Pins einlesen und auf dem anderen die 
Signale als Output ausgeben.
Als RS485 Anbindung ist je ein MAX-3078 EESA im Einsatz.
Nun hab ich zum Test zwei Firmware, eine zum senden und eine zum 
empfangen.
Diejenige die sendet sollte in Ordnung sein, ich hab am MAX-3078 des 
Empfängerboards das Signal mit dem Oszilloskop messen können.

Aber der Empfänger verarbeitet das Signal nicht weiter.
Hier der Teil bei dem ich nicht sicher bin:
1
  while (1)
2
  {
3
  GPIO_WriteBit(RS485_DIR,Bit_RESET);
4
  
5
  while(USART_GetFlagStatus(USART2, USART_FLAG_RXNE) == RESET)
6
  {}
7
8
9
    
10
if(USART_ReceiveData(USART2) == 'X')
11
        {    
12
          GPIO_WriteBit(Output1,Bit_SET);
13
          GPIO_WriteBit(Output2,Bit_SET);
14
        }
15
    else
16
        {
17
          GPIO_WriteBit(Output1,Bit_RESET);
18
          GPIO_WriteBit(Output2,Bit_RESET);
19
        }  
20
 }
21
}
Die ganzen Firm's im Anhang.
Vielen Danke für Tipps!

von (prx) A. K. (prx)


Lesenswert?

RCC_APB2PeriphClockCmd(RCC_APB1Periph_USART2, ENABLE);
       ^                      ^

von holger (Gast)


Lesenswert?

>RCC_APB2PeriphClockCmd(RCC_APB1Periph_USART2, ENABLE);
>       ^                      ^

Fällt man immer wieder gerne drauf rein;)

Wieso sind die Leute eigentlich inzwischen zu blöd eine

Seriell_Senden_USART.txt

als

Seriell_Senden_USART.c

zu posten?

Scheiss Copy and Paste Kids.

von (prx) A. K. (prx)


Lesenswert?

holger schrieb:
> Fällt man immer wieder gerne drauf rein;)

STM32 Checkliste, Platz 1: die RCC. :)

Nur hat er das auf beiden Seiten falsch, d.h. der Tx müsste genauso tot 
sein. Also wie konnte er was mit dem Oszi messen?

von pb (Gast)


Lesenswert?

Hallo A. K danke für den Tipp hab ich echt übersehen. Nur leider hats 
auch nichts gebracht. Die Messung funktionierte wirklich. Desswegen 
müsste der Fehler doch in der while Schlaufe des EMpfängers sein? Leider 
habe ich das Oszilloskop natürlich nicht zu Hause. Fische also 
regelrecht im trüben. Hab jetzt aber viele Möglichkeiten ausprobiert, 
ohne Erfolg..

von Michael N. (betonmicha)


Lesenswert?

Du hast in beiden Quellcodes den gleichen Fehler:
RCC_APB2PeriphClockCmd(RCC_APB1Periph_USART2, ENABLE);

Du behauptest aber dein Senden würde funktionieren auch mit dem Fehler. 
Das glaube ich aber nicht.
Sind die Frequenzen von beiden Boards richtig eingestellt? Außerdem 
würde ich mit Interrupts arbeiten, damit das Hauptprogramm nicht immer 
blockiert ist.
Was heißt "der Empfänger verarbeitet das Signal nicht weiter"? Beschreib 
doch mal den Fehler genauer.

von (prx) A. K. (prx)


Lesenswert?

Michael N. schrieb:
> würde ich mit Interrupts arbeiten, damit das Hauptprogramm nicht immer
> blockiert ist.

Für den Anfang ist so ein Testcode schon ok. Erst wenn das funktioniert, 
sollte man sich Interrupts widmen.

von Jay (Gast)


Lesenswert?

Hallo,

unter der Annahme, dass dieser Kommentar
//Set USART2 Rx & Tx as AF
stimmt:
Afair muss der RX Pin als Input Float und nicht AlternateFunction 
definiert sein.

CU,
Jay

von Michael N. (betonmicha)


Lesenswert?

A. K. schrieb:
> Für den Anfang ist so ein Testcode schon ok. Erst wenn das funktioniert,
> sollte man sich Interrupts widmen.

Du hast Recht, für den Anfang ist es so besser.

Jay schrieb:
> Afair muss der RX Pin als Input Float und nicht AlternateFunction
> definiert sein.

Alternate Function ist richtig. daran liegt es nicht.


Hast du auch richtig verdrahtet? PA2 an PA3?
Warum probierst du es nicht mir einem Board? einfach einen Jumper auf 
PA2 und PA3 stecken. Dann kannst du schonmal ausschließen das es am Code 
liegt.

Außerdem hab ich eine Vermutung. in deiner system_stm32f0xx.c ist eine 
Frequenz von 25 MHz eingestellt. Dein Board läuft aber mit 8 MHz. Zeig 
mal die Datei.

von (prx) A. K. (prx)


Lesenswert?

Michael N. schrieb:
> Alternate Function ist richtig.

Beim Output ja, aber auch beim Input? Ich habe die F0 Serie grad nicht 
parat, aber bei den F1 gibt es keinen AF Input Modus. Inputs steht immer 
auch als AF zur Verfügung.

: Bearbeitet durch User
von Michael N. (betonmicha)


Lesenswert?

Dann scheint beides zu funktionieren. Ich benutze auf jeden Fall AF beim 
STM32F0 und das geht.
Ich hatte es mal so verstanden, das man Input als reinen Input Pin 
nimmt. Output als Output und AF immer dann wenn spezielle Funktionen 
gewünscht sind, z.B. Usart.

Ist natürlich schwierig, wenn kein AF beim STM32F1 verfügbar ist. Hab 
bisher nur mit F0 und F4 gearbeitet und dort gibts das.

von (prx) A. K. (prx)


Lesenswert?

Michael N. schrieb:
> Ist natürlich schwierig, wenn kein AF beim STM32F1 verfügbar ist.

Wieso? AF-Output gibt es. AF-Input braucht kein Mensch, weil das 
Input-Signal in jedem Fall zum AF-Modul geroutet wird.

von Michael N. (betonmicha)


Lesenswert?

A. K. schrieb:
> Wieso? AF-Output gibt es. AF-Input braucht kein Mensch, weil das
> Input-Signal in jedem Fall zum AF-Modul geroutet wird.

War nur auf den Input bezogen. Dann ist es nur ne Geschmackssache.

von Xenu (Gast)


Lesenswert?

>AF-Input braucht kein Mensch, weil das Input-Signal in jedem Fall zum
>AF-Modul geroutet wird.

Beim STM32F0 stimmt das leider nicht. Du musst den GPIO-Pin auf 
Alternate Function umstellen, auch wenn er Input ist. Ich hab noch nicht 
alles ausprobiert, aber beim USART ist das definitiv so.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.