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.