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:
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
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/
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.
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.
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/
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
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.
