Moin Moin, nachdem ich mich jetzt fast 4 Jahre CubeMX-IDE und insgesamt HAL verweigert habe, hab ich die neueste Version mal wieder ausprobiert und bin geschockt. CubeMX fand ich zum (Pin-)Konfigurieren schon immer gut - der Code war fraglich, aber konnte man als Richtschnur für eine saubere nicht-überladende Firmware auf StdPeriphLib als inspiration nehmen. Naja, wollte ich den Workflow mal testen, wie es sich STMicro so "gedacht" hat. Wie üblich CubeMX gestartet, kleinen STM32L011 konfiguriert, aber es scheitert am Generieren des CubeMX-IDE-Projects. Code wird generiert, aber Fehler bei der Projekterzeugung, obwohl Project-Files vorhanden. Neueste CubeMX-IDE gestartet, Projekt importiert - Config für Debugging und Kompilieren orphand, also kaputt. Das IOC-File erkennt die IDE auch nicht mehr (das ging früher schon alles, als ich es mal getestet hatte). Naja gut - also Makefile generieren und in Eclipse CDT + GnuARM importieren - da geht dann auch Debuggen. Man muss allerdings mühsam erstmal noch die trace_printf aus anderen Projekten in das HAL-Projekt migrieren, damit man printf über openocd auf dem Host machen kann. WTF wieso ist das nich gleich bei HAL dabei - war es damals nicht und scheint es immer noch nicht zu sein. Ok, also Hello-World funktioniert ... Sorgfältig meinen TIM2 mit PWM und Output auf PA5 konfiguriert. Geht nicht ... Es fehlt HAL_TIM_Base_Start, dann rennt zumindest der TIM2. Dann fehlt noch ein HAL_TIM_PWM_Start, dann gibt es auch PWM auf dem Output. Lange Rede kurzer Sinn, ich hab mich gestern unendlich über diesen Mist aufgeregt ... Während man vor 4 Jahren noch tollerant sein konnte, weil ja alles neu war, gibt es jetzt keine Entschuldigung mehr dafür. CubeMX 5 + CubeIDE 1.2 haben zumindest noch funktionierende Projekte erzeugt - CubeMX 6 + CubeIDE 1.4 ist nur noch broken. Unglaublich ... kopfschüttel Also zurück zu Eclipse + Gnu-ARM + OpenOCD und der StdPeriphLib ... Hoffentlich sieht es STMicro mal ein und wirft ihren kaputten Kram weg. Viele Grüße, Mampf
Mampf F. schrieb: > Also zurück zu Eclipse + Gnu-ARM + OpenOCD und der StdPeriphLib ... > Hoffentlich sieht es STMicro mal ein und wirft ihren kaputten Kram weg. Die IDE finde ich ganz gut, mehr brauch ich nicht. Dieses CubemX gedöns nutze ich auch nicht. Neues Projekt anlegen, direkt Code generieren und alles was mit HAL und CubeMX zu tun hat sofort löschen. Dann hat man einen sauberen SourceCode.
Ben S. schrieb: > Mampf F. schrieb: >> Also zurück zu Eclipse + Gnu-ARM + OpenOCD und der StdPeriphLib ... >> Hoffentlich sieht es STMicro mal ein und wirft ihren kaputten Kram weg. > > Die IDE finde ich ganz gut, mehr brauch ich nicht. Dieses CubemX gedöns > nutze ich auch nicht. Neues Projekt anlegen, direkt Code generieren und > alles was mit HAL und CubeMX zu tun hat sofort löschen. > > Dann hat man einen sauberen SourceCode. Welche Definitionen benutzt du dann für Registerzugriffe etc? Kann mich mit CubeMX auch nicht anfreunden weil sie die Hardware für mich nicht wirklich abstrahiert sondern nur einen undurchsichtigen Grauschleier über die Register legt. Ständig muss man in der HAL nachsehen welche Bits nun durch eine Funktion gesetzt werden. Ich frage mich ob das irgendwo produktiv eingesetzt wird?
Andreas F. schrieb: > Welche Definitionen benutzt du dann für Registerzugriffe etc? Ich behalte die CMSIS, die generiert wird und arbeite ausschließlich (bis auf komplexe Peripherie wie USB oder Ethernet) auf Registerebene. Andreas F. schrieb: > Ich frage mich ob das irgendwo produktiv eingesetzt wird? In fertigen Industrieprodukten hoffentlich nicht. SIch mit Registern rumzuschlagen dauert ggf. 1 oder 2 Tage mehr, ja - dafür hast du keinen fehleranfälligen fremden komplexen Sourcecode und verstehst wirklich was passiert und kannst bei eigenen Fehlern direkt zielgerichtet eingreifen.
:
Bearbeitet durch User
Beitrag #6431354 wurde von einem Moderator gelöscht.
Ben S. schrieb: > und arbeite ausschließlich > (bis auf komplexe Peripherie wie USB oder Ethernet) auf Registerebene Ich nehme den Mittelweg und habe mittlerweile so viele Libraries für Peripherie unter SPL, das ich einen Teufel tun werde und mir HAL antue (ein Monsterprojekt letzten Winter ist schuld daran). Die paar Bugs in der SPL sind inzwischen bekannt und den heißen Scheiß aus der neuesten HAL Edition brauche ich nicht. Ich hatte mich schon damals über 'Processor Expert' für die Freescale Chips geärgert, weil es eine Qual war, in dessen Code noch eigene Funktionen einzubauen.
:
Bearbeitet durch User
Ben S. schrieb: > Ich behalte die CMSIS, die generiert wird und arbeite ausschließlich > (bis auf komplexe Peripherie wie USB oder Ethernet) auf Registerebene. Wie gehst du denn dann z.B. mit USB um? z.B. USB Vendor. Ich bin zwar mit dem SAM4 unterwegs, aber im laufe der Zeit fiel mir auch soviel in der ASF auf, dass es bei UART/ SPI usw. ja recht einfach ist (Registerbezogen) zu arbeiten, aber USB? Da hab ich mich immer drum gesträubt.
:
Bearbeitet durch User
Adam P. schrieb: > ie gehst du denn dann z.B. mit USB um? > z.B. USB Vendor. Wie ich bereits sagte: CubeMX Projekt mit USB CDC z.B. anlegen, Code generieren und dann wirklich alles rausschmeissen, was nict zur Funktion des USB benötigt wird. Am Ende lande ich dann bei ein paar HAL Bibliotheken, einem Interrupt und bisschen Middleware vo ST. Das sind dann wirklich nur wenige Aufrufe aus meinem sonst aus Registerzugriffen bestehenden Code.
Adam P. schrieb: > aber USB? Habe ich mir zwar ein ASF-Projekt erzeugt, aber dann den Code selbst geschrieben. Läuft ganz brauchbar, macht CDC + MSC (für eine angeschlossene Micro-SD-Karte).
Ben S. schrieb: > wirklich alles rausschmeissen, was nict zur Funktion > des USB benötigt wird. Ah ok, ich dachte du greifst dann auf externe Layer zu (Segger oder sonstige erprobten).
Jörg W. schrieb: > aber dann den Code selbst > geschrieben. Ja das hab ich auch bei vielen Dingen gemacht, da der ASF Layer z.B. für die SD-karte auch nicht ganz vollständig war oder SPI gar kein DMA unterstützte - aber USB schien mir so "gewaltig" :)
Adam P. schrieb: > aber USB schien mir so "gewaltig" Vermutlich wäre meine Implementierung noch nicht so ganz USB-zertifizierungsfähig (da vermute ich ASF deutlich näher dran, was diverse corner cases betrifft), aber am Ende sind das genannte CDC+MSC ca. 2000 LoC. Ein USB-Bus-Analyzer war allerdings bei der Implementierung und dem Debuggen mehr als hilfreich. ;-)
Jörg W. schrieb: > Ein USB-Bus-Analyzer war allerdings bei der Implementierung und dem > Debuggen mehr als hilfreich. ;-) Ja kenn ich :-D - LogicAnalyser für Low-Level - HHD Device Monitoring Studio für den Rest
Jörg W. schrieb: > Ein USB-Bus-Analyzer war allerdings bei der Implementierung und dem > Debuggen mehr als hilfreich. ;-) Sorry für OT, aber wissen ja: Wer debuggen muss, der kann nicht programmieren ;) ..
:
Bearbeitet durch User
Ich bin am Debugger gerade nochmal vorbeigekommen - in meinem Projekt wollte ich an die HS Engine (USB-A Buchse) Massenspeicher andocken und an der FS Engine (USB-B) ein CDC Device haben. Das mühseligste war dabei aber, die doppelten Bezeichnungen beider USB Definitionen einzigartig zu machen - eine reine Fleissarbeit.
Adam P. schrieb: > Ben S. schrieb: >> Wer debuggen muss, der kann nicht programmieren ;) > > :-D > > Müssen? ...Man möchte. Er hat auf W.S. angespielt der debuggen bis aufs Messer verteufelt und die Leute als Nichtskönner beschimpft, die Debugger nutzen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.