STM32 - Page 1
Forum section: electronics / general

author: Simon
author_rank: Unknown
timestamp: January 08, 2020, 10:16:29 am
content: 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!

author: Berni
author_rank: Super Contributor
timestamp: January 08, 2020, 11:29:13 am
content: 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.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: January 08, 2020, 11:35:08 am
content: Quote from: Simon on January 08, 2020, 10:16:29 amHmm, not sure about that... depends on how you define "good" I suppose. These sort of tools tend to be a constantly moving target. Youwillend 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.

author: Karel
author_rank: Super Contributor
timestamp: January 08, 2020, 11:38:06 am
content: Quote from: Berni on January 08, 2020, 11:29:13 amI couldn't agree more.

author: Simon
author_rank: Unknown
timestamp: January 08, 2020, 12:02:23 pm
content: 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: January 08, 2020, 01:12:51 pm
content: 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 withCAN bus before.

author: Berni
author_rank: Super Contributor
timestamp: January 08, 2020, 01:31:33 pm
content: 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.

author: Simon
author_rank: Unknown
timestamp: January 08, 2020, 02:09:02 pm
content: 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.

author: llkiwi2006
author_rank: Regular Contributor
timestamp: January 08, 2020, 02:10:20 pm
content: Quote from: Simon on January 08, 2020, 12:02:23 pmI 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.

author: Simon
author_rank: Unknown
timestamp: January 08, 2020, 03:10:03 pm
content: Yea, but what about the rest of the hal and which one of the 3 is it and will they support in the future?

author: Simon
author_rank: Unknown
timestamp: January 08, 2020, 03:44:54 pm
content: 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.

author: Berni
author_rank: Super Contributor
timestamp: January 08, 2020, 04:38:10 pm
content: 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).

author: Simon
author_rank: Unknown
timestamp: January 08, 2020, 04:40:55 pm
content: 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?

author: ataradov
author_rank: Super Contributor
timestamp: January 08, 2020, 06:21:37 pm
content: Quote from: Simon on January 08, 2020, 02:09:02 pmBuffers are allocated as arrays in C. So C compiler/linker will not allocate overlapping areas. This is not a problem at all.Quote from: Simon on January 08, 2020, 02:09:02 pmHere I provided a very simple CAN bootloader for SAM C21https://www.eevblog.com/forum/microcontrollers/can-on-atsamc21j18a/msg2493300/#msg2493300. The amount of CAN initialization code is pretty minimal.

author: Simon
author_rank: Unknown
timestamp: January 08, 2020, 06:51:29 pm
content: Quote from: ataradov on January 08, 2020, 06:21:37 pmthey 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.

author: Berni
author_rank: Super Contributor
timestamp: January 08, 2020, 09:24:16 pm
content: 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.

author: thm_w
author_rank: Super Contributor
timestamp: January 08, 2020, 11:16:54 pm
content: Quote from: Simon on January 08, 2020, 04:40:55 pmWith 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.

author: Smokey
author_rank: Super Contributor
timestamp: January 09, 2020, 12:22:47 am
content: 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.

author: Berni
author_rank: Super Contributor
timestamp: January 09, 2020, 06:24:11 am
content: 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\ExamplesAlso 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\SrcI 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.

author: Simon
author_rank: Unknown
timestamp: January 09, 2020, 07:56:51 am
content: 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: January 09, 2020, 11:01:12 am
content: What chip do you have? I could perhaps send some bare metal snippets.

author: Simon
author_rank: Unknown
timestamp: January 09, 2020, 12:40:50 pm
content: 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

author: krish2487
author_rank: Frequent Contributor
timestamp: January 09, 2020, 04:38:15 pm
content: @simonYou 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.

author: FlyingDutch
author_rank: Regular Contributor
timestamp: January 11, 2020, 02:50:21 pm
content: Quote from: Jeroen3 on January 08, 2020, 01:12:51 pmHello,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=591I 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

author: FlyingDutch
author_rank: Regular Contributor
timestamp: January 11, 2020, 02:56:19 pm
content: Sorry I forget to say: You have to register a free account to read post on given forum.Regards

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 11, 2020, 03:50:14 pm
content: Quote from: Simon on January 09, 2020, 12:40:50 pmAs I've said in other threads, if you're going to use the HAL, start with looking at all the example projects that come with the download instead of fiddling with the Cube app first. They are categorized by peripheral/functionality.I know many despise STM32's HAL, but I think it's actually not that bad especially when you're starting with STM32 MCUs, and I've done a few useful things with it. All the source code is provided, so you can look at how things are implemented.

author: Simon
author_rank: Unknown
timestamp: January 11, 2020, 03:53:54 pm
content: Well i was put back onto the idea of STM by a subcontractor work use who first told me about all their ballsups of the past but now says that it has matured into a usable solution. The last thing i want for example is that I write a project and them update the HAL and find that names of things have changed and my code stops working.

author: SiliconWizard
author_rank: Super Contributor
timestamp: January 11, 2020, 05:24:06 pm
content: Quote from: Simon on January 11, 2020, 03:53:54 pmI have never seen that happen with the HAL, usually STM is pretty cautious about not breaking things like that. So you may find the HAL "bloated" (the code size is not tiny indeed), but it seems decently maintained. (Now bear in mind I've mostly used the L4 series so I can only talk for the HAL for L4, but I think it's pretty similar across series...)

author: Simon
author_rank: Unknown
timestamp: January 12, 2020, 09:27:43 am
content: I think it was some time ago but I think there have been situations where a chip is made with one UART, so all registers are called UART. then they want to put more uarts on so it becomes UART0 and the code breaks.

author: Berni
author_rank: Super Contributor
timestamp: January 12, 2020, 02:43:25 pm
content: Well it is pretty difficult to make a universal peripheral library work across all chips. New chips keep coming out that might do something in a slightly different way that the existing library is not made for and so it needs changing.Some things are actually done pretty well in HAL, like having functions with the word IT in front for things that are interrupt driven so you can clearly see what to use. It provides built in mutexes and locks to prevent problems with multithreading and interrupts. Even sets up DMA for you if you use appropriate functions.But then there are a lot of little things that make me facepalm. Like flipping a GPIO pin between input and output requires you to allocate a whole gpio pin init structure, fill that structure and then pass it in to the init function to have your pin reconfigured. Some peripherals also hold on to this init structure in RAM as part of the hal peripheral struct that holds the state of the peripheral. While i do applaud them for using simply a C struct to store this (Rather than making a C++ class for the same thing) that init structure can sometimes be over a kilobyte in size and has no use anymore after the init function finishes setting up the peripheral according to your wishes. I would much prefer the init would only do the very basic things to get the peripheral running and then have you call separate things like HAL_GPIO_SetMode(GPIOC, 10, GPIO_INPUT_PULLUP)Then there are things where the HAL library is built to work well with a very specific use case in mind, yet this use case is something really niche and rare, while the most common use case is not supported at all. One such thing is you can ask to receive a certain number of characters from UART, depending on how you call it you can have the function wait as a blocking call, interrupt you or DMA them somewhere, notifying you when done and stopping receiving. This is great if you expect exactly 10 characters to arrive just after this call. But if you want to constantly receive? Well you could always keep asking for 1 character but the UART stops receiving when its done with 1 character and only starts receiving again once you call the receive function again so you will loose any characters that arrive in that time. Are you kidding me?!Then you get things that are implemented without any thought as to there use case at all. Like having I2C with DMA. Sounds great since I2C is awfully slow so you don't want to wait around for data. Well turns out this is only really useful if you want to transfer a big block read of data as it will only do one operation at a time. It won't let you automate the usual I2C dance that happens before the read transfer (Adress the slave, write to address, restart, adress slave, read, get data...). My solution was about a 100 line long function that takes in a structure of instructions for the I2C to do and executes them in interrupts by direct poking of bits in hardware registers. Works great and will read data from multiple I2C chips, doing it from a single function call all in the background. Versus the many thousands of lines of code of that crappy HAL I2C library.All feels like the HAL library was written by a bunch of high level programmers used to writing C code for Windows, following a checklist of implementing something for every peripheral in blocking, interrupt and DMA mode before moving on. None of those programmers having actually used any MCU peripheral libraries, having no idea what embeded programmers actually want a device driver to look like.Still HAL is a great way of getting something up and running quickly and to get you familiar with the peripheral. Then you can slowly rewrite parts of the HAL library to actually do it in a proper way.

author: Simon
author_rank: Unknown
timestamp: January 12, 2020, 02:58:52 pm
content: Quote from: Berni on January 12, 2020, 02:43:25 pmWell lets face it embeded programming seems to be a niche. Few books on it, no courses. I guess it's the programmers trying to do electronics by using an arduino all over again

author: Jeroen3
author_rank: Super Contributor
timestamp: January 13, 2020, 07:34:50 am
content: Quote from: SiliconWizard on January 11, 2020, 05:24:06 pmYou're right. Before HAL I had a different name. StdPeriph.Quote from: Simon on January 12, 2020, 02:58:52 pmThere is nothing wrong with trying to get some abstraction. Especially since embedded processors are getting more and more capable.The design of HAL is broken, it should have been C++, but that wasn't economically viable since the world still uses C. So they went with the device driver model, but they can't separate kernel from userspace, so it became what it is today. Redundant abstraction.The best part is the sample code generator and IO and clock tree.

author: Simon
author_rank: Unknown
timestamp: January 19, 2020, 01:02:47 pm
content: I have set up a simple project with CAN and GPIO enabled in the Cube IDE using the HAL. So just looking at the only header file i can find for the GPIO things are not clearly explained. I can see the gist of things but nothing is explicitly explained. I take it that in declaring a function that has no parameters leaving the parenthesis out is OK? if so that explains one small thing i was not expecting to see. I get the impressions that to understand this clearly i will need to thoroughly understand the registers anyway at which point why was I using the HAL again? Am i missing some documentation somewhere?

author: Jeroen3
author_rank: Super Contributor
timestamp: January 19, 2020, 03:17:03 pm
content: Well yes, as I said before. The HAL is redundant abstraction. You still need to know about the specific functions of each pin. The only thing the HAL does it put the choices into drop-down menus and give your some limited feedback of illegal options.

author: Simon
author_rank: Unknown
timestamp: January 19, 2020, 04:55:05 pm
content: what drop down menu? I can scarcely see what the functions are that i should write to enact any of the code. If this header file that I have found is the "public interface" then it is bloody awful as it carries no documentation at all. All that I have read in several books is that the c file is "private" and the header file will expose what is "publicly" available to be used in the application and is to have any documentation.Going by that I have nothing and would find it faster to just read the manual and write my own driver thanks. Is the rest of it that useless?

author: Karel
author_rank: Super Contributor
timestamp: January 19, 2020, 05:02:09 pm
content: Quote from: Simon on January 19, 2020, 04:55:05 pmFormally you are correct. And with closed-source software that comes as libraries and headerfiles, this is usually the case.With open-source software however, documentation can be found often in the comments in the *.c files.

author: Simon
author_rank: Unknown
timestamp: January 19, 2020, 05:13:42 pm
content: OK, I will give that a read but it still does not make sense because i don't care to read a load of code i am not interested in. I just need to know how to drive it. Even the couple of libraries I wrote for myself although I documented the how it works in the C file for my own sanity to avoid confusion I explained clearly in the header file how to use it. It's also how C works. Variables that are internal to the library stay in the C file but variables that are global allowing the library to interact with an application were declared in the header so that there was no confusion about which was which.

author: ataradov
author_rank: Super Contributor
timestamp: January 19, 2020, 06:23:35 pm
content: What you are finding for the N-th time is that vendor supplied code sucks. It always does. What you need to decide is the level of suckiness you are willing to accept.You will always have to read the code to understand. Writing code and documentation is a cost center, which directly contributes to the final price of the product. And in a world where you sort by price on Digi-Key, it is unrealistic to expect vendor to put more effort than bare minimum required.

author: Jeroen3
author_rank: Super Contributor
timestamp: January 19, 2020, 06:29:23 pm
content: Quote from: Simon on January 19, 2020, 04:55:05 pmThe drop down menus in the STM32CubeMX java application of course!Are you working with a proper editor? Go useVisual Studio Codeand use that Go to Defintion button (F12)

author: Simon
author_rank: Unknown
timestamp: January 19, 2020, 07:34:10 pm
content: Quote from: ataradov on January 19, 2020, 06:23:35 pmWell I'm trying to understand it and see if I am happy using the HAL. If the GPIO is relatively well documented in the C file and there are more comments there than in the header file then perhaps I am happy with this level of suckiness. I am just trying to work out if the HAL is documented enough to work with or if I should barre bones it. the STM32F0x1 appears simpler than the SAMC. However ultimately if I was ever to use a more complicated micro controller the HAL may be more essential so best figure it out on the simple stuff first then be able to apply it on the more complicated stuff.

author: Berni
author_rank: Super Contributor
timestamp: January 20, 2020, 06:30:39 am
content: There is documentation for the HAL drivers, for example here:C:\Users\<Username>\STM32Cube\Repository\STM32Cube_FW_F7_V1.5.1\Drivers\STM32F7xx_HAL_Driver\STM32F779xx_User_Manual.chmTho it is just doxygen generated html documentation so anything you find in there is pretty much going to be also in the source code comments. But perhaps easier to flip trough. without the mountains of source code in the way.Best way to figure out how to use HAL is still the example code they provide. Just find the example that is the closest to what you need, copy paste it, modify to do what you need and done. Tho sometimes after messing around with it you come to the conclusion that HAL doesn't support this exact thing you want to do, so you go open the datasheet, look at how the peripheral works and add a extra driver function or two that does the thing, but still keep as much of the HAL as possible to avoid having to make a driver from scratch.You will find drivers being shit for most 32bit MCU vendors.And it is with a reason. It is very difficult to write a high level driver for modern complicated peripherals that can cover all possible use cases, there are simply too many or the driver becomes too bulky and complicated. Its much easier to make a low level driver flexible while staying simple since it mostly just needs to give you access to all the raw settings, but the user of such low level drivers has to understand how the peripheral works in order to use it.In my opinion low level drivers are the way to go. You will need to look at the datasheet to understand the capabilities and limitations of your chip anyway, so might as well have a peek at the registers.

author: Simon
author_rank: Unknown
timestamp: January 20, 2020, 08:51:20 am
content: Well yes this is what I am wondering. By the time I have worked out how/if the HAL works I have learnt enough to just do it. The code does indeed seem quite bulky. I started to write my own low level drivers for the SAMC and comparing mine to the ST HAL they are much simpler to do the same thing and it all happens in a one line function not definitions all over the place and huge functions.

author: Berni
author_rank: Super Contributor
timestamp: January 20, 2020, 10:59:25 am
content: Its a lot easier to write a simple driver when you are writing it to do one job. But yes the STM HAL made it even more complicated than it needed to be.The way i tend to handle it is to write my own wrapper for a HAL driver. That way i can hide away its ugliness, make a sleek single purpose driver. Then i mix and match HAL functions and my own custom functions however needed. Usually using the HAL for init, but then making a custom sleek fast send or receive function for pumping data trough it, or code for running the peripheral trough interrupts and such.

author: thinkfat
author_rank: Unknown
timestamp: January 20, 2020, 04:40:08 pm
content: Quote from: krish2487 on January 09, 2020, 04:38:15 pmI've never looked at the STM32 HAL seriously, but the samples I found look very verbose. I much more like libopencm3, it's really a no-frills approach and pretty lean, IMHO. I've used SPI, I2C and USB peripherals so far, with and without DMA, no major problems.But the documentation isn't great. It's barely more than a list of functions and sometimes you need to read the code and the reference manual side by side to discover what a certain library function is doing.Of course it's not without its share of problems. Just recently some weird I2C code in one of the library functions would indefinitely block because a NACK condition wouldn't clear (it couldn't, the slave was in reset and wouldn't talk). Of course it was easily found with a debugger but it isn't an acceptable behaviour to block inside an endless loop on a common failure such as a typo in an I2C address.

author: Simon
author_rank: Unknown
timestamp: January 20, 2020, 05:37:32 pm
content: I'm thinking that the STM32F0 series are simpler than other ARM based µC's I have started to look at. I may as well just bare bones it. 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.

author: ataradov
author_rank: Super Contributor
timestamp: January 20, 2020, 05:44:25 pm
content: Quote from: Simon on January 20, 2020, 05:37:32 pmThat'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.

author: Simon
author_rank: Unknown
timestamp: January 20, 2020, 06:05:50 pm
content: when you look at the CAN peripheral of the SAMC you'd be glad of anythingI don't have a problem with GPIO stuff but if the HAL for the GPIO is near useless it's obviously going to be useless for CAN

author: ataradov
author_rank: Super Contributor
timestamp: January 20, 2020, 06:09:10 pm
content: I did look at CAN peripheral and I wrote a driver for it without too much trouble. It looks like a lot, but when you get down to it, and start filling out the registers, most of them are just filled with some constant like 0.Also, it is a standard BOSCH IP used by many other MCUs. There are all sorts of drivers for it out there.It also looks complicated because its overall design is different from other peripherals, since it was not designed by Atmel.

author: Simon
author_rank: Unknown
timestamp: January 20, 2020, 06:11:29 pm
content: Well I think I'll start working my way from GPIO to the UART and then tackle CAN.

author: Simon
author_rank: Unknown
timestamp: January 20, 2020, 06:20:16 pm
content: So how much influence does Bocsh have? yes they wrote the standard but that is different from how a peripheral works

author: ataradov
author_rank: Super Contributor
timestamp: January 20, 2020, 06:28:32 pm
content: Quote from: Simon on January 20, 2020, 06:20:16 pmThey 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 herehttps://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 pagehttps://www.bosch-semiconductors.com/media/ip_modules/pdf_2/m_can/mcan_users_manual_v330.pdf

author: Simon
author_rank: Unknown
timestamp: January 20, 2020, 06:39:22 pm
content: I see. I guess they did the works then as they invented the standard.

author: thm_w
author_rank: Super Contributor
timestamp: January 20, 2020, 11:11:37 pm
content: Quote from: ataradov on January 20, 2020, 05:44:25 pmLet me know when you've got that SD card DMA based driver running and then we can talk about that always being the case.

author: ataradov
author_rank: Super Contributor
timestamp: January 20, 2020, 11:16:07 pm
content: Quote from: thm_w on January 20, 2020, 11:11:37 pmThere 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.

author: thm_w
author_rank: Super Contributor
timestamp: January 21, 2020, 12:35:20 am
content: Quote from: ataradov on January 20, 2020, 11:16:07 pmThere 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.

author: ataradov
author_rank: Super Contributor
timestamp: January 21, 2020, 12:39:33 am
content: Quote from: thm_w on January 21, 2020, 12:35:20 amWell, 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.

author: Berni
author_rank: Super Contributor
timestamp: January 21, 2020, 06:24:33 am
content: 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.

author: nuclearcat
author_rank: Unknown
timestamp: April 29, 2020, 01:13:58 am
content: 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/6And 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

author: Simon
author_rank: Unknown
timestamp: April 29, 2020, 06:59:58 am
content: 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.

author: dtodorov
author_rank: Contributor
timestamp: April 29, 2020, 08:39:58 am
content: 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.

author: Simon
author_rank: Unknown
timestamp: April 29, 2020, 08:46:56 am
content: 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.

author: hansd
author_rank: Contributor
timestamp: April 29, 2020, 09:50:22 am
content: 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?

author: Simon
author_rank: Unknown
timestamp: April 29, 2020, 09:54:39 am
content: why, what wrong with SAM?

author: hansd
author_rank: Contributor
timestamp: April 29, 2020, 10:13:06 am
content: Nothing wrong with ex Atmel. I am just interested. Is it for hobby use?

author: Simon
author_rank: Unknown
timestamp: April 29, 2020, 10:32:07 am
content: 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: April 29, 2020, 12:29:25 pm
content: Quote from: hansd on April 29, 2020, 09:50:22 amExact 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 debuggingYou 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-4decadesand 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.

author: Simon
author_rank: Unknown
timestamp: April 29, 2020, 12:37:31 pm
content: 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.

author: Karel
author_rank: Super Contributor
timestamp: April 29, 2020, 03:29:33 pm
content: Quote from: Siwastaja on April 29, 2020, 12:29:25 pmI'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?

author: Siwastaja
author_rank: Super Contributor
timestamp: April 29, 2020, 05:57:32 pm
content: Quote from: Karel on April 29, 2020, 03:29:33 pmYeah, but I admit there was a learning curve. That curve was mademuchsteeper 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 forsomeARM instructions.) ALIGN() is your friend...You don't need to do itcompletelyfrom 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 itlookcomplex. Autogenerators are like a workaholic who terrorises the company by doing excess work to demonstrate he's irreplaceable.

author: thinkfat
author_rank: Unknown
timestamp: April 29, 2020, 07:19:43 pm
content: 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.