Forum: Mikrocontroller und Digitale Elektronik Stilblüten in der STM32 firmware library


von (prx) A. K. (prx)


Lesenswert?

Welches Niveau von Programmierer(n) wird bei ST eigentlich für die 
Erstellung der Firmware Libraries eingesetzt? Dürfen sich da nur 
Anfänger austoben, oder jene die erwiesenermassen für anderes nicht zu 
gebrauchen sind?

Dass diese Libs arg platzraubend sind ist zu verschmerzen, nicht zuletzt 
weil bei GCC sehr viel Müll mit -ffunction-sections und --gc-sections 
über Bord geworfen werden kann (obacht bei Interrupthandlern, die 
fliegen auf diese Art gleich mit über Bord, wenn man sie nicht mit 
__attribute__(used)) verziert ;-).

Ich hatte den Fehler gemacht, in den Code zur UART-Initialisierung 
reinzusehen. Der Teil über die Berechnung des fraktionalen 
Baudratenteilers ist eine Sehenswürdigkeit für den Umgang mit 
Festkommarechnung. Dafür, wie man es nicht machen sollte. Nämlich mit 
dezimaler Festkommarechnung bei einem Wert der im Register als binäre 
Festkommazahl mit 4 Nachkommastellen erwartet wird.

Bei ST sieht das bei 36MHz / (16 * 9600) = 234,375 vereinfacht(!) so 
aus:
1
divider = ((0x19 * apbclk) / (0x04 * baud)         // 23437
2
USART->Mantissa = divider / 0x64                   // 234
3
fraction =  divider - (0x64 * USART->Mantissa)     // 37
4
USART->Fraction = (fraction * 0x10 + 0x32) / 0x64  // 6
Die Konstanten legen die Frage nahe, ob das aus disassembliertem Code 
rückübersetzt wurde (0x19=25, 0x32=50).

Jedenfalls kommt man abgesehen von einem kaum relevanten Rundungseffekt 
auch so zum Ziel:
1
USART->BRR = apbclk / baud
oder mit korrekter Rundung mit gleichem Ergebnis wie von obigem Code:
1
USART->BRR = ((2 * apbclk) / baud + 1) / 2

von Peter D. (peda)


Lesenswert?

Deine Erwartungen sind zu hoch.
Application-Notes sollen immer nur in die Richtung zeigen.
Wirklich optimalen und universellen Code zu erzeugen kostet viel Kraft 
und Zeit.

Manchmal stolpert man über nen hübschen Code und fragt sich, warum ist 
da bloß früher niemand drauf gekommen.
Dann möchte man ihn veröffentlichen und merkt, da muß man noch viel 
Arbeit reinstecken, um ihn zu erklären.


Peter

von Marcus H. (mharnisch) Benutzerseite


Lesenswert?

A. K. schrieb:
> Welches Niveau von Programmierer(n) wird bei ST eigentlich für die
> Erstellung der Firmware Libraries eingesetzt? Dürfen sich da nur
> Anfänger austoben, oder jene die erwiesenermassen für anderes nicht zu
> gebrauchen sind?

Um es mit den Worten eines ex-Kollegen zu sagen: "Ich habe noch nie Code 
gesehen, den ich nicht selbst hätte besser schreiben können."

Das mit den Firmware Libraries ist ein herstellerübergreifendes Problem. 
Schau Dir mal das Zeug von Luminary an. Nicht besser! Auch in ARMs 
eigenem CMSIS wirst Du über ein paar komische Stellen stolpern.

Gruß
Marcus
http://www.doulos.com/arm/

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

A. K. schrieb:
> Dürfen sich da nur
> Anfänger austoben, oder jene die erwiesenermassen für anderes nicht zu
> gebrauchen sind?

Such dir was aus:

- Praktikant

- Outgesourced nach Indien

- Hardware-Ingenieur der nebenbei Software macht / machen muss.

von Random .. (thorstendb) Benutzerseite


Lesenswert?

> Auch in ARMs eigenem CMSIS wirst Du über ein paar komische Stellen stolpern.

Z.B?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Hannes Jaeger schrieb:
> - Hardware-Ingenieur der nebenbei Software macht / machen muss.
Informatiker, der nebenher Hardware macht   ;-)

von Johnny (Gast)


Lesenswert?

Sagen wirs mal so; ist der Code einigermassen verständlich und er 
funktioniert für das vorgesehene, dann ist alles im Butter.

von (prx) A. K. (prx)


Lesenswert?

Johnny schrieb:

> Sagen wirs mal so; ist der Code einigermassen verständlich und er
> funktioniert für das vorgesehene, dann ist alles im Butter.

Das ist ja der Punkt. Solcher Code soll Tipps für den Umgang mit der 
Hardware geben. Hier wird aber nur klar, dass der Autor des Codes rein 
garnichts davon kapiert hat. Zugegeben: Das Reference Manual von ST ist 
an dieser Stelle auch nicht besser.

von JojoS (Gast)


Lesenswert?

na immerhin wurde nicht mit floating point gerechnet... So siehts aus 
wenn man VB Programmierer auf µCs loslässt.

von Marcus H. (mharnisch) Benutzerseite


Lesenswert?

Hallo Thorsten

zunächst geht es mir nicht darum schmutzige Wäsche zu waschen. Man wird 
immer irgendetwas finden, das man selbst anders gemacht hätte. Andere 
Vorlieben, Prioritäten, etc.

> Z.B?

Zugegeben, in neueren Versionen von CMSIS findet man weniger Stellen. 
Aber es gibt unnötige API Unterschiede zwischen CM0 und CM3. CM1 fehlt 
ganz.

In der Prioritätsverwaltung (core_cm3.h) gibt es meiner Meinung nach die 
Gefahr einer Prioritätsinvertierung, wenn man Code von einem Prozessor 
mit n Prioritätsbits zu einem mit m < n Prioritätsbits portiert, 
da die oberen Bits (und nicht die unteren) abgeschnitten werden. Da 
könnte man wenigstens eine Warnung erzeugen.

Solche Abstraktionslayer werden nie "expert friendly" sein. Das können 
sie gar nicht. In sofern ist es müßig, darüber zu diskutieren.

Gruß
Marcus
http://www.doulos.com/arm/

von Robert T. (robertteufel)


Lesenswert?

Solche Libraries werden in erster Linie als Marketing Tool eingesetzt 
und sollen dem potentiellen Kunden zeigen, "wir haben bereits all deinen 
Code geschrieben, brauchst nur noch die Bloecke auszusuchen". Dass ein 
solcher Code gnadenlosen Overhead beinhaltet ist schon fast in der Natur 
der Dinge. Typischerweisse sind dabei wirklich viele Werksstudenten im 
Einsatz. Die schreiben eine LIB Funktion, der Betreuer laesst sich 
zeigen, dass es funktioniert (mit dem gegebenen Setup), dann wird noch 
in die Beschreibung reingelesen ob es zu entschluesseln ist und fertig 
ist eine LIB-Routine.
Dieser Code kann selbstverstaendlich noch verbessert werden aber die 
LIBs helfen einen schnellen Schuss zu machen und die Funktionalitaet des 
Systems zu zeigen, dem Chef, dem Kunden, wem auch immer.
Leider ist es dann so langsam wie bei Windows, es tut, wir haben es 
schnell zum laufen gebracht, blos nicht mehr anfassen :-(
Time to Market ist und bleibt ein Riesenthema, also wird es in Zukunft 
eher verstaerkt in die Richtung von schnell erstelltem aber nicht sehr 
schoenen Code gehen.
Bin gerade dabei einen Vortrag ueber Power Saving zu erstellen, so manch 
einer wuerde es nicht fuer moeglich halten, wieviel Power / 
Batterielebenszeit verbessert werden koennte durch gute Programmierung.

Ich bin oft froh, dass es die LIBs gibt aber wenn ich wuesste, dass ein 
Geraet darauf aufbaut.....

Robert

von Martin T. (mthomas) (Moderator) Benutzerseite


Lesenswert?

A. K. schrieb:
> Welches Niveau von Programmierer(n) wird bei ST eigentlich für die
> Erstellung der Firmware Libraries eingesetzt? Dürfen sich da nur
> Anfänger austoben, oder jene die erwiesenermassen für anderes nicht zu
> gebrauchen sind?

Das kann wohl nur ST beantworten, man könnte ja freundlich (=anders als 
oben) anfragen.

> Dass diese Libs arg platzraubend sind ist zu verschmerzen, nicht zuletzt
> weil bei GCC sehr viel Müll mit -ffunction-sections und --gc-sections
> über Bord geworfen werden kann (obacht bei Interrupthandlern, die
> fliegen auf diese Art gleich mit über Bord, wenn man sie nicht mit
> __attribute__(used)) verziert ;-).

Attribut ist nicht nötig, wenn die input-section für die Sprungtabelle 
im Linker-Skript mit einem KEEP versehen wird, damit existieren Verweise 
auf die ISRs und unused-code-removal entsorgt sie nicht. Hat zumindest 
bei meinen Experimenten anstandslos geklappt. Habe aber auch ansonsten 
einiges an dem Beispielskript von STM herumgebastelt (bei Interesse: 
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html#stm32_memcard 
)

Ansonsten finde ich es durchaus o.k., auf die Entfernung von totem Code 
durch den Linker zu setzten, besser als 1001 kleine Quellcodedateien für 
eine "echte" Library oder die Präprozessor-Klimmzüge die zumindest in 
älteren Versionen der Luminary-Codes gemacht wurden. Erfahrungen mit GNU 
Tools werden wohl bei einigen Firmen noch gesammelt, man (der der 
beauftragte Programmierer) kennt sich wohl viel besser mit IAR und/oder 
ARM/Keil Realview aus - aber off topic, Tools haben ja wenig mit dem 
zitierten Wurschtelcode zu tun.

> Ich hatte den Fehler gemacht, in den Code zur UART-Initialisierung
> reinzusehen. Der Teil über die Berechnung des fraktionalen
> Baudratenteilers ist eine Sehenswürdigkeit für den Umgang mit
> Festkommarechnung. Dafür, wie man es nicht machen sollte. Nämlich mit
> dezimaler Festkommarechnung bei einem Wert der im Register als binäre
> Festkommazahl mit 4 Nachkommastellen erwartet wird.
>
> Bei ST sieht das bei 36MHz / (16 * 9600) = 234,375 vereinfacht(!) so
> aus:
>
1
> divider = ((0x19 * apbclk) / (0x04 * baud)         // 23437
2
> USART->Mantissa = divider / 0x64                   // 234
3
> fraction =  divider - (0x64 * USART->Mantissa)     // 37
4
> USART->Fraction = (fraction * 0x10 + 0x32) / 0x64  // 6
5
>
> Die Konstanten legen die Frage nahe, ob das aus disassembliertem Code
> rückübersetzt wurde (0x19=25, 0x32=50).
>
> Jedenfalls kommt man abgesehen von einem kaum relevanten Rundungseffekt
> auch so zum Ziel:
>
1
> USART->BRR = apbclk / baud
2
>
> oder mit korrekter Rundung mit gleichem Ergebnis wie von obigem Code:
>
1
> USART->BRR = ((2 * apbclk) / baud + 1) / 2
2
>

Muss zugeben, dass ich die Funktion auch verwendet habe, fand den Code 
auch verwurschtelt aber habe nicht weiter Zeit daran gesetzt. Danke für 
die Verbesserung.

A. K. schrieb:
> Johnny schrieb:
>
>> Sagen wirs mal so; ist der Code einigermassen verständlich und er
>> funktioniert für das vorgesehene, dann ist alles im Butter.
>
> Das ist ja der Punkt. Solcher Code soll Tipps für den Umgang mit der
> Hardware geben. Hier wird aber nur klar, dass der Autor des Codes rein
> garnichts davon kapiert hat. Zugegeben: Das Reference Manual von ST ist
> an dieser Stelle auch nicht besser.

Grade auf einem besonders groß gewachsenen Holsteiner unterwegs? Der 
Code, so wie er ist, erleichtert doch den Umgang mit der Hardware. Der 
UART wird einstellt und man braucht sich nicht selbst darum zu kümmern. 
Wenn es wirklich auf die paar Bytes und Zyklen ankommt, hat man 
wahrscheinlich woanders größere Baustellen im eigenen Code. Kann ja 
nicht jeder Entwickler Fließkommaarithmetik mit der Muttermilch 
aufgesaugt haben aber kann dennoch mehr als "garnichts kapiert" haben. 
Die Library ist mglw. weniger als "Tip"-Sammlung gedacht, sondern dafür, 
den Anwendungsprogrammierer das Hantieren auf Registerebene zu ersparen 
- aber auch nur Spekulation.

Wie auch immer. Nachhaltige Verbesserung im offiziellen Code vom st.com 
wird es wohl nur geben, wenn man STM die Verbesserung mitteilt. 
Ansonsten versackt das in diesem Forum. Im STM32-Forum ( 
http://www.st.com/mcu/forumsid-23.html ) scheint zumindest ein 
Firmenangehöriger aktiv tätig und hat auch vor einiger Zeit um Feedback 
zu CMSIS/FwLib gebeten.

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.