unknown type name 'HAL_StatusTypeDef'

[STM32 (Gast)]

Hallo,

ich habe hier ein STM32 Projekt mit Eclipse, Atollic Studio.
Die Datei STM32F4xx_hal_def.h wird eingebunden und besitzt einige
Typendefinitionen. Sie sieht so aus:

#ifndef __STM32F4xx_HAL_DEF
#define __STM32F4xx_HAL_DEF


typedef enum
{
  HAL_OK       = 0x00U,
  HAL_ERROR    = 0x01U,
  HAL_BUSY     = 0x02U,
  HAL_TIMEOUT  = 0x03U
} HAL_StatusTypeDef;

typedef enum
{
  HAL_UNLOCKED = 0x00U,
  HAL_LOCKED   = 0x01U
} HAL_LockTypeDef;

...weiterer Inhalt

#endif /* ___STM32F4xx_HAL_DEF */

Obgleich die Datei: STM32F4xx_hal_def.h überall eingebunden ist, wo sie 
gebraucht wird, erhalte ich beim Kompilieren die Fehler:
> unknown type name 'HAL_StatusTypeDef'

Die Fehler treten dabei in fast allen Dateien des Ordners: 
STM32F4xx_HAL_Driver auf.

Wenn ich nun in der Datei "STM32F4xx_hal_def.h" das "#ifndef" 
auskommentiere dann wird die Datei auch von den anderen Files gefunden, 
aber dann erhalte ich wiederum tausende Fehler der Art "conflicting 
types" bzw. der Art redeclaration of HAL_StatusTypeDef und 
HAL_LockTypeDef.

Irgendwie befinde ich mich da in einer Sackgasse.
Ich arbeite mit Eclipse, Atollic Studio, Controller ist ein STM32.

Was mache ich da gerade falsch?

[W.S. (Gast)]

STM32 schrieb im Beitrag #4767071:
> Was mache ich da gerade falsch?

Das was du falsch machst ist, daß du irgendwelches Zeugs verwenden 
willst, ohne daß du es verstehst und ohne daß du es dir genauer 
angeschaut hast.

Warum verschwendest du deine Zeit überhaupt damit, sowas wie diese 
STM-HAL benutzen zu wollen? Das ist doch überhaupt keine HAL, sondern 
lediglich ein zusätzliches Gekruschte, was du nicht im Mindesten 
benötigen würdest, wenn du zum Benutzen deiner Hardware das zugehörige 
RefManual lesen würdest.

In deinem Falle ist offenbar __STM32F4xx_HAL_DEF bereits vorher von 
anderer Seite aus definiert worden und die dortigen Inhalte stehen im 
Konflikt zu dem Zeugs, was du in der genannten Headerdatei siehst. 
Kurzum, all das, was du da zusammenkopiert hast, paßt nicht zusammen.

Mein dringender Rat:
1. pfeif auf all dieses HAL-Gewurschtel,
2. suche dir nen ordentlichen Startupcode in Assembler (Jaja, nicht 
sowas in C, wie hier einige Oberschlaue immer wieder betonen)
3. Stelle dir eine Headerdatei für deinen Controller zusammen, die du 
SELBST verstehst. Und zwar auf Basis des Referenzmanuals!
4. schreibe dir eine ordentliche Konfigurations-Unit
5. schreibe dir für all die Peripherie-Cores, die du benutzen willst und 
für die es einen Sinn macht, einen ordentlichen Treiber, der die HW 
tatsächlich kapselt.

W.S.

[R.I. (Gast)]

Das sind immer die hilfreichsten Antworten, die verlangen man könnte 
sich ja einfach selbst den Treiber schreiben, programmier am besten 
gleich alles in Assembler! Und dann nicht auf die Frage eingehen, naja.

In meinem Fall war das Problem, dass ich in einer selbst geschriebenen 
Datei einen Header aus stm32f4-hal eingebunden habe, um den Typedef 
einer externen Variable zu benutzen.
Diese Zeile dann mit #include "stm32f4xx.h" ersetzt und siehe da alles 
kompiliert wieder.

[DaLi (Gast)]

@R.I. Vielen Dank für Deine Antwort. Mir hat sie geholfen und mein 
Problem ist gelöst.

[Johnny B. (johnnyb)]

STM32 schrieb im Beitrag #4767071:
> Die Fehler treten dabei in fast allen Dateien des Ordners:
> STM32F4xx_HAL_Driver auf.

Die HAL setzt voraus, dass noch mit der Option -D beim Compileraufruf 
ein paar defines gesetzt werden.
Beispielsweise für einen STM32F302xC:

-DUSE_HAL_DRIVER -DSTM32F302xC

CubeMX setzt das alles automatisch richtig, wenn man damit ein Projekt 
erzeugt.