HAL_UART_TxCpltCallback

[joule (Gast)]

Guten Tag,
ich versuche gerade in einem STM32F1 eine Software Änderung zu machen.
Ich habe bis jetzt ATmels programmiert.
Da Projekt wurde mit CubeMx und Atolic begonnen.
Ich versuche gerade den  HAL_UART_TxCplt Interrupt einzubauen.
Wenn ich was über die Uart Sende bekomme ich auch die 
HAL_UART_TxCpltCallback angesprungen.
Aber irgendwie sind die Daten noch nicht alle gesendet.
verstehe ich den Interrupt  HAL_UART_TxCpltCallback falsch?
Wird dieser nicht ausgelöst wenn alle Zeichen gesendet sind?
Ich muss damit den RS485 Treiber auf Empfang umschalten.
Das senden wurde mit HAL_UART_Transmit_IT()realisiert.


Danke für die Hilfe

[Harry L. (mysth)]

Der Callback wird aufgerufen, sobald das letzte Zeichen an den UART 
übergeben wurde.
Das eigentliche Senden dieses Zeichen dauert dann (je nach Baudrate) 
natürlich noch ein gewisse Zeit.

[joule (Gast)]

Harry L. schrieb:
> Der Callback wird aufgerufen, sobald das letzte Zeichen an den
> UART
> übergeben wurde.
> Das eigentliche Senden dieses Zeichen dauert dann (je nach Baudrate)
> natürlich noch ein gewisse Zeit.

Das ist aber bei Atmel anders da wird der Interrupt ausgelöst wenn es 
komplett gesendet wurde.
Wie steuert man dann beim STM32 Den Treiber für die 4845?

[Gerd E. (robberknight)]

joule schrieb:
> ich versuche gerade in einem STM32F1
[...]
> Ich muss damit den RS485 Treiber auf Empfang umschalten.

Nimm das nächste mal einen neueren STM32, die haben ein Driver Enable 
für genau diesen Zweck in Hardware. Z.B. STM32F072.

Die STM32F1 waren die ersten STM32er überhaupt, Release war 2007. Das 
Design hat also jetzt schon über 12 Jahre auf dem Buckel.

[joule (Gast)]

Gerd E. schrieb:
> Nimm das nächste mal einen neueren STM32, die haben ein Driver Enable
> für genau diesen Zweck in Hardware. Z.B. STM32F072.
>
> Die STM32F1 waren die ersten STM32er überhaupt, Release war 2007. Das
> Design hat also jetzt schon über 12 Jahre auf dem Buckel.

Ich habe das Projekt so übernommen die Hardware ist bestand.

[STK500-BEsitzer (Gast)]

Einfach mal hier nachlesen:

https://www.st.com/content/ccc/resource/technical/document/user_manual/72/52/cc/53/05/e3/4c/98/DM00154093.pdf/files/DM00154093.pdf/jcr:content/translations/en.DM00154093.pdf

joule schrieb:
> Das ist aber bei Atmel anders da wird der Interrupt ausgelöst wenn es
> komplett gesendet wurde.

HAL bedeutet Hardware Abstraction Layer.
Es ist eine Library, die einem das Konfigurieren und Register-Gehampel 
der Schnittstellen abnimmt.

Das USART der STM32 bietet eigentlich die gleichen Interrupts wie der 
AVR.
Die Callbacks wären die ISR dazu.

[joule (Gast)]

STK500-BEsitzer schrieb:
> HAL bedeutet Hardware Abstraction Layer.
> Es ist eine Library, die einem das Konfigurieren und Register-Gehampel
> der Schnittstellen abnimmt.
>
> Das USART der STM32 bietet eigentlich die gleichen Interrupts wie der
> AVR.
> Die Callbacks wären die ISR dazu.

Danke für das Dokoment. Ich habe aus diesen Dokument die
void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) entnommen.

void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart)
{
  if (huart == &huart2)
  {
    printf("HAL_UART_TxCpltCallback\n");  // Ausgabe über die SWO
    
  }
}

[Stefan (Gast)]

Ist jetzt Dein Problem damit eigentlich gelöst?
Denn die Funktion 'HAL_UART_TxCpltCallback' kanntest Du doch schon zu 
Beginnn des Threads.

Das Problem war ja, dass diese Funktion aus Deiner Sicht nicht das 
macht, was Du erwartest hast (nämlich erst aufgerufen zu werden, wenn 
das letzte Zeichen tatsächlich gesendet wurde, und nicht bereits, wenn 
es an den UART übergeben wurde).

[hfhd (Gast)]

wann kommt die meldung TxClpt

wieviele bytes sendest du mit HAL_UART_Transmit_IT() ?


es fehlt an code und informationen

[W.S. (Gast)]

joule schrieb:
> Da Projekt wurde mit CubeMx und Atolic begonnen.
> Ich versuche gerade den  HAL_UART_TxCplt Interrupt einzubauen.

Warum nur läßt du dich auf diesen Krampf ein? Dein Problem ist 
offensichtlich NICHT der konkrete Chip und sein Verhalten, sondern das 
Verhalten dieses Bibliotheks-Zeugs von ST, wo man sich erstmal durch 
dessen Quellcode durchwühlen muß, um herauszukriegen, was da eigentlich 
so abgeht.

Lies lieber dort mal:
Beitrag "STM32 USART mit falscher Baudrate"
Dort hatte ich damals das gepostet:
https://www.mikrocontroller.net/attachment/316790/STM32F103C8T6.ZIP
Das sollte eigentlich ausreichen, um dir zu zeigen, wie man mit den 
UART's bei den STM32F1xx umgeht - OHNE Cube und Konsorten. Und das 
angenehme ist, daß es tatsächlich funktioniert. Ohne Callback-Funktionen 
und anderes Zeugs, was das Leben bloß kompliziert macht. Und mit nur 
wenigen Änderungen funktioniert das dann auch bei den STM32F3xx und 
höher.

Mein dringender Rat: Löse dich von Cube und Konsorten und bahne dir 
deinen eigenen Weg. Das mag am Anfang etwas mühsamer sein, weil man 
tatsächlich die diversen Manuals lesen und verstehen muß, aber dafür hat 
man eben Lowlevel-Treiber, die schlicht und einfach funktionieren und 
ein verständliches Interface bieten.

Je mehr man selber an solchen Treibern im eigenen Portfolio hat, desto 
einfacher wird es mit der Zeit, ein neues Projekt selber aufzustellen 
und durchzuziehen.

W.S.

[pegel (Gast)]

W.S. schrieb:
> Mein dringender Rat:

Es geht nicht ohne, oder?