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:
>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.
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?
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..
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.
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.
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
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.
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.
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.
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.
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.
>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.
