stm32 stdperiph-driver: Programmierstil?

[Markus G. (the_grue)]

Servus!

Gerade habe ein paar Stunden verloren um meinen USART zum Laufen zu 
bekommen. Dank Hilfe aus dem Forum hat's dann geklappt (danke nochmal)

Beitrag "Noch ein STM32F303 USART3 geht nicht"

Jetzt ärgere ich mich gehörig über den Programmierstil im STM32 
StdPeriphDriver: Warum schreiben die dort sowas:

void GPIO_PinAFConfig(GPIO_TypeDef* GPIOx, uint16_t GPIO_PinSource, uint8_t GPIO_AF)
{
  /* Check the parameters */
  assert_param(IS_GPIO_PIN_SOURCE(GPIO_PinSource));

anstatt sowas?

void GPIO_PinAFConfig(GPIO_TypeDef* GPIOx, GPIO_PinSource_t GPIO_PinSource, GPIO_AlternateFunction_t GPIO_AF)
{

Dass erstere Methode mit dem Assert keinerlei Sicherheit bringt wenn die 
Werte im gleichen Bereich liegen ist doch klar. und ein

 typedef enum {...} GPIO_PinSource_t

 wäre halbwegs typsicher und kostet nix.

Was übersehe ich da? Irgendwelche Kompatibilitätsprobleme? Bin noch 
nicht lange bei ST...

cu
Markus

[kaesschnip (Gast)]

Markus G. schrieb:
> Was übersehe ich da? Irgendwelche Kompatibilitätsprobleme? Bin noch
> nicht lange bei ST...

Bei ST gilt eins:

Je tiefer du in die hübsche Fassade rein schaust, destö übler wirds.

Die Chips (im speziellen die STM32F4 Serie) sind im Silizium ganz ok.

Bei der Dokumentation, der HAL-Schicht und den darauf aufbauenden 
Treibern (USB, etc.) wird es ganz schnell ganz übel.

Das offz. ST-Forum quilt über was Bugs angeht. Die Dokumentation ist 
auch ziemlich rottig und an einigen Stellen falsch.

http://www.efton.sk/STM32/STM32F4xx_doc_errors.txt

[Jay (Gast)]

Markus G. schrieb:
> Was übersehe ich da? Irgendwelche Kompatibilitätsprobleme? Bin noch
> nicht lange bei ST...

ST hat, wie praktisch alle Mikrocontroller-Hersteller ein Problem mit 
Software. Software ist nicht Kerngeschäft, da hat man keine Ahnung von, 
will keine Ahnung von haben, man macht schließlich Hardware, und billig 
muss es auch sein.

Weil alle Mikrocontroller-Hersteller so schlechte Treiber-Bibliotheken 
liefern verzichten viele für einfache Operationen auf diese 
Bibliotheken. Die Erfahrung lehrt es ist einfacher die Peripherie nach 
Datenblatt und Errata zu programmieren und notfalls den eigenen Code zu 
debuggen, als das Zeug vom Hersteller verstehen und debuggen zu müssen.

Ausnahmen gibt es auch. Kaum jemand wird sich einen eigenen USB-Treiber 
nach Datenblatt programmieren. Da lebt man lieber mit den Zeug vom 
Hersteller oder einem Drittanbieter.

[aSma>> (Gast)]

Servus,

> Was übersehe ich da? Irgendwelche Kompatibilitätsprobleme? Bin noch
> nicht lange bei ST...

Wird zum Teil gemacht aber nicht Konsequent.

typedef enum
{ GPIO_Mode_AIN = 0x0,
  GPIO_Mode_IN_FLOATING = 0x04,
  GPIO_Mode_IPD = 0x28,
  GPIO_Mode_IPU = 0x48,
  GPIO_Mode_Out_OD = 0x14,
  GPIO_Mode_Out_PP = 0x10,
  GPIO_Mode_AF_OD = 0x1C,
  GPIO_Mode_AF_PP = 0x18
}GPIOMode_TypeDef;

#define IS_GPIO_MODE(MODE) (((MODE) == GPIO_Mode_AIN) || ((MODE) == GPIO_Mode_IN_FLOATING) || \
                            ((MODE) == GPIO_Mode_IPD) || ((MODE) == GPIO_Mode_IPU) || \
                            ((MODE) == GPIO_Mode_Out_OD) || ((MODE) == GPIO_Mode_Out_PP) || \
                            ((MODE) == GPIO_Mode_AF_OD) || ((MODE) == GPIO_Mode_AF_PP))

Hier wiederum nicht:

#define GPIO_Pin_0                 ((uint16_t)0x0001)  /*!< Pin 0 selected */
#define GPIO_Pin_1                 ((uint16_t)0x0002)  /*!< Pin 1 selected */
...

Vielleicht ist OpenSTM32 was für dich. Da ist die lib portabler und wird 
immer weiter entwickelt.

Das ist hier aber nur ein kleiner Tropfen auf den heißen Stein.

mfg

[Random .. (thorstendb)]

Warum braucht man für so einfache Peripherals eine komplizierte 
DriverLibrary?

[Herbert (Gast)]

Random .. schrieb:
> Warum braucht man für so einfache Peripherals eine komplizierte
> DriverLibrary?

Weil du in der Industrie keine Zeit hast so Low Level zu entwickeln. Es 
ist nicht mehr so einfach wie bei den 8bit Controllern und das ist 
einfach zu zeitaufwändig für Entwicklungen hinter denen Geld / Zeitdruck 
steht.

[Random .. (thorstendb)]

Herbert schrieb:
> Random .. schrieb:
>> Warum braucht man für so einfache Peripherals eine komplizierte
>> DriverLibrary?
>
> Weil du in der Industrie keine Zeit hast so Low Level zu entwickeln. Es
> ist nicht mehr so einfach wie bei den 8bit Controllern und das ist
> einfach zu zeitaufwändig für Entwicklungen hinter denen Geld / Zeitdruck
> steht.

Wenn ich mir den ganzen Ärger mit den DriverLibs so ansehe, könnte man 
das in der Zeit fast ohne selbige programmieren :-)

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Markus G. schrieb:
> {...} GPIO_PinSource_t[/c] wäre halbwegs typsicher und kostet nix.

Der Compiler wird aus den Aufzählungstypen wahrscheinlich einen int 
machen, dass wären dann ein paar Bytes mehr auf dem stack. Das könnte 
man mit C++11 lösen, aber die meisten HW Herstellen trauen Ihren Kunden 
ja nicht einmal C99 zu.

> Was übersehe ich da? Irgendwelche Kompatibilitätsprobleme? Bin noch
> nicht lange bei ST...

Ansonsten hat Jay es eigentlich ganz gut getroffen.

[W.S. (Gast)]

Markus G. schrieb:
> Gerade habe ein paar Stunden verloren um meinen USART zum Laufen zu
> bekommen.

Ja sag mal, von welcher Vorkenntnis-Position aus bist du denn gestartet? 
Also aus meiner Sicht sind die USART/UART-Cores von ST so übersichtlich 
und einfach in der gewöhnlichen Benutzung als UART's, daß es gerade 
damit doch gar keine Probleme geben dürfte. Statische Interrupts, die 
man bei Bedarf nur wieder zuschalten braucht, ohne dem NVIC nen Softint 
unterjubeln zu müssen - was will man mehr???

Markus G. schrieb:
> Jetzt ärgere ich mich gehörig über den Programmierstil im STM32
> StdPeriphDriver: Warum schreiben die dort sowas:

Gegenfrage: Warum versuchst du, sowas überhaupt zu benutzen? Dieses 
ST-Zeugs war von Anfang an Mist und jeder, der sich das mal angesehen 
hat, weiß, daß man da besser einen großen Bogen drum macht. Knick das 
Zeugs einfach, anstatt dich über deren Stil zu echauffieren.

Ich häng dir mal ne Alternative dran - zum verstehenden Angucken, denn 
das ist für nen STM32F302. Sowas geht ohne all das krude ST-Zeugs.

W.S.

[Lukas K. (carrotindustries)]

Für komplexe Peripherien, mit gut definierbarer Schnittstelle, wie USB, 
SDIO, oder Ethernet macht Abstraktion durchaus Sinn. Andere (libopencm, 
chibios) bekommen das allerdings ordentlicher hin als ST.
Bei Peripherien wie ADC, Timer, etc. lohnt sich Abstraktion nicht 
wirklich. Ob ich nun die Register direkt beschreibe oder einer Funktion 
sage, wie sie die Register setzen soll, macht keinen arg großen 
Unterschied. Hilfreich dabei wäre noch, wenn ST in den Header-Dateien 
sinnvolle konstanten für Bitfelder definiert, sodass man auch ohne 
Datenblatt ansehen erkennt, was beabsichtigt war. (Aber dann würden 
Leute ja sehen, dass deren HAL praktisch keine Abstraktion bietet)

[W.S. (Gast)]

Lukas K. schrieb:
> Bei Peripherien wie ADC, Timer, etc. lohnt sich Abstraktion nicht
> wirklich.

Da setzt du einfach zu tief an.

Einen Timer braucht man eigentlich NIE als reinen Selbstzweck.
Stattdessen soll er immer irgend einem "höheren" Zweck dienen.
Und genau dieser Zweck ist normalerweise etwas, das eines sinnvollen 
Treibers bedarf.

Beispiel(aus dem Stegreif): Dreiphasen-Motor mit 3 gekoppelten 
Compare-Registern und/oder drangekoppeltem zweiten Timer für die 
Approximmation der Sinus-Ansteuerung oder sowas in der Art.

Das gibt dann nen Treiber "dreiphasen.c", der sehr wohl seine ganzen 
Innereien ggü. den höheren Programmschichten abstrahiert. An solcher 
Stelle sehe ich die Abstraktion, nicht jedoch bei do_gpio_set(1<<7); 
anstelle GPIO_SET = 1<<7;

W.S.

[Michi (Gast)]

Random .. schrieb:
> Wenn ich mir den ganzen Ärger mit den DriverLibs so ansehe, könnte man
> das in der Zeit fast ohne selbige programmieren :-)

Ich weiß ja, dass viele über die SPL und die HAL schimpfen, kann das 
aber bisher nicht nachvollziehen. Sie mag ja (teilweise) ineffizient 
geschrieben sein, aber so verbuggt, wie manche einen glauben machen 
wollen, ist sie nicht, finde ich.

Lukas K. schrieb:
> Andere (libopencm,
> chibios) bekommen das allerdings ordentlicher hin als ST.

Ich habe mich mal an der libopencm versucht, habe sie aber nicht 
durchschauen können und auch nicht zum Laufen gebracht. Ein gutes 
Tutorial habe ich nicht gefunden, zumindest nicht für Windows. Sowas ist 
dann natürlich nicht gerade hilfreich...

[Lukas K. (carrotindustries)]

W.S. schrieb:
> Lukas K. schrieb:
>> Bei Peripherien wie ADC, Timer, etc. lohnt sich Abstraktion nicht
>> wirklich.
>
> Da setzt du einfach zu tief an.
> [...]
> W.S.

Eine Abstraktion wie von dir beschrieben ist keine generische 
Abstraktion, wie sie ST anstrebt. Und ebendiese ist unnütz. Das von dir 
beschriebene fällt für mich schon unter Applikation/Bibliothek.

Michi schrieb:
> Lukas K. schrieb:
>> Andere (libopencm,
>> chibios) bekommen das allerdings ordentlicher hin als ST.
>
> Ich habe mich mal an der libopencm versucht, habe sie aber nicht
> durchschauen können und auch nicht zum Laufen gebracht. Ein gutes
> Tutorial habe ich nicht gefunden, zumindest nicht für Windows. Sowas ist
> dann natürlich nicht gerade hilfreich...
Dann siehst du mal, wie es den Leuten ergeht, die die Beispielprojekte 
von ST auf Linux bauen wollen und mit Dingen wie backspaces in 
Include-Pfaden kämpfen müssen :P

Auf Linux ist's git pull, git submodule init, make

[Markus G. (the_grue)]

Servus!

Danke für die fleissigen Antworten/die Diskussion! Wie gesagt, ST 
verwende ich noch nicht lange.

Alles selbst zu programmieren und auf die angebotenen Bibliotheken zu 
verzichten ist sicher machbar (hab' ich auf 8051, Atmel und MSP430 auch 
schon gemacht). Je weiter weg man aber vom Einzelkämpfer entwickelt, hin 
zu (nicht mal so großen) Teams, hat man selten die Wahl.

Außerdem bin ich eigentlich ein Freund von Abstrahierung, so lange es 
sinnvoll machbar ist.

Deshalb denke ich, daß eine Bibliothek des Herstellers eigentlich eine 
art Aushängeschild sein sollte, mit der es eine Freude ist zu arbeiten. 
"Seht her, so schön könnt Ihr UNSEREN chip mit UNSERER lib verwenden". 
Ist leider nicht realistisch ;)

cu
Markus

[Tom (Gast)]

Markus G. schrieb:
> und ein typedef enum {...} GPIO_PinSource_t wäre halbwegs typsicher

In C hilft ein enum der Typsicherheit fast gar nicht. Die Alternative 
wäre das Verpacken des Wertes in ein struct oder Makrozauberei.

#include <stdio.h>

typedef enum  tApple { CoxOrange, Boskop } tApple;
typedef enum tColor { Green, Red} tColor;

void doit(tApple apple)
{
    if (apple == Red) // gcc -Wall -Wextra warnt, clang -Weverything nicht
        return;
    return;
}

int main(void)
{
    doit(Green); //geht mit gcc, clang warnt
    tColor x = Boskop; //geht mit gcc, clang warnt
    doit(1);  //geht
    return 0;
}

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Tom schrieb:

> In C hilft ein enum der Typsicherheit fast gar nicht. Die Alternative

Aber im Debugger erhaelt man eine vernuenftige Angabe und nicht nur eine 
Ziffer...

[Markus G. (the_grue)]

Tom schrieb:
> In C hilft ein enum der Typsicherheit fast gar nicht

Leider hast Du recht. Ich war es über die Jahre so gewohnt auch C-Code 
mit einem C++ compiler zu übersetzen, daß ich die Typenprüfung dem 
C-Compiler untergeschoben habe :(

Trotzdem, "fast gar nicht" ist immer noch besser als "gar nicht".