How do I build a solid understanding of how to develop STM32xxx applications?

[magene]

I've been slowly learning how to develop apps using STM32L4R9 and STM32F4xx MCUs. I just went through a really painful experience trying to develop an app that talks to a UART device and logs data to the SD card on the STM32L4R9-Discovery board that reinforces the fact I just don't know enough of the basics. Using VisualGDB and/or STM32CubeIDE, I have successfully written polled, interrupt and DMA UART apps based on various example I found on the web using HAL. I was also able to get the STM32 CubeMX FatFs_uSD_Standalone example working in a separate app. But it took 4 hours to combine a UART app and the SD app into one app that could get data from a UART connected device and log it to the SD card. I had 2 fundamental problems. 1) Finding all the right .h and .c files and including them in the right places. 2) figuring out how to initialize all the clocks, the UART and the SD interface so they didn't interfere with each other. Even though I got it working, I still don't feel like I have the basic background knowledge I need. I don't mind putting in the time to build up this background but I haven't found an effective process yet.

So my basic question is how do I, and how did you experts, build up the basic knowledge so getting the infrastructure of a new app up and running isn't so painful and I can concentrate on programming the actual functionality the app needs? Books, classes, consultants, or is it really just this painful?

[waclawek.jan]

Reading and writing. Yes it takes time.

Pain is a state of mind. Find a project which will fulfill you and you then enjoy the time spent with it.

Keep in mind that "writing to SD card" is a complex process and you did not program that, you've just slapped together some other's code. I personally find blinking a LED (perhaps controlled through UART for extra fun) to be a much more rewarding task, but YMMV.

JW

[Mr_M_from_G]

Hi magene,

I agree with Jan that it is a long way and I fully agree with his sentence "pain is a state of mind". Digging into these detail can also be very fascinating.

I started with microcontrollers about thirty years ago, with Intel 8051. All we had was the ref manual and an oscilloscope or some LEDs and editors were not what they are today and there was no IDE. This forced us to read the manual and try for ourselves what happens in reality if we set this or that bit in some register. At that time getting a UART running was a job of several days and logging data to a SD card (which did not yet exist at that time) would have been a project for weeks or months.

But being forced into details made us learn thorougly. This kind of learning is not possible when you use CubeMx and HAL (sorry ST folks but this is really a drawback of these tools). So my advice if you really want to learn would be to try things for yourself with only the manual and program directly to the registers, ie not to use CubeMx and HAL. Or dig into the routines that CubeMx generates until you see how they set the registers and then look up in the manual what that does. Best for this is to start with a given project because getting a naked microcontroller running nowadays is really a hard job. Look for a simple project as Jan said. Blinking an LED with a timer interrupt and control the blinking frequency through UART characters is quite a project for a beginner. And start with a simple controller. Even a timer or UART peripheral in a high end controller is pretty complex today.

Good luck

Martin

[TDK]

> But it took 4 hours to combine a UART app and the SD app into one app that could get data from a UART connected device and log it to the SD card.

This seems like a reasonable amount of time, given your experience.

I just learned by creating applications, and because I enjoy programming, I tolerate the frustration that inevitably comes up and stuck with it. If you don't enjoy it (and you're not getting paid to do it), it's going to be a tough road.

STM32CubeMX is great for understanding how the clocks are setup and how to assign pins to peripherals. You can make your own choice about whether to use their generated code or not.

When you run into a problem, check the reference manual or Google it. You'll build a foundation of knowledge slowly but surely.

> Books, classes, consultants, or is it really just this painful?

I would argue that aspects of programming are always going to be painful. For me, the reward of creating a working program is satisfying enough to balance it out.

[magene]

Thanks for the input, I was hoping there was some magic "Learn STM32" pill but your comments confirm what I was thinking. Mr_M's suggestion to "dig into the routines that CubeMx generates until you see how they set the registers and then look up in the manual what that does" makes a lot of sense. I am being paid to do this but I'm a mechanical/electrical engineer with only a modest amount of programming experience but embedded programming hasn't been my main job. I also get a lot of satisfaction from creating working apps but right now I'm getting stuff to work in a way that is too random to make me feel good about my process.

Since I am being paid for this and time is my most valuable resource, I'm trying to get up the learning curve as effectively as possible. One option that I think would be very cost effective would be to work with an expert STM32 embedded engineer for a couple of days to get my (small) team up the learning curve more quickly. If anyone knows of a consultant that might fit that bill, I'd be happy to hear recommendations.

[Tesla DeLorean]

People tend to underestimate the complexity of integrating things. A lot of the pieces that ST provides need testing, and then portions refactored so they fit together, and do error propagation and error recovery better. Failing into an infinite loop is usually something I can't do in reality. Most of the examples have the singular goal of demonstrating a piece of hardware works, at least to the point that someone can say "see it works", and then tell you to go fish.

My approach to this is to ingest a lot of technical material from different perspectives, and triangulate to a solution. I know how the HW and SW work and combine, so I can write everything from scratch if I need too, and I don't need to cut-n-paste my way to a solution. I'm also pretty good at static-analysis, so I can see flow and failure by inspection.

Not been one for classes, learn at lot about things/methods that don't work on the forum.

One can easily dump dozens of man-hours into things, the trick really is to not waste that time, or repeat the work. Time spent reviewing the reference manuals and code examples is not wasted. Have file search/inspection methods so you can find related information quickly, especially when finding source code illustrating modes of operation matching or closely related, and which confirm details in the manuals, or fill in gaps.

Automate processes you're going to have to repeat, even if doing it once takes longer. You'll understand the process better, and it scales.

[magene]

For anyone looking at this thread in the future who may be looking for a good STM32 development reference to start with, I bought this and it has already proven really, really useful. Well worth the investment.

https://leanpub.com/mastering-stm32