Verständnisfrage stm32 uart

Danke schonmal für die rasche Antwort.

Also mein Code sieht wie folgt aus:


#include "stm32f4xx_hal.h"
#include "stm32f4xx_hal_rcc.h"
#include "stm32f4xx_hal_gpio.h"
#include "stm32f4xx_hal_uart.h"
#include "stm32f4xx_hal_cortex.h"

#include <stdio.h>
#include <stdlib.h>
#include <string.h>


UART_HandleTypeDef uart_config;

int x=0;
char data[10];
char rx_byte[1];

int main(void)
{
  int i=0;

  HAL_Init();

  SystemInit();

//************  UART CONFIG  *****************************//

  __USART1_CLK_ENABLE();

  uart_config.Instance=USART1;

  uart_config.Init.BaudRate=115200;
  uart_config.Init.WordLength=UART_WORDLENGTH_8B;
  uart_config.Init.StopBits=UART_STOPBITS_1;
  uart_config.Init.Parity=UART_PARITY_NONE;
  uart_config.Init.Mode=UART_MODE_TX_RX;
  uart_config.Init.HwFlowCtl=UART_HWCONTROL_NONE;
  uart_config.Init.OverSampling=UART_OVERSAMPLING_8;

  HAL_UART_Init(&uart_config);

  HAL_NVIC_SetPriority(USART1_IRQn,0,1);
  HAL_NVIC_EnableIRQ(USART1_IRQn);

//**********************************************************//

//************ UART GPIO CONFIG  *********************//

  GPIO_InitTypeDef uart_gpio;

  __GPIOA_CLK_ENABLE();

  uart_gpio.Pin=GPIO_PIN_9 | GPIO_PIN_10;
  uart_gpio.Mode=GPIO_MODE_AF_PP;
  uart_gpio.Pull=GPIO_NOPULL;
  uart_gpio.Speed=GPIO_SPEED_FAST;
  uart_gpio.Alternate=GPIO_AF7_USART1;


  HAL_GPIO_Init(GPIOA, &uart_gpio);

//******************************************************//


//************  LED  ****************************//

  GPIO_InitTypeDef gpio_led;

  __GPIOG_CLK_ENABLE();

  gpio_led.Pin=GPIO_PIN_12;
  gpio_led.Mode=GPIO_MODE_OUTPUT_PP;
  gpio_led.Pull=GPIO_NOPULL;
  gpio_led.Speed=GPIO_SPEED_FAST;

  HAL_GPIO_Init(GPIOG, &gpio_led);

//***********************************************//


  while(1)
    {

    HAL_UART_Receive_IT(&uart_config, rx_byte, 1);

      HAL_GPIO_WritePin(GPIOG, GPIO_PIN_12, 0);

      for (i=0; i<=500000; i++);  //delay für LED

      HAL_GPIO_WritePin(GPIOG, GPIO_PIN_12, 1);

      for (i=0; i<=500000; i++);      //delay für LED


    }
}


void HAL_UART_RxCpltCallback(UART_HandleTypeDef *UartHandle)
{

  data[x]=rx_byte[0];

  if (data[x] =='\r')
  {
    HAL_UART_Transmit_IT (&uart_config, data, x);
    x=0;
  }
  else
  {
    x++;
  }
}

void USART1_IRQHandler(void)
{
  HAL_UART_IRQHandler(&uart_config);

}


Wäre meine Überlegung so prinzipiell richtig??
An der Ausführung muss natürlich noch gearbeitet werden :)

Vielen Dank für die Antworten aber leider bekomme ich das Ding nicht 
richtig zu laufen.

Was ich immer noch nicht verstehe folgender Befehl:
HAL_UART_Receive_IT(&uart_config, rx_byte, 1);

Der muss scheinbar in der Hauptschleife stehen, sonst funktioniert 
nichts. Das ist aber meiner Meinung nach dann keine Interruptsteuerung, 
wenn ich das jedes mal aufrufen muss, oder?? Kann mir das jemand 
erklären??

Hat vielleicht jemand ein simples Beispielprogramm mit der HAL library, 
welches er posten kann!?

Danke schonmal.

Hat denn keiner einen Tipp??

elektro01 schrieb:
> Was ich immer noch nicht verstehe folgender Befehl:
> HAL_UART_Receive_IT(&uart_config, rx_byte, 1);
>
> Der muss scheinbar in der Hauptschleife stehen, sonst funktioniert
> nichts. Das ist aber meiner Meinung nach dann keine Interruptsteuerung,
> wenn ich das jedes mal aufrufen muss, oder?? Kann mir das jemand
> erklären??

Der Thread ist zwar schon alt, wurde aber gerade in 
Beitrag "Re: STM32 HAL Tutorial" referenziert und da 
passt die Antwort besser hierhin.

Die Funktion  HAL_UART_Receive_IT(&uart_config, rx_byte, 1); liefert 
einen Status zurück der ausgwertet werden sollte. Wenn ein Receive 
gestartet und noch nichts empfangen wurde wird die beim erneuten Aufruf 
Busy zurückliefern. Im HAL_UART_RxCpltCallback() kann man ein Flag 
setzen wenn der Empfang fertig ist (weil z.B. ein Endezeichen empfangen 
wurde) und im Hauptprogramm kann man andere Sachen erledigen und 
gelegentlich das Empfangsflag abfragen.

Aus dem anderen Thread:
technikus schrieb:
> HAL_UART_Receive_IT(&UartHandle, rx_data, 10);
>
> Füllt fleißig den Puffer bis 10 Bytes empfangen wurden und beginnt dann
> wieder von vorne - alles Interrupt gesteuert.
>
> Was ist aber, wenn ich in der Hauptschleife auslese ob schon was da ist
> und dann den Startzeiger vom Puffer neu initialisieren möchte?
> Qick and dirty kriege ich das hin, geht aber irgendwie am HAL Gedanken
> vorbei...

Das halte ich für keine gute Strategie, das behandelt man besser in 
einer Statemachine. Wenn das Protokoll über die Schnittstelle z.B. mit 
fixem Header+Daten aufgebaut ist startest du einen Receive mit Anzahl 
Headergrösse und setzt den Status auf 'STATE_RECEIVE_HEADER'. Im 
RxCpltCallback wird dann nur der Status auf Header empfangen gesetzt. 
Wenn das Hauptprogramm diesen Status erkennt startet es dann den Receive 
mit der nötigen Anzahl Daten.

Danke für den konstruktiven Beitrag!
Nur was mache ich, wenn der Empfangspuffer mit z.B. 10 Zeichen definiert 
ist, 9 empfangen werden und das Endzeichen nicht empfangen wird?
Dann müsste die Funktion ja nach einem Timeout den Puffer von vorne 
füllen ?!

ja, timeout ist das Stichwort nachdem ich auch suchen würde. Im User 
Manual ist ein Kapitel 'Timeout and error management'. Das wird für 
mehrere Funktionen benutzt ist damit übergeordnet.
Im Kapitel UART ist noch ein 'how to use' da findest du schonmal eine 
kurze Erklärung zum nötigen Ablauf. Und die Interrupt und DMA 
(non-blocking) Funktionen können mit den Abort Funktionen abgebrochen 
werden, damit muss man dann etwas spielen.
Wenn man ein Protokoll ohne Endezeichen hat kann man auch Blockweise mit 
Timeout lesen, solche Protokolle finde ich aber weniger gut. Ansonsten 
ist die Nutzung von Timeouts sehr zu empfehlen. Weil das mehr Aufwand 
ist spart man sich das gerne, aber wenn der HAL das schon bietet sollte 
man das auch mitnehmen.
Für mich macht das den Unterschied zwischen funktionierenden und 
robusten Programmen aus: es gibt viele die tun was sie sollen, aber 
einmal Stecker raus-rein und das Programm hängt und muss neugestartet 
werden. Programmiere industrielle Steuerungen und du weisst was das 
kostet...