STM32

[Simon]

I have told that the STM software has reached a good state of maturity and makes setting things up on their MCU's much easier. This is good news as while I am happy to bare metal program it seems silly wasting time re inventing the wheel writing my own drivers when what I really need to spend time on is my application.

Does anyone have any advice on this? I did a mock up STM Cube setup and can't even get it into the IDE (granted i have not looked at documentation yet but when ST have two peices of software with the same name that work in tandem you would expect this to be fairly obvious).

The problem i have had in the past with trying to setup middlewares is that there is 0 documentation and looking at the code supplied itself can be challenging as it is tens of files often with one line of code, if I have to piece someone elses code together to work out how to use it then i may as well write my own thanks!

[Berni]

They merged everything recently into something called "STM32 Cube IDE". They just stuck the CubeMX utility as a plugin into the official STM32 Eclipse based IDE (That used to be Atollic TrueStudio IDE before they acquired them).

For some stuff CubeMX does a great job like setting up the clock generation and distribution trough a nice GUI (It gets complex on big chips with 3 PLLs and tons of peripherals...). It does a lot of the heavy lifting for middlewares like FAT32, TCP/IP, USB, RTOS... etc It helps with finding the right pins for your peripherals and sets up your pinmuxes and all.

The "HAL drivers" however are pretty crap. They are a over complicated mess that doesn't even do the job in the end. You get a I2C driver in the form of a C and H file with thousands of lines that are full of preprocesor defines that go 4 or 5 levels deep, making it a pain to understand what the driver actually does. And the reason i ended up digging trough the driver source code is to make it do a simple task that was not supported. Like for example I2C doing a start and stop condition instead of restart, or the UART not supporting a easy way to constantly read data like a normal serial port would.

The newer LL drivers are better in most cases, but still don't expect to never have to touch the driver or read the peripheral datasheet.

[donotdespisethesnake]

I have told that the STM software has reached a good state of maturity

Hmm, not sure about that... depends on how you define "good" I suppose. These sort of tools tend to be a constantly moving target. You will end up having to wade through installation issues and then "other peoples code" trying to figure out what it does. Auto-generated code can be particularly difficult to decipher.

Unfortunately, I think there is still no "magic bullet" when it comes to dev environments. Probably the best thing is to pick one and learn it thoroughly and resist the "grass is greener" thought.

[Karel]

For some stuff CubeMX does a great job like setting up the clock generation and distribution trough a nice GUI (It gets complex on big chips with 3 PLLs and tons of peripherals...). It does a lot of the heavy lifting for middlewares like FAT32, TCP/IP, USB, RTOS... etc It helps with finding the right pins for your peripherals and sets up your pinmuxes and all.

The "HAL drivers" however are pretty crap. They are a over complicated mess that doesn't even do the job in the end. You get a I2C driver in the form of a C and H file with thousands of lines that are full of preprocesor defines that go 4 or 5 levels deep, making it a pain to understand what the driver actually does. And the reason i ended up digging trough the driver source code is to make it do a simple task that was not supported. Like for example I2C doing a start and stop condition instead of restart, or the UART not supporting a easy way to constantly read data like a normal serial port would.

I couldn't agree more.

[Simon]

Well yes which is why i picked SAMC, did look at the plethora of startup code options between legacy atmel stuff and what microchip offer and it's poorly documented and not clear what is the one that will emerge.

My main issue is getting CAN to work. The SAMC datasheet section on CAN is well over 100 pages and complex, nothing like just getting the ADC or counters to work.

[Jeroen3]

CAN bus itself is relatively complicated. But the advantage is that almost all CAN controller works the same. There may be a slight design difference in how the actual data gets into your application, but otherwise they are all pretty much equal.

I can be overwhelming at first. Especially when you've never worked with CAN bus before.

[Berni]

CAN mostly just looks complicated due to the amount of features that most CAN controllers provide.

The controller can often crudely sort the incoming CAN traffic by itself. This is so that the device can prioritize the most critical messages by giving them a dedicated buffer that the code can treat with more urgency than other things. Less important messages might go in another low priority buffer and some messages might be ignored all together (There is often a lot of uninteresting other junk going trough the bus). The controller can also decide if to acknowledge the packet or not based on what you configure it for.

All this functionality makes it seam a lot more complex. But for just getting a CAN controller to send out a single message its usually just as simple as getting SPI or UART to send some data. You set it up during initialization and then just dump your data into the transmit register.

Still it does help a lot if you can find a simple minimalist example program for it. That way you can see what you actually need and what you don't.

[Simon]

I am familiar with CAN and yes the functionality is vast. A lot of pages in SAMC are about the setup of the buffers that go into RAM so you basically put RAM adresses into registers and make sure that you don't put them in so close that they overlap as nothing will tell you that you did that (unless the IDE helps you).

At the end of the day i want a standard setup that I set the ID of during initialization and then just give it data or respond to an interrupt for incomming data.

[llkiwi2006]

Well yes which is why i picked SAMC, did look at the plethora of startup code options between legacy atmel stuff and what microchip offer and it's poorly documented and not clear what is the one that will emerge.

My main issue is getting CAN to work. The SAMC datasheet section on CAN is well over 100 pages and complex, nothing like just getting the ADC or counters to work.

I have found that the can hal driver from atmel start (which is asf4 I believe) does work out of the box for simple stuff such as sending and receiving packets, and some filters on packets ids.

[Simon]

Yea, but what about the rest of the hal and which one of the 3 is it and will they support in the future?

[Simon]

Well, I have "set up" a chip in the cube IDE with CAN and UART enable. I think it has added the required code, I dunno. There is a box to tick that says do not generate main), i have not ticked it but not main(). I dunno. Usual thing, no obvious buttons to push to move through the project and probably 100 files i don't care about.

[Berni]

Its not supposed to guide you trough the process in any way. Its just a tool that you tell what you want so that you can hit the generate button and have it create a ready to go project for you.

You do typically want to let it create a main function as that main will contain all the calls to libraries that set your chip up regarding PLLs, IO pins, peripherals. You then just start adding code like you would if the CubeMX thing was not even there. Typicaly i like to create a new source file and call into it from the autogenerated main, since if you place code in the wrong place in these autogenerated files you risk getting your code overwritten the next time you hit generate again (And you need to click that if you make any changes to the CubeMX configuration like moving pins or peripherals around).

[Simon]

Well I did not get a main() file but I still don't know if the setup built, does it update files as I work through settings or do i have to click on a button to make it do that and where is it?

[ataradov]

and make sure that you don't put them in so close that they overlap as nothing will tell you that you did that.

Buffers are allocated as arrays in C. So C compiler/linker will not allocate overlapping areas. This is not a problem at all.

At the end of the day i want a standard setup that I set the ID of during initialization and then just give it data or respond to an interrupt for incomming data.

Here I provided a very simple CAN bootloader for SAM C21 https://www.eevblog.com/forum/microcontrollers/can-on-atsamc21j18a/msg2493300/#msg2493300 . The amount of CAN initialization code is pretty minimal.

[Simon]

and make sure that you don't put them in so close that they overlap as nothing will tell you that you did that.

Buffers are allocated as arrays in C. So C compiler/linker will not allocate overlapping areas. This is not a problem at all.

they warn you about it in the datasheet. Because you have to remember how long the data is and i think in one mode it's 32 bits in another its 64 or is it that given the 8 bit memory mapping if you forgot and used adjacent addresses you would have allocated only 8 bits to a 32 bit variable.

[Berni]

Yep this is classical C pointer stuff.

Feeding the wrong address or setting up any sizes incorrectly in any peripheral that can directly write to memory (DMA, CAN, Ethernet...) can have disastrous consequences of tramping over other data in RAM. But so can feeding the wrong parameters to basic C functions like memcpy or scanf.

Tho in terms of memory the newer big ARM M7 chips from ST can be quite complex. Some of them have multiple regions of SRAM that are connected trough different buses and bridges to the CPU and peripherals. This means you have to take care of how the linker script is set up so that the correct things end up in the correct RAM areas. It also means you have to be careful what RAM areas you use for buffers used by DMA or CAN because they can't access all of memory, or have performance penalties for some areas. Unfortunately CubeMX will not give you much help apart from helping you configure the memory protection unit in the CPU (that you will likely want to use for keeping these shared RAM areas from being cached incorrectly by the CPU and causing very annoying unpredictable bugs) But smaller chips with a single RAM areas don't have a lot of these problems.

In any case you still have to know what you are doing no matter how smart the IDE is.

[thm_w]

Well I did not get a main() file but I still don't know if the setup built, does it update files as I work through settings or do i have to click on a button to make it do that and where is it?

With CubeMX you change the setting and then hit "generate code", then it will go in and update all the .c/.h files. The Cube IDE may be different, but easy enough to check by looking for a setting (say a baud rate), changing it, then seeing if the file refreshes or not with the new number.

Keep in mind to only write your own code within the *user code* blocks or within your own included files, text outside those will be erased.

Also, use the HAL example projects as a reference (it will be extracted somewhere on your PC), trying to figure out what code/functions you need to use based on trial and error is not efficient. Although, it will force you to learn some of the underlying code and hardware, which is not necessarily bad.

[Smokey]

I'm actually really happy with the job ST is doing cleaning up the STM32 toolchain.  It was an absolute mess a couple years ago when I started a project.  I'm so glad they have an "official" toolchain now, and not the "here are a handfull of 3rd party options, you figure out what works best and how to get all the pieces to interoperate" silliness. 

About the HAL.  Is it bloated?  Yes.  Is it inefficient?  Sorta.  But what it does REALLY well is being mostly out of the box working "example code".
If the software dev cycle is: 1) Get it running.  2) Refactor and optimize., then the HAL gives you a jump almost straight into step 2.  You can tweak and remove and optimize as much as you want/need.  Your first shot at getting something functional will probably be worse than the HAL anyway and take way longer.
The other thing the HAL does is get very high level functions working that would literally take me partial years to understand and make functional, like USB.  I'm not going to even thing about touching the HAL USB stack, but I may tweak the HAL IO and SPI send/receive.

[Berni]

Yep you do need to click the Generate button on every change you make in CubeIDE. The CubeMX configuration tool does nothing to the IDE environment on its own. Its just a little built in application that reads that configuration file in the project directory(This is where all the pin and peripheral config is saved) and only once its told to generate it starts going trough all the generated source files and replaces them with new ones or updates project settings (include paths, compiler options...etc). This is also when any user modifications to the automatically generated source code files will be overrun and removed (Unless placed in designated user code areas shown by comments)

Examples are indeed a great help in learning how to use the HAL functions and can be found in a rather convoluted path, here is for example one such path:
C:\Users\<USERNAME>\STM32Cube\Repository\STM32Cube_FW_H7_V1.4.0\Projects\STM32H743I-EVAL\Examples

Also if you need to modify a source file that is part of the HAL (Had to do this to fix bugs in the HAL code, like form example Ethernet DMA being unable to transmit at all) you will need to modify the file in this repository to avoid your HAL modification from being overwrite the next time you clock Generate. This would be found for example in:
C:\Users\<USERNAME>\STM32Cube\Repository\STM32Cube_FW_H7_V1.4.0\Drivers\STM32H7xx_HAL_Driver\Src

I found i generally want to avoid reading HAL driver source code because its a needlessly complicated convoluted mess. For some cases what i ended up doing is just calling the HAL drivers Init function to get it to set up my UART or SPI or whatever, but right afterwards throw away the HAL memory structs and start talking to the peripheral directly trough registers.

[Simon]

I'll do some more digging. It would be nice to be able to use a HAL providing i don't have to reverse engineer anything as at that point I may as well just learn the bare metal of the chip.

[Jeroen3]

What chip do you have? I could perhaps send some bare metal snippets.

[Simon]

Well nothing other than a Nucleo-F091RC although if I do use STM32 it would be nice to figure out how to work with the HAL

[krish2487]

@simon

You can always have a look at libopencm3.
Its relatively less bloated than the official cubemx and has a fairly active community. It does take some getting used to.
but the API is fairly straightforward. I found it easier to work with libopencm3 than cubemx.

Just my 2 cents.

[FlyingDutch]

CAN bus itself is relatively complicated. But the advantage is that almost all CAN controller works the same. There may be a slight design difference in how the actual data gets into your application, but otherwise they are all pretty much equal.

I can be overwhelming at first. Especially when you've never worked with CAN bus before.

Hello,

I make "CAN 2.0 B"  and "CAN FD" working for STM32MP157A and STM32H7, STM32F7, STM32F4. I have CAN 2.0 (older) working and CAN FD (newer standard) working in mode of CAN 2.0 frame. If you want to look of code for "System Workbench for STM32" you can download "CAN FD" poject for STM32MP!x with this post on polish forum (it is my post):

https://forum.sunduino.pl/viewtopic.php?f=91&t=591

I hope that "Google translator" will translate this page to English properly. If you want CAN 2.0 (or FD) working project for STM32F7 or F4 I can send it to you later.
One have to familiarize and became accustomed to STM32CubeMX, but after some time I think it is tool that saves me much time in writing projects for STM32 MCUs.

Kind Regards

[FlyingDutch]

Sorry I forget to say: You have to register a free account to read post on given forum.

Regards