Is Steves or the Genric core better suited?
If you could let me know it would be appreciated.
Thanks
[Nutsy – Thu Aug 02, 2018 10:32 am] –
Ive just come across a project that might require me to build on the Nucleo STM32L4 based board, and I’m unsure where this chip sits in regards to support, is it fully implemented like the f103? or lesser like the f4?Is Steves or the Genric core better suited?
If you could let me know it would be appreciated.
Thanks
Check out GrumpyOldPizza’s work here: https://github.com/GrumpyOldPizza/arduino-STM32L4
I believe that the effort is rather mature.
Ray
It already supports several Nucleo-32, Nucleo-64, Nucleo-128 boards. It is fairly simple to add any other Nucleo board.
The L476 is a very versatile chip. It can run at a reasonable speed or go slowly for reduced power consumption.
David.
[Nutsy – Thu Aug 02, 2018 7:50 pm] –
hmm having a little look in there, not to fault oldpizza, im not sure its mature enough for the project… might tell the lead to move to f103 just for simplicity on that front…
Interesting … What are you missing in there ?
In my experience, grumpyoldpizza’s core is much more stable and mature than the “official” STM core for the STM32L4.
If you report them, they can be solved for other users and the world in general.
Likewise, I am sure that grumpyoldpizza might offer advice. This is the way that Open Source software works.
Personally, I think it is important that an Arduino core can be produced for most STM32 chips fairly easily. The popular boards are supported by default. Yes, this involves HAL abstraction.
David.
[david.prentice – Fri Aug 17, 2018 6:38 am] –
What problems did you have with the official core?If you report them, they can be solved for other users and the world in general.
The goal of the official core (well, done by Wi6Labs, not really by ST … so how is that any more official than any other ?) is to support as many chips/boards as possible using the ST HAL implementing the minimum functionality required by Arduino. Upside is that pretty much every Nucleo board sort of works …
The soul of the STM32L4 (and STM32L0 for that matter) is to have a ultra low power Arduino Core that offers USB CDC/HID/MSC, a robust FAT file system, Serial NOR support (via a embedded FTL, so that USB MSC can really use it as a block device with wear leveling; QSPI to have faster transfer). Async IO for USB/UART/I2C/SPI, so that you can background IO and put the CPU core to sleep. There is bazillion of other features embedded that go far beyond the minimum requirement. The downside (besides complexity) is that not every board under the sun is supported.
If anything with the STM32L4 does not work (and I cannot test everything all the time, nor can I anticipate every use case), please tell me, raise a flag.
However I got to admit that currently I am focused more on STM32L0 / LoRaWAN work, so things will not happen that quickly.
[GrumpyOldPizza – Fri Aug 17, 2018 2:09 pm] –
well, done by Wi6Labs, not really by ST … so how is that any more official than any other ?
Just a quick thought, originally, Wi6Labs have made one core for some series (not all)… Then ST (unfortunately mainly myself) based on users feedback’s has implemented the current one. Wi6labs is no more involved in the support since several month.
About “Official”, you’re right The right terms would be “Officially supported by ST”.
[david.prentice – Fri Aug 17, 2018 6:38 am] –
What problems did you have with the official core?If you report them, they can be solved for other users and the world in general.
Likewise, I am sure that grumpyoldpizza might offer advice. This is the way that Open Source software works.
Personally, I think it is important that an Arduino core can be produced for most STM32 chips fairly easily. The popular boards are supported by default. Yes, this involves HAL abstraction.
David.
I have actually contributed back to grumpyoldpizza’s core regarding 2 minor (and quickly fixed) bugs, and yes I could probably contribute towards fixing the ‘official’ core as well, but unfortunately I don’t have time at the moment. My board freezes quite easily with the ‘official’ core even with extremely minor code changes so it might take a lot of time to locate and fix. I might take that time eventually, but since my board works so well with grumpyoldpizza’s core there’s little need for me to do so.
Nothing against the ‘official’ core, understandably it’s a challenge to code a flexible core for several STM families and it will take some more time to mature and get more features, so I’ll keep it in my radar In the meantime I’m enjoying using grumpyoldpizza’s core and haven’t had to use the debugger in a very long time
What I meant was that the f103 baite is a bit more tried and tested and perfectly powered for this project. Less room for error… and much cheaper and easier to get hold of.