STM32

[ataradov]

So how much influence does Bocsh have? yes they wrote the standard but that is different from how a peripheral works

They designed the IP and Atmel licensed it. They probably did not feel like reinventing the wheel.

You can find the datasheet from Bosch that has the same exact text as Atmel datasheet. It would be somewhere here https://www.bosch-semiconductors.com/ip-modules/can-ip-modules/, but I can't find it now. I know I had it somewhere.

Well, I guess I'm blind. The link is right on that page https://www.bosch-semiconductors.com/media/ip_modules/pdf_2/m_can/mcan_users_manual_v330.pdf

[Simon]

I see. I guess they did the works then as they invented the standard.

[thm_w]

By the time I have read the HAL with the manual for the chip and then worked out what the HAL does, yea, i may as well write my own.

That's what a lot of people were telling you from the beginning. This is always the case. And it will be the case in the near future.

Let me know when you've got that SD card DMA based driver running and then we can talk about that always being the case.

[ataradov]

Let me know when you've got that SD card DMA based driver running and then we can talk about that always being the case.

There is nothing hard about SD cards with DMA. Yes, it is not trivial. Nothing with DMA is trivial. But it is not hard. And if the stock driver just happens to work for you, then it is great. But if it does not, then you are truly screwed.

My job is to support people that are in the second category. And based on that experience I will not change my opinion. In all cases I'd rather spend time and effort upfront to create code that I know.

But I also have years of experience doing that, so big flowcharts don't really scare me. Your mileage may vary, of course.

[thm_w]

There is nothing hard about SD cards with DMA. Yes, it is not trivial. Nothing with DMA is trivial. But it is not hard. And if the stock driver just happens to work for you, then it is great. But if it does not, then you are truly screwed.

My job is to support people that are in the second category. And based on that experience I will not change my opinion. In all cases I'd rather spend time and effort upfront to create code that I know.

But I also have years of experience doing that, so big flowcharts don't really scare me. Your mileage may vary, of course.

There is where the difference lies. You are selling your services and time, and future support. In your case re-writing is very likely justified, and often is even required for various internal requirements.

OP and me are using the chip for hobbyist purposes (AFAIK), and would not be paid for our efforts rewriting drivers.
Rewriting will take more time to get up and running for SDHC, there is no question about that. Other peripherals may vary.

[ataradov]

There is where the difference lies. You are selling your services and time, and future support. In your case re-writing is very likely justified, and often is even required for various internal requirements.

Well, not really. I work for Microchip supporting their frameworks (among other things). I get paid even if nobody is having issues. I don't see that happening though.

My opinion is based on the things I do for hobby and side projects.

[Berni]

Yep DMA is one of the strong points of CubeMX and HAL.

Not only does it help you set it up trough a more friendly to use graphical interface, but it also makes sure all the ducks are in a row in terms of all the things it needs. It gets the clocks and everything running, it keeps track of DMA channels, the peripheral knows what the correct DMA channel is, wires up any events or interrupts as needed... etc. Most peripherals also have dedicated functions in the HAL driver for DMA use where the function does everything.

And yet you still have to know what you are doing because modern ARM chips may have multiple RAM regions, not all DMA accessible, so you have to take care your code puts the DMA buffer arrays on the right spot in RAM. Then these modern CPUs also have decently sized cache (Just memory is no longer fast) so you need to also know what you are doing there or the cache and RAM will go out of sync (DMA writes directly to RAM, bypassing cache), so it means flushing the correct parts of cache in the correct moments or using something like the MPU to create non cachable regions of RAM for DMA use.

Knowing how to deal with all this is all part of being an embedded programmer. With more processing power comes more complexity so there is a learning curve as it is with everything. Just wait til you see how complicated FPGA+SoC chips are.

[nuclearcat]

Honestly using CubeMX, CubeIDE is plain suicide.
Even with their nice GUI and DMA and etc, it is equal to shooting your own leg and putting huge risks using in your product their crappy code.
In my experience, these bugs will get you at the most unexpected moment and they will be very painful.
Take as example this problem: https://github.com/STMicroelectronics/STM32CubeF1/issues/6
And look what is their final answer, then they got cornered:
"The new F1 series' firmware has not been released yet and will not be in the near future."
So, product is still supported, problem is trivial and known how to fix, but hey, "swallow that dear customer", we wont fix it, but we will fix it for other chip model.

P.S. What made me exceptionally angry, their malloc is broken in FreeRTOS. If you try to printf your code will hardfault, if you are lucky enough (thats what is most scary, it has random chance and will hit your project at worst moment).
They know about problem 7 month+, there is community proposed solutions, but here we go, they are "discussing".
https://community.st.com/s/question/0D50X0000BB1eL7SQJ/bug-cubemx-freertos-projects-corrupt-memory

[Simon]

I'm not using any HAL systems at all from anyone. I have come to find that HAL's are not documented or poorly documented at best. To use a HAL you have to understand the chip because you have to read the HAL code as the documentation so without knowing what stuff is you are wasting your time. So by the time I have worked out how the chip works I can write my own bloody code. I have settled on the SAMC series from Atmel at the moment.

[dtodorov]

My few cents on this topic.

I've never worked as a FW designer professionally, only as a hobbyist for rather simple projects. I' started with MPLAB IDE, then shortly CCS, then MPLAB X, then arduino, then mbed online compiler stuff, then Atmel Studio,  then I bought a bag (literally) of stm32's for dirt cheap and decided to check out what ST offers.

So at that moment in time I first saw the CubeMX and Atollic, later combined to CubeIDE. To me it seems OK and I mostly find what I need inside. In fact, the HAL provided is not really a high abstraction, to me it's merely a collection of functions as driver you don't need to write. But at the end, I expect if you want to do efficient/fast/small code you need to know your peripherals and registers and so on and exploit them according to your needs. It's hardly conceivable a single generic high-level abstraction layer of code will be able to that. Or maybe it can, I've just never seen it.

I am basically fully OK to use the CubeIDE for now, it's got everything I need at this moment in life. 

[Simon]

My take on ST is that they are aiming at the market segment of every cent saved counts. The entry level chips with CAN are M0 not M0+ and there is 0 documentation for the HAL. Because it's not high level like you say I have to understand the chip in detail. At which point i am most of the way there. Relying on a HAL means that it becomes the reason to use that vendor - not for me. I want to use the chip i like not the chip that comes with a HAL I like. So I am using the SAMC, not too expensive but very well featured. I don't have to worry about saving a few cents on a part like a micro controller, sure I'll not go and use something that costs £55 but give or take a dollar on a chip I'll pick the one that I can work with and that I like.

[hansd]

What are you going to use to develop software for the SAM MCU's?

I have just used STM32CubeIDE using the STM32F405RG 168MHz 1MB Flask 128K Ram. J-Link EDU for debugging. Technologies used in this test ADC-DMA (DMA fills a Buffer from ADC conversion), SPI for a little OLED display, PWM to drive a little motor, UART for communication (sending commands etc) using the HAL framework. Changing things in CubeMX then code generation many times. I must say it just worked.  Would I use it for big projects? Properly not.

Then I did the same thing with libopencm3 on multiple IDE's. The first thing I noticed was that the OLED display did not work anymore. I had to slow down the software controlled CS.
 
I think ST has affordable tools (from Dual Core right across the range). The CubeIDE can be used without CubeMX and HAL. You can also write your own header files and drivers.

Not sure if you want to use the SAM for professional use?

[Simon]

why, what wrong with SAM?

[hansd]

Nothing wrong with ex Atmel. I am just interested. Is it for hobby use?

[Simon]

No it is not hobby use. The SAMC series looks to be squarely aimed at the automotive market. As for "ex" Atmel, in acquiring them Microchip also acquired an ARM licence and a line of ARM platforms they never had themselves. It's not like they have to compete with existing Microchip ARM platforms.

[Siwastaja]

What are you going to use to develop software for the SAM MCU's?

Exact same tools as for any ARM MCU, that's the strength of ARM microcontroller "ecosystem", really:

* Device-specific manuals and datasheets
* Any code editor of your choice (either text editors, or IDE if you want. The key: don't use manufacturer-specific IDE distribution!)
* gcc-arm-none-eabi, binutils, etc.
* gdb and openocd, if you want/need debugging

You only need the tools installed once! A new project can be for any ARM MCU manufacturer.

Once you learn this mindset, you are free to jump between any ARM MCU with very little hassle, and have enormous selection of devices available. And, by not using the example libraries, you are not limited in functionality but can do anything the chips are physically capable of.

What's best, most of these tools have stayed basically the same for 3-4 decades and will stay the same. No need to re-learn the workflow all the time, only learn the new technical details of new peripherals and the new CPU features when they occur. And it's not that often.

Don't ruin this by limiting yourself to the trend-package-of-the-year-for-a-specific-manufacturer.

[Simon]

Well you have to learn each chip. Really I could not give a stuff what the CPU is, it's capabilities are the least thing that impact my choice of chip. It's the I/O and peripherals that matter. And it's the peripherals that take up all of my time to learn and write low level drivers for.

[Karel]

What are you going to use to develop software for the SAM MCU's?

Exact same tools as for any ARM MCU, that's the strength of ARM microcontroller "ecosystem", really:

* Device-specific manuals and datasheets
* Any code editor of your choice (either text editors, or IDE if you want. The key: don't use manufacturer-specific IDE distribution!)
* gcc-arm-none-eabi, binutils, etc.
* gdb and openocd, if you want/need debugging

You only need the tools installed once! A new project can be for any ARM MCU manufacturer.

Once you learn this mindset, you are free to jump between any ARM MCU with very little hassle, and have enormous selection of devices available. And, by not using the example libraries, you are not limited in functionality but can do anything the chips are physically capable of.

What's best, most of these tools have stayed basically the same for 3-4 decades and will stay the same. No need to re-learn the workflow all the time, only learn the new technical details of new peripherals and the new CPU features when they occur. And it's not that often.

Don't ruin this by limiting yourself to the trend-package-of-the-year-for-a-specific-manufacturer.

I'm trying to but I'm not able to write a linker file from scratch myself.

So, what I did is I used STM Workbench IDE to generate a project which I abandoned but I took (and modified) the linkerfile and makefile.
Now I don't use any IDE anymore but I'll have to when I switch to another MCU.

Are you able to write linkerfiles?

[Siwastaja]

Are you able to write linkerfiles?

Yeah, but I admit there was a learning curve. That curve was made much steeper than necessary because I followed a tutorial which gave false advice, and non-working linker script examples; having no tutorial at all would have been better. (The mistake was, it initialized the stack pointer to a value multiple of four, but not a multiple of eight, which is a requirement for some ARM instructions.) ALIGN() is your friend...

You don't need to do it completely from scratch - there is nothing wrong in looking at examples and modifying them to your needs, as long as you understand what they are doing, and what you want to do. Learning from autogenerated code and modifying it sucks, though, because it tends to be far from understandable or optimal.

After the initial hassle, I have had no issues. I routinely use the multitude of memory sections modern devices (above the most simple M0 devices) offer: different flash sectors (for erase granularity, storing data that keeps over firmware updates), core-coupled memories (standard ARM ITCM, DTCM, or vendor-specific), battery backup RAM, etc. All of this is extremely simple and work the same way once you understand how you enter the memory regions: just understand the linker script syntax, enter the memory map as shown in the device datasheet. It has worked the same way for decades, and will work the same way for decades to come, and is the same for all manufacturers. Finding the memory map from the right datasheet pdf is the biggest task, and may take as much as 5 minutes.

I recognize the biggest obstacle is in the lack of documentation: basically good examples and simple tutorials. Requiring people rely on autogeneration on a point-and-click gui is, IMHO, damaging. I'm OK with it being an optional extra, but it's sad how lacking the documentation and tutorials are.

My makefiles are just a few lines. Similarly, my peripheral init code tends to be 1/10th of lines of the equivalent autogenerated thing, and can be actually modified. There is very little magic in compiling for ARM microcontrollers. Stuff autogenerated by IDEs and code configurators make it look complex. Autogenerators are like a workaholic who terrorises the company by doing excess work to demonstrate he's irreplaceable.

[thinkfat]

Once you understood what "sections" are and how they are mapped to memory locations, and what the difference between a file offset and a load address are, linker files themselves are easy.

The complexity is mainly in understanding what the compiler spits out and where to put it.