Da muss ich mich aber doch mal fragen - was sind das fuer Leute, die so Software schreiben und in dieser Form abliefern?
Haben die schon mal was davon gehoert, dass man "trailing whitespaces" auch weglassen kann? Oder sind da satanische Botschaften per whitespace-steganographie drinnen versteckt, wenn man den code rueckwaerts liest?
Das ist doch so nervig, wie wenn du im Grossraumbuero einen Kollegen hast, der sich andauernd raeuspern muss.
Was soll diese bescheuerte Pseudo-doxygen-dokumentation ueber den Funktionen?
Und auch die Kommentare in den Funktionen sind doch voellig ueberfluessig. Genau solche Kommentare, die nur nochmal wiederholen, was da dann eh' eine oder ein paar Zeilen spaeter in C steht, sind doch ein Negativbeispiel, wie man gerade /nicht/ coden soll.
Ganz grosses Kino auch die Schreibweisen: Bei Src und Inc natuerlich den ersten Buchstaben gross. Ganz wichtig auch, dass die lokalen popel-includes natuerlich immer in einem eigenen Unterverzeichnis stehen. Warum nicht gleich eine eigene Partition jeweils fuer Src und Inc? Gaaaah!
Dafuer wird dann natuerlich das makefile mit kleinem m am Anfang (mutmasslich vom dusseligen STM32CubeIDE) erstellt und nicht mit grossem M.
Und includiert natuerlich auch im simpelsten Projekt Unmengen andere makefileartige Dateien.
Dann muss man natuerlich immer streng zwischen Applications, Examples, und Demonstrations unterscheiden. Ist ja logo...
Ich hatte echt versucht, diesen Kackhaufen zu umgehen. Aber dummerweise siehts so aus, als wuerde an der libopencm3 schon seit Jahren nichts mehr gefixt und USB-Host ist da auch nur ein grosses, schwarzes Loch :-(
Da muss ich mich aber doch mal fragen - was sind das fuer Leute, die so
Software schreiben und in dieser Form abliefern?
You get what you paid for...
Haben die schon mal was davon gehoert, dass man "trailing whitespaces"
auch weglassen kann? Oder sind da satanische Botschaften per
whitespace-steganographie drinnen versteckt, wenn man den code
rueckwaerts liest?
Das dürfte an Editor liegen, wenn man ein Tab gesetzt hat, und sich dann für einen Zeilenumbruch entschieden hat.
Das ist doch so nervig, wie wenn du im Grossraumbuero einen Kollegen
hast, der sich andauernd raeuspern muss.
Soll er halt was trinken.
Was soll diese bescheuerte Pseudo-doxygen-dokumentation ueber den
Funktionen?
Genau solche Kommentare, die nur nochmal wiederholen, was
da dann eh' eine oder ein paar Zeilen spaeter in C steht, sind doch ein
Negativbeispiel, wie man gerade nicht coden soll.
Nö, es ist eine Überschrift für das was danach kommt.
Was ist einfacher zu lesen / zu verstehen? Kryptischer Quellcode oder ein Satz in prosa?
Ich hatte echt versucht, diesen Kackhaufen zu umgehen. Aber dummerweise
siehts so aus, als wuerde an der libopencm3 schon seit Jahren nichts
mehr gefixt und USB-Host ist da auch nur ein grosses, schwarzes Loch :-(
Wie wäre es, das Repo zu forken, die Macken zu beheben und es der Allgemeinheit zur Verfügung zu stellen?!
In dem Quellcode fehlen noch auskommentierte oder nicht verwendete Riesen-Funktionen.
Keil bietet für sein mdk eine USB-Host-Lib an.
Kostet zwar was, entspricht aber wohl eher deinem Geschmack.
Ich hatte echt versucht, diesen Kackhaufen zu umgehen.
Wenn du diesen Kackhaufen erst mal richtig kennengelernt hast
wirst du vielleicht merken wie dir das Programmieren in der
CubeIDE erleichtert wird. Dazu hast du noch die freie Wahl
entweder LL- oder HAL-Libraries zu verwenden. Frei nach Ge-
schmack sogar wild gemischt.
Oder redest du nur von den vielen Beispielen die dir in der
Cube-Firmware mitgeliefert werden?
Ansonsten kommt mir noch der Spruch in den Sinn: Wasch mir den
Pelz aber mach nicht nasss.
Da muss ich mich aber doch mal fragen - was sind das fuer Leute, die so
Software schreiben und in dieser Form abliefern?
Das sind Leute, denen man nicht genug Zeit für ein perfektes Denkmal gibt. Das ganze muss billig produziert werden, da es kaum messbaren Gewinn abwirft.
Warum STM32Cube? Wenn man möchte, kann man die Controller auch mit direkten Zugriffen auf die Register programmieren.
Einzig zum Einstellen der internen Takte nimmt es einem etwas an Arbeit ab, solange diese im weiteren Programmablauf unverändert bleiben sollen.
Muss halt automatisch nebenbei entstehen. Die Firma könnte einen
Buchautor in Vollzeit gebrauchen, aber der kostet ja Geld.
Nee, das ist Quatsch. Bei den schwachsinnigen Doxygenueberresten (siehe mein Bild im 1. Post) kommt eh' keine verwertbare Doku raus. Genausowenig wie bei schwachsinnigen Kommentaren im Stil von:
1
/* inkrementiere i */
2
i++;
Und nicht recht viel anders ist das ja, was mir da auffaellt.
Also spart da simples, komplettes Weglassen auch Zeit und minimiert Tastaturabnutzung ;-)
Im uebrigen gibt's ja durchaus auch Doku, die mir jetzt auf den 1. Blick ganz vernuenftig vorkommt, z.b. UM1720 (User manual STM32Cube USB host library).
Genialerweise ist die natuerlich nicht im repository, sondern man darf sie sich dann separat runterladen und gucken, ob das dann irgendwie zu den sourcen passt...auch seeehr clever. Und die sieht so ueberhaupt nicht aus, als ob da mit doxygen oder anderen Generatoren gearbeitet worden waere, sondern eher, als haette das ein "Buchautor in Vollzeit" geschrieben.
Das rausschmeissen von trailing whitespaces kann man automatisieren, kostet also auch nicht wirklich Zeit. Muss man einmal machen, dann ist Ruhe.
Und jaaaa, ich weiss, kost' nix, darf man auch nicht meckern. Doch. Darf ich. Tu' ich auch. Macht mich rot.
Nee, das ist Quatsch. Bei den schwachsinnigen Doxygenueberresten (siehe
mein Bild im 1. Post) kommt eh' keine verwertbare Doku raus.
Naj, selbst bei sowas kommt was raus (auch wenn die Kommentare nicht wirklich sinnvoll sind).
Das (* incrementiere i *) ist natürlich die Krönung einer erfolgreichen code-review. :-)
Ja, finde ich auch super. Aber nicht, um richtige Dokumentation zu bekommen, sondern um ahnungslose Projektkasper in Sicherheit zu wiegen (Ja, sicher - wir verwenden doxygen, damit ist sichergestellt, dass die Dokumentation immer zum aktuellen Code passt <harhar>).
Und mal ehrlich - z.B. die Doku von der libopencm3 ist bestimmt mit guter Absicht so entstanden. Aber das Bild - auch mit dem Kontext von:
https://libopencm3.org/docs/latest/stm32f4/html/group__CM3__systick__file.html
hilft doch wirklich nicht weiter, oder?
(Was mir da viel mehr weiterhalf, war libopencm3-examples.)
Was natuerlich sinnvollerweise zu einer Warning fuehren kann (und bei mir im Gegensatz zur Standardeinstellung in der CubeIDE auch tut):
1
warning: declaration of 'hhcd' shadows a global declaration [-Wshadow]
Und was natuerlich komplett gelogen ist, denn hhcd ist alles, aber keine "Private variable", sondern heftigst global(, wie der gcc im Gegensatz zum STM32-Coder weiss).
Das wird dann auch im Interrupthandler (10 files weiter und wo ganz wo anders) ausgenutzt:
1
voidOTG_FS_IRQHandler(void)
2
{
3
HAL_HCD_IRQHandler(&hhcd);
4
}
Interrupthandler, die mit Argumenten aufgerufen werden muessen. Das nenn ich mal ein weiteres innovatives Konzept. Hut ab!
Ja, so ein Kackhaufen, hau wech die Scheisse und kauf dir was
Gescheites.
ja, das schrieb ich auch schon:
Rahul D. schrieb:
Keil bietet für sein mdk eine USB-Host-Lib an.
Kostet zwar was, entspricht aber wohl eher deinem Geschmack.
Nachdem meine Fassungslosigkeit ueber insbesondere die Middleware/USB-Device von ST sich immer weiter manifestierte (USB-Host lief bei mir so làlà, aber Device war mittlere Katastrophe) - auch die runtergeladenen .pdfs ueber diese Middleware eher nur weitere Fragen aufwarfen (z.b. welche callbacks oder sonstwas von meinem eigenen code wird aus einem Interrupt aufgerufen und welche nicht, etc.), war das Kraut entgueltig fett:
Wie mir hier angeraten, haute ich die Scheisse wech. Und siehe es war gut - denn ich hab's durch TinyUSB ersetzt: https://docs.tinyusb.org/en/latest/
OK, Dokumentation ist eher ziemlich spaerlich, aber im Gegensatz zu der ST-Middleware gingen da bei mir ruck-zuck die mitgelieferten Beispiele (Host /und/ Device) zu meiner vollsten Zufriedenheit.
Hurtig eines der vielen unterstuetzten Boards(stm32f411blackpill), was meiner HW am naechsten kam, ausgesucht und soweit (clk, pll, pushbutton-gpio) angepasst, schon liefen die Beispiele. Vieel weniger K(r)ampf als mit dem ST-Kram.
Der src ist sehr angenehm zu lesen und ich bin noch ueber keine whitespaces an bekloppten Stellen oder triviale Kommentare gestolpert.
OK, warum die TinyUSBs sich bei ihrem Buildsystem so viel Muehe gegeben haben, besonders gut zu verschleiern, mit welchen Optionen die verschiedenen Files gebaut werden, kann ich nicht nachvollziehen, aber man kann halt nicht alles haben...Sponge over, wuerde da der Nativespeaker sagen.
Dafuer bin ich von deren Codequalitaet und ihren Beispielapplikationen deutlich begeisterter - echt kein Vergleich zu ST.
usbd_conf.png
(86 KB)
