STM32 UART HAL

[Studi (Gast)]

Heyho,

Ich versuche einen Chararray über UART an mein HTerm zu senden. 
Außerhalb der while schleife funktioniert es auch, in der while schleife 
scheint der UART bei dem senden fest zu stecken. Um genau zu sein bei

HAL_StatusTypeDef UART_WaitOnFlagUntilTimeout(UART_HandleTypeDef *huart, uint32_t Flag, FlagStatus Status, uint32_t Tickstart, uint32_t Timeout)
{
  /* Wait until flag is set */
  while((__HAL_UART_GET_FLAG(huart, Flag) ? SET : RESET) == Status)
  {
    /* Check for the Timeout */
    if(Timeout != HAL_MAX_DELAY)
    {
      if((Timeout == 0U) || ((HAL_GetTick()-Tickstart) > Timeout))
      {
        /* Disable TXE, RXNE, PE and ERR (Frame error, noise error, overrun error) interrupts for the interrupt process */
        CLEAR_BIT(huart->Instance->CR1, (USART_CR1_RXNEIE | USART_CR1_PEIE | USART_CR1_TXEIE));
        CLEAR_BIT(huart->Instance->CR3, USART_CR3_EIE);

        huart->gState  = HAL_UART_STATE_READY;
        huart->RxState = HAL_UART_STATE_READY;

        /* Process Unlocked */
        __HAL_UNLOCK(huart);
        return HAL_TIMEOUT;
      }
    }
  }
  return HAL_OK;
}

Sitze seit ein paar Tagen an dem Problem. Weis nicht mehr weiter. Wieso 
wird kein Flag gesetzt?

[Studi (Gast)]

Meine Einstellungen für den USART2:

UART_HandleTypeDef huart2;

void MX_USART2_UART_Init(void)
{
  huart2.Instance = USART2;
  huart2.Init.BaudRate = 9600;
  huart2.Init.WordLength = UART_WORDLENGTH_7B;
  huart2.Init.StopBits = UART_STOPBITS_1;
  huart2.Init.Parity = UART_PARITY_NONE;
  huart2.Init.Mode = UART_MODE_TX_RX;
  huart2.Init.HwFlowCtl = UART_HWCONTROL_NONE;
  huart2.Init.OverSampling = UART_OVERSAMPLING_16;
  HAL_UART_Init(&huart2);


}

Meine while schleife:

while(1)
  {
     scale(i);
     HAL_UART_Transmit(&huart2, (uint8_t*)buffer, strlen(buffer), HAL_MAX_DELAY);
     HAL_Delay(1000);
  }

Anscheinend wir das UART_FLAG_TXE nicht auf Reset gesetzt. Genau da 
hänge ich in der obrigen Schleife fest.

HAL_StatusTypeDef HAL_UART_Transmit(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout)
{
  uint16_t* tmp;
  uint32_t tickstart = 0U;

  /* Check that a Tx process is not already ongoing */
  if(huart->gState == HAL_UART_STATE_READY)
  {
    if((pData == NULL ) || (Size == 0U))
    {
      return  HAL_ERROR;
    }

    /* Process Locked */
    __HAL_LOCK(huart);

    huart->ErrorCode = HAL_UART_ERROR_NONE;
    huart->gState = HAL_UART_STATE_BUSY_TX;

    /* Init tickstart for timeout managment*/
    tickstart = HAL_GetTick();

    huart->TxXferSize = Size;
    huart->TxXferCount = Size;
    while(huart->TxXferCount > 0U)
    {
      huart->TxXferCount--;
      
      if(UART_WaitOnFlagUntilTimeout(huart, UART_FLAG_TXE, RESET, tickstart, Timeout) != HAL_OK)
      {
        return HAL_TIMEOUT;
      }

Außerhalb der while Schleife kann ich mit dem Befehl Transmit Daten 
schicken. Habe bis jetzt auch nichts auf Google gefunden.

[W.S. (Gast)]

Studi schrieb:
> Heyho,

Alo-Ahe, Freddy.


Studi schrieb:
> Sitze seit ein paar Tagen an dem Problem. Weis nicht mehr weiter.

Also, wenn du weiter so mit diesem Zeugs:

while((__HAL_UART_GET_FLAG(huart, Flag) ? SET : RESET) == Status)

herummurkst, dann wirst du auch noch weitere Tage am Problem sitzen und 
weiterhin nicht weis sein.

Ich hatte hier schon des öfteren diverses auch zu den STM32 gepostet, 
unter anderem auch eine Art "Starter-Kit" für den STM32F103, wo eben 
auch ein funktionabler Lowlevel-Treiber für die UART's dabei war. Sowas 
brauchst du - und nicht ein Herumackern auf irgendwelchen 
Hal-Uart-Blabla-Funktionen und obendrein auch noch solch abenteuerliche 
Formulierungen wie oben gezeigt.

Bei mir heißt sowas schlicht

String_Out("Studi muß dazulernen", toUART0);

und das funktioniert (mit meinen I/O-Funktionen). Such einfach mal nach 
"STM32F103C8T6.ZIP"

W.S.

[Ruediger A. (Firma: keine) (rac)]

Hast Du die peripheral clock für den UART enabled?

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

W.S. schrieb:
> Ich hatte hier schon des öfteren diverses auch zu den STM32 gepostet,
> unter anderem auch eine Art "Starter-Kit" für den STM32F103, wo eben
> auch ein funktionabler Lowlevel-Treiber für die UART's dabei war.

Ja, mit Magic Numbers beim init.
Wenn also wer gaaaaanz leise sein sollte dann du!

[Apollo M. (Firma: @home) (majortom)]

W.S. schrieb:
> Such einfach mal nach
> "STM32F103C8T6.ZIP"

schlaumann poste hier mal bitte den link zu dem zip, mercy!


mt

[W.S. (Gast)]

Mw E. schrieb:
> Ja, mit Magic Numbers beim init.
> Wenn also wer gaaaaanz leise sein sollte dann du!

Ich schätze mal, daß du derjenige bist, der ganz leise sein sollte und 
währenddessen mal ganz gründlich nachdenken sollte über den Zweck von 
Zahlen in einem Programm.

Also nicht gedankenlos nachplappern von allem, was dir mal jemand 
eingebleut hat, sondern kritisch hinterfragen. Und da ist meine Methode, 
sich auf so wenig Abhängigkeiten wie sinnvoll möglich einzulassen, 
allemal die weitaus bessere. Abgesehen davon hast du offensichtlich 
den eigentlichen Sinn der Konfigurations-C-Quelldatei nicht im 
geringsten kapiert.


Apollo M. schrieb:
> schlaumann poste hier mal bitte den link zu dem zip

Darf ich dir dann auch noch deine Firmware für lau schreiben? Ja?

W.S.

[Harry L. (mysth)]

Was ein Gefummel...

Versuchs mal so:

#define TIMEOUT 500 // Timeout in ms

uint8_t mystring[] = "Hello World!";

  HAL_UART_Transmit(&huart2, &mystring, sizeof(mystring), TIMEOUT);

HAL_UART_Transmit ist blockierend, und wartet max. TIMEOUT ms.

[pegel (Gast)]

Harry L. schrieb:
> Was ein Gefummel...

Würde ich auch sagen. Schien mir dann aber zu einfach gedacht.
Eigentlich versucht er nur die HAL_UART_Transmit Funktion nachzubauen.

Allerdings würde ich mystring vom Typ char nehmen und strlen() benutzen 
um flexibel zu sein in der Anzahl der Zeichen.

[Harry L. (mysth)]

pegel schrieb:
> Allerdings würde ich mystring vom Typ char nehmen und strlen() benutzen
> um flexibel zu sein in der Anzahl der Zeichen.

HAL_UART_Transmit erwartet an der Stelle einen uint8_t *.

Aber mit strlen() hast du natürlich recht! (geht auch mit uint8_t *)
Bei meinem Beispiel würde er das \0 mitsenden...sorry - my fault.

Dann eben so:

HAL_UART_Transmit(&huart2, &mystring, strlen((char *)mystring), TIMEOUT);

Kann man so oder so machen - in jedem Fall muß man an einer Stelle 
casten.

[Studi (Gast)]

pegel schrieb:
> Würde ich auch sagen. Schien mir dann aber zu einfach gedacht.
> Eigentlich versucht er nur die HAL_UART_Transmit Funktion nachzubauen.

Nein wollte sie nur posten zur info.

Mein Problem ist, dass ich die Transmit-Funktion einmal in einer 
Dauerschleife aufrufen kann, das char einmal übermittelt wird und die 
Funktion dann fest steckt bei dem "waitonflag". Wenn ich zyklisch Daten 
auf den UART ausgeben möchte, ist es besser dies über Interrupt zu 
realisieren?

[Harry L. (mysth)]

Studi schrieb:
> pegel schrieb:
>> Würde ich auch sagen. Schien mir dann aber zu einfach gedacht.
>> Eigentlich versucht er nur die HAL_UART_Transmit Funktion nachzubauen.
>
> Nein wollte sie nur posten zur info.
>
> Mein Problem ist, dass ich die Transmit-Funktion einmal in einer
> Dauerschleife aufrufen kann, das char einmal übermittelt wird und die
> Funktion dann fest steckt bei dem "waitonflag". Wenn ich zyklisch Daten
> auf den UART ausgeben möchte, ist es besser dies über Interrupt zu
> realisieren?

Wozu das ganze Gefummel?

Hit HAL_UART_Transmit() kannst du problemlos in einer Dauerschleife 
senden ohne selbst irgendwelche Flags berücksichtigen zu müssen.
Die Funktion kehrt erst zurück, wenn alle Daten übertragen wurden.

Natürlich ist es besser, sowas mit Interrupts zu machen, aber dann musst 
du dir auch dezu passende FIFOs bauen, und mir scheint, deine Probleme 
liegen im Moment noch auf einer ganz anderen Ebene.