Is there another way?

[luch]

I am a very patient man. I've spent the last 2 days (not hours! entire days!) studying this 'simple' example from Cube1 (HAL_TimeBase_RTC_ALARM). The example is irrelevant: I've experienced the same with other examples...

So, I'm looking at these files, started digging from main and the rabbit's hole took me very, very far... I found things that are not even mentioned in the (i.e.) Reference Manual... but I digress.

I've been fighting, trying to make some sense of it, with a wall of 38 files and 28064 lines, standing between me and the micro. And this is just a little example program! I am jumping thru this mountain of 'define's and going nowhere. There are people really determined to declare and name and rename and rename and rename things to death. What I don't see on these screen is 'action'. Or real C!

At the end of the day(s) one could gather all that blah-blah-blah (isn't HAL suppose to make our life easier?!) into a handful of instructions that would fit on a screen!

Are all of you, guys and girls, going thru the same? How do you deal with all this sh..oftware?

Is there another way? Or am I just stupid?

[Willunen]

Yes, we are all going through (or went through) the same process. I'm a hobbyist too and I too came from the AVR world (and long ago the Motorola world) In the AVR world I ran away from the Arduino libraries as soon as possible as those too were unreadable for me and I wrote to the bare registers.

When I migrated to the STM32's I wanted to do the same, using CMSIS. So like this "TIM1->DIER |= TIM_DIER_UIE;" This makes you have to read the Reference Manual AND the CMSIS "libraries" very well.

After some time I discovered STM32CubeMX which I first used for the pinout only. Later I tried the HAL code but didn't like it. I bought a book "Mastering STM32" by Carmine Noviello only to find out he uses the HAL exclusively. So I went on using CMSIS.

Until I found out that STM32CubeMX could generate LowLayer code. And I have to admit that I like that, it is simple, does just the initialization of the peripherals and nothing more. It is close enough to the hardware but (I think) it is more human readable, like this "LL_TIM_SetTriggerInput(TIM3, LL_TIM_TS_TI1FP1);" Of course you still have to have the Reference Manuals AND the Datasheets handy at all times.

Unfortunately STM32CubeMX does not always generate complete initialization (at least in LowLayer mode). As an example, the settings for the RTC Calendar are completely ignored in the code it generates.

I share your aversion against the examples, they are written in the most abscure way as far as I'm concerned. It also seems like they wanted to use just the Nucleo's / Discoveryboards and no other parts. Eg. see the I2C examples.

I do the same as waclawek.jan does, write many small programs to test just one peripheral, and sometimes that still takes me days (not hours) I guess that's just the way it works.

[luch]

Thanks Wilko!

Yes, I agree with you about CubeMX generating LL code - it does not cover everything, but it's much more efficient than HAL.

I'm trying the same approach as you and Jan - to write many simple programs and study every peripheral... Unfortunately, after more than a week on this, I am still at the setup stage: choosing the tools to use and creating a minimal program with the basic initialization of the micro. Then, knowing what set of instructions to use, to start experimenting. I'm slooooowly getting there!

[Willunen]

Oh, the tools. For IDE software I started with Keil uVision but now it is Atollic TrueStudio combined with STM32CubeMX. The hardware is ST-Link-V2 and Segger J-Link EDU. And the controllers themselves, a mix of STM32F030, F100, F103, F407, L031 and L431 bought through Farnell or Ebay. I'm moving away from Ebay because of the fakes and recycled junk. But at this moment I'm still playing with a "blue pill" STM32F103. I have some Discovery and Nucleo boards but I don't like the Morpho- and Arduino pinout so I rarely use them.

[luch]

I am using uVision - the limitations don't bother me at this point - mostly because the clear structure of the program and the debugger. I use a ST-Link-V2 for debbuging and have a few boards with F100, F103 and a L476. The little, cheap and widespread BluePill doesn't get much support from these tools - I found no example projects for it - speaking of bias...

[turboscrew]

I, too, prefer to not use libraries, although in this I used <stdint.h>.

https://github.com/turboscrew/rpi_stub