Forum: Mikrocontroller und Digitale Elektronik STM32 UART niedrige Baud Rate keine Interrupts


von Bert S. (kautschuck)


Lesenswert?

Hi,

Ich habe hier ein sehr komisches verhalten eines UART's auf einem STM32 
und zwar bekomme ich keine Interrupts, wenn ich die Baudrate niedrige 
setze. Bei 9600 also wird der USART1_IRQHandler() nur aufgerufen, wenn 
ich zwei Zeichen oder mehr gleichzeitig schicke. Hingegen bei 115200B/s, 
wird der Interrupt für jedes Zeichen ausgelöst. Auch meine Callback 
Funktion geht nur mit 115200 B/s. Jemand eine Idee, was da los ist? Eine 
niedrigere Baudrate müsste ja einfacher zu handhaben sein für den 
Interrupt Handler? UART2 hingegen funktioniert mit 9600B/s wunderbar.
1
static void MX_USART1_UART_Init(void)
2
{
3
4
  huart1.Instance = USART1;
5
  huart1.Init.BaudRate = 9600;
6
  huart1.Init.WordLength = UART_WORDLENGTH_8B;
7
  huart1.Init.StopBits = UART_STOPBITS_1;
8
  huart1.Init.Parity = UART_PARITY_NONE;
9
  huart1.Init.Mode = UART_MODE_TX_RX;
10
  huart1.Init.HwFlowCtl = UART_HWCONTROL_NONE;
11
  huart1.Init.OverSampling = UART_OVERSAMPLING_16;
12
  huart1.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;
13
  huart1.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;
14
  if (HAL_UART_Init(&huart1) != HAL_OK)
15
  {
16
    _Error_Handler(__FILE__, __LINE__);
17
  }
18
19
}

Der UART wird nach jedem empfangenen Zeichen mit folgender HAL Funktion 
wieder neu initialisiert:

HAL_UART_Receive_IT(uart1, rx_buffer_uart_1, 1);

: Bearbeitet durch User
von Stefan F. (Gast)


Lesenswert?

Ich will dich jetzt nicht ärgern, aber du wirst noch merken, dass du bei 
Problemen mit der HAL meistens ziemlich alleine da stehst.

Offensichtlich kennen sich einige Leute ganz gut mit der alten StdPeriph 
(SPL) Library aus, aber nur wenige mit der HAL.

Ich habe sie nach kurzer Evaluierung ganz weit weg in die hinterste Ecke 
meines Unterbewusstseins verbannt und programmiere lieber mit dem 
Reference Manual auf Register-Ebene. Das ist etwas Zeitaufwändiger (mir 
egal, da Hobby), dafür weiß ich wenigstens, was ich tue.

An meinem ersten Tag mit der HAL auf einem original STM Evaluation Board 
hatte ich direkt ein Problem mit der Initialisierung des Taktgebers. Ich 
bat STM um Hilfe, auf Antwort warte ich immer noch (nun fast 1 Jahr). 
Inzwischen wurde es als Bug in der HAL behoben. Aber die Leute dort 
halten es nicht einmal für angemessen, mich darauf hinzuweisen.

Qualität = sehr fragwürdig
Support = Null
Doku = Kacke (da ist sogar Arduino noch besser, und Arduino ist 
schlimm).

Die HAL braucht kein Mensch. Sie vereinfacht auf den ersten Blick die 
Programmierung, schafft damit aber eine große Menge neue Probleme, bei 
denen Dir nur wenige Menschen kostenlos helfen können. Am schlimmsten 
ist die Abhängigkeit, in die man sich bei der Benutzung der HAL begibt. 
Du kannst danach nicht eben schnell auf ein anderes Framework wechseln 
oder gar auf einen µC von einem anderen Hersteller. Genau das ist die 
wahre Absicht hinter dem Framework (Kundenbindung auf Drogendealer-Art). 
Wenn du mit der CMSIS-Core Programmierst, hast du diese Freiheiten aber.

Warum schreibe ich das: Ein bisschen weil ich ein ewiger Miesepeter bin 
(zumindest heute). Aber hauptsächlich, weil ich dich animieren will, 
lieber das Referenzhandbuch zu lesen anstatt das Manual zur HAL.

von STK500-Besitzer (Gast)


Lesenswert?

Bert S. schrieb:
> einem STM32
Welcher denn? Es gibt ja nicht den STM32, sondern mehrere Familien.

Stefan U. schrieb:
> weil ich dich animieren will,
> lieber das Referenzhandbuch zu lesen anstatt das Manual zur HAL.

Das und das "HAL and LL driver manual" sollte man griffbereit haben.
Ich bin auch nicht der Freund von Blackbox-Bibliotheken (die noch 
fehlerhaft und schlecht dokumentiert sind).
Wenn man aus Richtung 8051, AVR und Arduino kommt, dann ist man bzgl. 
Doku etwas verwöhnt.

von Bert S. (kautschuck)


Lesenswert?

Danke euch, ich programmiere auch öfters mal CMSIS, aber wenn es schnell 
gehen muss nehme ich CubeMX zur Hand und initialisiere alles dort vor. 
Den Fehler habe ich gefunden und war nicht beim Empfang des STM32, 
sondern beim anderen Gerät. Ich hatte beim Senden ein zu kleines Timeout 
gewählt, so dass das andere Gerät nicht nachkam und so manchmal/immer 
falsche Daten schickte.

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.