Ich habe hier ein STM32L053 Nucleos Bord. CooCox bietet da nur noch die STM32Cube Lib und nicht mehr die alte Lib an. Bei ST habe ich auch nur noch die Cube Lib für den STM32L053 gefunden. Schwenkt ST jetzt wirklich so hart auf die STM32Cube Lib um? Oder war ich zu doof, für den STM32L053 die alte Lib zu finden? Jetzt hat man sich etwas an die alte Lib gewöhnt und schon muss man sich wieder umstellen. Durch meine alten Projekte müsste ich ja dann mit der alten und der neuen Cube Lib leben. Gruß Ingo
Sorry, aber hänge mich hier mal hin. Gibt es nur Libs im Style von ST, also irgendwelche Strukturen befüllen die über Registern gelegt werden, oder hat schon jemand weiter gedacht.
Es ist doch sehr unwahrscheinlich, dass ST zwei Bibliotheken pflegt und in deren Forum gibt es Threads, die ebenfalls davon ausgehen, dass die SPL tot ist.
Ingo Stahl schrieb: > Schwenkt ST jetzt wirklich so hart auf die STM32Cube Lib um? > Oder war ich zu doof, für den STM32L053 die alte Lib zu finden? Es ist doch offensichtlich, dass sie das tun. Guck mal wie das auf der Website beworben wird. Seit kurzem gibt es nun für alle STM32 die HAL/Cube-Libraries, auch die alten STM32F1. Ich nutze die HAL-Libraries seit einiger Zeit und kann mich eigentlich nicht beschweren. Alles was ich brauche läuft problemlos. Die CubeMX-Software habe ich aber noch nie benutzt. noreply@noreply.com schrieb: > Gibt es nur Libs im Style von ST, also irgendwelche Strukturen befüllen > die über Registern gelegt werden, oder hat schon jemand weiter gedacht. Was heißt "weiter gedacht" konkret?
Ingo Stahl schrieb: > Durch meine alten Projekte müsste ich ja dann mit der > alten und der neuen Cube Lib leben. Das wäre doch jetzt die Gelegenheit, ganz auf solche Libs zu verzichten.
Schaulus Tiger schrieb: > Das wäre doch jetzt die Gelegenheit, ganz auf solche Libs zu verzichten. Was ich mir im Falle von USB, SDIO etc. nicht unbedingt antun würde..
Neben dem "Strukturen füllen und an API übergeben" gibt es auch das CMSIS, was in der Firmware-Lib versteckt war und direkt die Register enthalten hat. Das dürfte es auch weiterhin geben.
The STM32Cube HAL Layer is the replacement of the Standard Peripheral Library. The HAL APIs offer a higher abstraction level compared to the standard peripheral APIs. HAL focuses on peripheral common functionalities rather than hardware. The higher abstraction level allows to define a set of user friendly APIs that can be easily ported from one product to another. Customers currently using Standard Peripheral Libraries will be helped through Migration guides. Existing Standard Peripheral Libraries will be supported, but not recommended for new designs.
drama schrieb: > Was heißt "weiter gedacht" konkret? Ich bin halt in der objektorientierten Welt und ich mag Typsicherheit. Manche Libs interessiert das überhaupt nicht, manchmal versucht man mit assert das selber zu programmieren. Ich würde auf Klasse stehen. PureADC, SingleShotADC, ContinousADC z.B. Die Flags dann mit setter setzen. Mit getter die Rückgabeflags in boolean zurückgeben. Aber wahrscheinlich ist das nicht effektiv genug.
Schaulus Tiger schrieb: > Das wäre doch jetzt die Gelegenheit, ganz auf solche Libs zu verzichten. Schau mal nach ChibiOS. http://www.chibios.org Cheers
Ingo Stahl schrieb: > Jetzt hat man sich etwas an die alte Lib gewöhnt und schon muss man sich > wieder umstellen. Siehste, so geht es einem, der sich auf sowas wie diese ST-Lib eingelassen hat - anstatt sich seine Peripherie-Treiber selber zu machen und dann unabhängig zu sein. Ich habe mich hier schon vor langer Zeit über dieses ST-Unkraut ausgelassen - aber die, welche eben nicht hören wollen, dürfen sich jetzt eine andere Kandarre ins Maul stopfen lassen, womit sie ab morgen in eine andere Richtung gezwungen werden. OK, vielleicht hat ST ja inzwischen den selbstangerührten Unsinn erkannt und macht es jetzt tatsächlich besser. VIELLEICHT... Dabei war das bisherige Zeugs doch so offensichtlich miserabel (Strukturen im RAM befüllen, die der Quasi-Treiber dann zu einem Wert wieder zusammenklatscht, ohne daß sich irgend eine echte Abstraktion dabei ergeben hätte), daß es mich immer wieder verwundert hat, daß es Leute gibt, die das unreflektiert benutzen. noreply@noreply.com schrieb: > Ich würde auf Klasse stehen. PureADC, SingleShotADC, ContinousADC z.B. > Die Flags dann mit setter setzen. O je. Hältst du sowas wirklich für eine Verbesserung? Ich nicht. Ich hätte allenfalls einen eher unanständigen Namen für sowas. Mal ganz im Ernst: Objekte haben genau DORT ihren Sinn, wo es eine Vielzahl von Dingen in der Software gibt, die vom übergeordneten Programm aus gleich behandelt werden sollen (weil sie äußerlich das Gleiche tun), obwohl ihre innere Struktur unterschiedlich sein kann. Beispiel: grafische Objekte auf einem Display. Dreiecke, Vierecke, Kreise.. aber alle müssen sich zeichnen können, alle müssen eine Koordinate haben und so. Objekte sind Software-Angelegenheiten und keine Hardware-Angelegenheiten. Hardware geht anders und ist NICHT objektorientiert. Oder kannst du per New.Create(USB_Core) dir einen weiteren USB-Anschluß in deinen Controller zaubern? W.S.
Bisher habe ich die alte Lib beim Initialisieren von komplexer
Peripherie eingesetzt. Nicht aber für die einfachen Sachen, wie Bit
setzen oder UART Register auslesen.
Wenn man mehrere unterschiedliche Typen einsetzt, wird eine eigene Lib
auch recht aufwendig.
Die kürzeste Variante habe ich in der Demo von ChaN's FAT Lib gesehen:
#define __gpio_conf_bit(p,b,f) p[b/8] = (p[b/8] & ~(0xF << ((b % 8) *
4))) | (f << ((b % 8) * 4))
oder
#define __enable_peripheral(p) (&RCC_AHBENR)[p/32] |= 1 << (p % 32)
oder
#define FCLK_SLOW() { SPIx_CR1 = (SPIx_CR1 & ~0x38) | 0x28; } /* Set
SCLK = PCLK / 64 */
---
Habe eben mir eine STM32F05x Cube Lib gezogen und auch mal das STMCubeMx
Tool ausprobiert. Also begeistert bin ich nicht. Das ist eher nicht
besser, aber anders. Das Zusammenklicken aller Konfigurationen ist auch
recht aufwendig. Der Vorteil kommt wohl erst bei Einsatz einer Anwendung
auf unterschiedlichen STM32 Varianten zum Tragen.
---
Gruß Ingo
W.S. schrieb: > Siehste, so geht es einem, der sich auf sowas wie diese ST-Lib > eingelassen hat - anstatt sich seine Peripherie-Treiber selber zu machen > und dann unabhängig zu sein. Du redest hier so, als ob ST jedes Jahr eine neue Sau durchs Dorf treiben würde. Die SPL gibt es seit vielen Jahren - und nun kommt eben was Neues. Wäre es dir lieber, wenn ST die eigene Software nicht weiterentwickelt? Der Umstieg ist übrigens gar nicht so schwer und die alte SPL kann man natürlich auch weiter nutzen...
Die alte SPL ist weder Fisch noch Fleisch, zu wenig echte Abstraktion, eher sinnfreies Hin-und Herschieben der Bits. Der Sinn hat sich mir auch nicht erschlossen - habe mein erstes STM32 Projekt (zugegebenermaßen klein, aber schon fast alles dabei: I/O, PWM, Timer, SPI, Interrupts, DeepSleep bzw. StandBy) ohne die Lib gebaut. In die Eigenheiten des jeweiligen HW-Moduls muss man sich ja sowieso einarbeiten um es richtig zu nutzen. Sollte mit dem neuen Modell eine echte Abstraktion stattfinden, ist das immerhin ein Stück vorwärts, auch wenn es natürlich auf die Performance geht...
LTC1043 schrieb: > Schau mal nach ChibiOS. > > http://www.chibios.org Danke, das ist wirklich eine Alternative zur STM32-Lib und man bekommt ein RTOS gratis dazu ;) Ich wollte es einsetzen und alles, was ich ausprobiert hab', hat auf Anhieb funktioniert. Solange man mit den angebotenen Funktionen auskommt, ist alles bestens. Wenn man aber genauer wissen will wie es funktioniert, steht man vor einem #define-Urwald. O.K., es soll portabel sein, aber mehr als 3 Makro-Ebenen müssen doch nicht sein? Und trotzdem wird ein großer Teil der Funktionen unnötigerweise übersetzt und erst vom Linker wieder rausgeworfen. Aber damit kann man leben. Gescheitert ist es letztlich an der Lizenz, obwohl eine Erweiterung der GPLv3 sogar das Linken mit nicht-GPL-Code erlaubt -- allerdings darf man dann nichts am RTOS ändern. Das muss man aber, weil mehrere while(1)-Schleifen eingebaut sind. Ein Teil davon lässt sich per #define umleiten, aber nicht alle. Alternativ müsste man (wegen der GPLv3) dem User die Möglichkeit geben, den STM32 neu zu flashen. Den Quellcode könnte ich schon noch mitliefern, aber was ist mit der nötigen Infrastruktur?
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.