Rant... Why I dumped Platform IO IDE after a week

[tooki]

- There is pretty literally one guy answering questions on their forum. I hope Max is paid, because if he isn't I imagine there is an end to his generosity. This does not count as having someone to call on. Paid support for PIO is absurdly expensive at $250/mo with a 12 month use it or lose it contract. This iirc on the prices, is more than a year of IAR, Keil, and CLion together. That's some lunatic pricing.  (EDIT I swear last week they had a $500 per month no contract, but it's gone now)

It’s right there on the support page:

[peter-h]

I've complained about the horrible process that ST libraries go to set the baud rate for a long time.

As I've said, I don't think it is a simple divider, because you would not get 115200 with enough accuracy if the CPU clock was 16MHz, especially as this is usually divided by two first before getting to the UART baud rate setting. Bear in mind that the RX channel of a UART has to sample the data at some multiple of the baud rate, and "classically" this has been 16x. So you need to get 1843200Hz, with an accuracy of a few % of better. The divider is 8.68 which is a 3.5% error which is probably OK, but the 32F4 silicon is not doing that; they get a much smaller error. One can use a smaller sampling rate and it can work down to 4x, just about.

Here
https://www.eevblog.com/forum/microcontrollers/32f417-any-way-to-get-baud-rates-below-1200/msg3561821/#msg3561821

Anyway, this is digressing. The writeup is very good and shows that getting stuff working is much simpler than the "HAL" Cube IDE approach makes one believe. In the last year or so of working on this project I have done all new code directly. OTOH, there is a lot of RM reading, forum posting, and forum googling behind that... the learning curves are steep these days.

[wek]

I've complained about the horrible process that ST libraries go to set the baud rate for a long time.

But why here? Nobody hears you here.

And why do you use those "libraries", then?

Over at the STM32 forum, Clive (Tesla DeLorean these days) complained multiple times back then, and IIRC some progress was made. I don't follow.

But at the end of the day, this is quite relevant to this thread, too: the horrible process, as you've said, is horrible because it tries to cater for the clicking background, i.e. for both variants of oversampling and for the fact that users don't want to be bothered with the nasty details of setting up clocks (yes, APB prescaler, but in many newer STM32 models also a dedicated UART clock mux). Magic comes at a cost.

  I don't think it is a simple divider,

No, it's not, it's a fractional divider, as described in the RM. So, in your example, for 16MHz UART clock and 115200 desired baudrate you set it to 8+10/16 (you should correctly round it to 8 + 11/16 but let's not split hair that tightly here), that gives you 115942.0 Baud which is +0.6% deviation.

The transmitter doesn't need to be bothered, it simply divides by 8*16+10=138 and then spits out the next bit. Only the receiver sampler needs to be oversample 16x to have several samples close the bit middle for noise rejection. The way how receiver's sampler works is, that the divider divides the input clock by 9  ten times in 16 cases, and divides by 8 six times in 16 cases. This results in exactly 138 timer periods within the 16 sampling points, except that the sampling points are not placed regularly, with the worst case shift from ideal being around one clock period, which in all but the highest baudrates is negligible.

JW

[peter-h]

Nobody hears you here.

Nobody hears you anywhere. On the ST forum, there is (mainly) you posting good replies, and there is "Piranha" who tells you that you are a complete moron, then he might tell you something useful if he fell off the right side of the bed that morning, then he finishes off by telling you that you are a completely illiterate moron and an idiot. Tesla has not been seen much lately; I think he is getting tired.

This is the reality of developing with complex chips which the mfg does not support, and 2000 page RMs which nobody can read - well the people who can read them are those who already know most of it.

I've gone a long way up the 32F417 learning curve and this will last me for the rest of my life (actuarily speaking another 20 years). I am completely sick of it and will never do this again. Last few weeks sunk into fixing a subtle data loss issue on USB. I will re-use my board for every new product - which makes sense anyway. It's got everything I might want on it, and SPI for any expansion.

No, it's not, it's a fractional divider, as described in the RM. So, in your example, for 16MHz UART clock and 115200 desired baudrate you set it to 8+10/16 (you should correctly round it to 8 + 11/16 but let's not split hair that tightly here), that gives you 115942.0 Baud which is +0.6% deviation.

Right

[westfw]

I don't think it is a simple divider

it's a fractional divider, as described in the RM

And the way the math works out, and the way the bits are arranged in the register, once you put together the integer part and the fractional part, you get exactly the same results as the simple division gives you.

I didn't believe it myself when I first saw it - I figured I must have missed something that STPLIB went to all that trouble to calculate, so I wrote some PC-side C code to exhaustively test essentially all the values, using the ST code vs the simple division.  Identical.  Sigh.

And why do you use those "libraries", then?

I don't.  Actually, since that initial $1 ARM thread, I pretty much haven't used STM32s at all.
I've been preferring the Atmel/Microchip parts, mainly because of their popularity in the Arduino world.  (although they put the fractional part of the Baudrate divisor in the wrong place, so the math doesn't work out as well.)

[wek]

Nobody hears you here.

Nobody hears you anywhere.

If you're talking about answering questions, then maybe. Many of your questions are very specific ('F42x+RTOS+FreeRTOS in particular+lwip+one particular setting of lwip) and there's just so many people on the planet which possibly have the knowledge, not to mention time and willing, to answer you. The vast majority of questions on that forum is completely out of my range of knowledge, some are honestly too annoying to me to even read them ("I clicked USB in CubeMX and it ain't work").

But when it comes to suggestions to improve "libraries" and documentation, the ST crew listens. There, not here. Not in all respects, and some topics are simply no go, but generally they do.

[EDIT] here's some "proof": http://www.efton.sk/STM32/STM32F4xx_doc_errors.txt I used to maintain and brag about on that forum; most of that is already incorporated in RM0090

2000 page RMs which nobody can read - well the people who can read them are those who already know most of it.

And what's the chance of knowing most of it without having it read first?

I understand, that printed word with static pictures is not the perfect method to convey information, and I am also aware of the fact that different people perceive different sorts of information better. But I still believe that that's still the best method we currently have, from both the provider and the consumer point of view.

For example, the clock setup which was carried over from microXplorer to CubeMX is a widely praised feature; yet I personally find it way more cumbersome to use than to read the few dozens pages of RCC chapter (disclaimer, never actually tried CubeMX). Admittedly, I never used the 'H7 where the RCC complexity shot the roof to the sky, but I'd probably try to read first. Maybe this has something to do with the fact that the STM32 manuals are written mostly by non-english speakers as myself. Maybe this has something to do with the fact that I read unusually lot from early age and I enjoy it much. Maybe it's my aversion to primarily clicky software which deliberately and joyfully breaks the usual control rules. Maybe I'm just simply old. Maybe something else, I don't know.

Again, this has much to do with the IDEs vs. barebones discussion, too.

JW

[wek]

I've been preferring the Atmel/Microchip parts, mainly because of their popularity in the Arduino world.  (although they put the fractional part of the Baudrate divisor in the wrong place, so the math doesn't work out as well.)

So, no perfection at the HW front, either... ;-)

In ST's case, it won't work with OVER8 set. The hardware could've been done better, too. That was actually the reason for that weird and ultimately broken calculation.

JW

[peter-h]

There isn't much wrong with the RM. You have to publish the info somehow and that is the best way.

Videos are the most annoying way to do anything - especially if the speaker speaks unintelligible English which is the case with the ST ones I watched.

Something needs to be done with the steep learning curve though and I think ST did the right thing with the MX for initial hardware setup. There are just too many ways to screw up and one could spend weeks full-time getting one of these chips to run properly. And one will never know if it is marginal - look at e.g. some wait loops around the PLL setup. It is after that, where it becomes debatable whether to go bare-metal. But even then MX is handy to get some code to examine.

As I posted in the other "support" thread, ST, a $14BN company, should have forum presence. Not for "obviously stupid" threads, but for the ones where the poster has taken care to frame the question properly.

I am probably older than you, and being ex CZ (left in 1969) I also read from an early age

there's just so many people on the planet which possibly have the knowledge

Lots have the knowledge (how many LWIP installations are there?) but they acquired it in employer time so aren't posting it For example the "Monday-pm guy" who started the project I am working on has a great and inexplicable reluctance to post on a forum, even though he is not prohibited from doing so, and would gain from it (like I have, considerably).

More evidently, people aren't interested in helping somebody with "old stuff" like LWIP which is ~15 years old. Those who integrated it have long moved on. This is really clear from places like the LWIP mailing list, which has been dead for ~10 years.

I've been doing micro hardware and software since ~1980 but without the internet, I would never have got 32F4 hardware working, from just the RM.

[bson]

For those who are interested - I have finished the tutorial. Added a section on UART, IO retargeting (printf redirect), debugging with Segger Ozone, and using a vendor-specific CMSIS headers.

If you find a mistake or wish to extend it, PRs are welcome.
https://github.com/cpq/bare-metal-programming-guide

Thanks to those who came up with suggestions!

Your startup _reset() function doesn't call the constructor list.  This may seem unnecessary outside of C++, but you still need to do it for C since that's how static initializers get invoked.

Also, gcc has memcpy(), memmove(), memcmp() and memset() as builtins.

[tellurium]

Your startup _reset() function doesn't call the constructor list.  This may seem unnecessary outside of C++, but you still need to do it for C since that's how static initializers get invoked.

Thank you!
I understand about static C++ initialisers - and you're correct, _reset() does not invoke constructors.

Can you elaborate a bit more on the "still need to do it in C" - do you mean, to cover the case when a firmware uses C++ code?

[JPortici]

I've been doing micro hardware and software since ~1980 but without the internet, I would never have got 32F4 hardware working, from just the RM.

That's because some KEY informations are missing in the STM reference manual and datasheets (unless i'm wrong that they have been added in the last couple of years)
key information such as a minimal connection diagram  looking at the schematic for a devboard is not really an excuse, it's an image and some description of key connection and required values, fits in a page

[peter-h]

Your startup _reset() function doesn't call the constructor list.  This may seem unnecessary outside of C++, but you still need to do it for C since that's how static initializers get invoked.

Not long ago I tried to find out what that function does (for C, not C++) and nobody knew. I don't think it does anything for C. I am not calling it

Code: [Select]

/* Call static constructors */
/*  bl _libc_init_array */
Zeroed variables are cleared when BSS is zeroed. Nonzero variables are initialised by code in startup... .s (can be done in C as shown).

looking at the schematic for a devboard is not really an excuse

It is what everybody does though and is what I did It saves a massive amount of time.

This discussion has been moved to a new thread started by wek
https://www.eevblog.com/forum/microcontrollers/lets-discuss-telluriums-tutorial/

[wek]

I've been doing micro hardware and software since ~1980 but without the internet, I would never have got 32F4 hardware working, from just the RM.

That's because some KEY informations are missing in the STM reference manual and datasheets (unless i'm wrong that they have been added in the last couple of years)
key information such as a minimal connection diagram  looking at the schematic for a devboard is not really an excuse, it's an image and some description of key connection and required values, fits in a page

AN4488?

JW

[peter-h]

That's a new one

But this is yet another descriptive appnote. It doesn't tell you the steps needed and their order.

It also has some fairly typical dodgy stuff - 2nd grade engineers throwing in caps and inductors around for good measure - on page 34: L1 and R11?? I actually use a 10R from the 3.3V rail, then a 22uF + 100nF to VREF+ , to form a proper filter with a low Zout to feed Vref. There is a fair bit of muck on the 3.3V rail and that miniscule inductor will do minus nothing

[paulca]

I found it fairly coincidental that I received my first STM32 (F4) dev board yesterday and the first problem is my test setup was caused by:

snprintf( buf, 64, "%.2f", temp_c );

I got an error because the floating point conversion code was not included in the stdio library.  Luckily it even gave me the linker flag.

Now I knew the precision of that number and I could fix point it, but I decided to and see how much hassle it would be to change.  Turns out none really.  The documentation is out of date as the run dialogs have changed recently, but it wasn't that hard to locate where they'd oved the Settings tab to.

[wek]

>>> I've been doing micro hardware and software since ~1980 but without the internet, I would never have got 32F4 hardware working, from just the RM.
>> That's because some KEY informations are missing in the STM reference manual and datasheets
> AN4488?
But this is yet another descriptive appnote. It doesn't tell you the steps needed and their order.

OK so we're back at square one - there's no one size which would fit all.

Now the question is, what's the IDE of HW design?

JW

[peter-h]

One tends to start with the circuit of the dev board.

Strip off stuff not needed (the accelerometer, etc) and add stuff needed to the dev board (birdsnest it) and get it all running.

Then design the PCB, reading the data sheet page by page (all 300 pages). It is very likely to work 100%, which won't be the case if you just thumb through the data sheet.

That appnote is good but really a condensate (and an amplification at times) of the data sheet.

[JPortici]

I've been doing micro hardware and software since ~1980 but without the internet, I would never have got 32F4 hardware working, from just the RM.

That's because some KEY informations are missing in the STM reference manual and datasheets (unless i'm wrong that they have been added in the last couple of years)
key information such as a minimal connection diagram  looking at the schematic for a devboard is not really an excuse, it's an image and some description of key connection and required values, fits in a page

AN4488?

JW

Nice! i didn't know about this one. Is it referenced anywhere in the device datasheet/reference manual? I had a quick look at some STM32F4 product pages. In some there is, in some there isn't

[peter-h]

Really?

This is not actually funny because I read somewhere else that 100nF is too much for the debugger to discharge. So I am using 10nF. There needs to be "something" to prevent spikes getting coupled capacitively into the NRST PCB track, although to be honest if that is happening, it's game over anyway.

I am reading through this AN to see if it has something relevant to my board.

[paulca]

This is not actually funny because I read somewhere else that 100nF is too much for the debugger to discharge. So I am using 10nF. There needs to be "something" to prevent spikes getting coupled capacitively into the NRST PCB track, although to be honest if that is happening, it's game over anyway.

Man, that energy you dump out of the cap with a discharge resistor could probably power the thing in standby for week!

When you get people that anal about low power and let them influence the tech writers, it's going to appear.

[peter-h]

I doubt it, when a 0.22 FARAD supercap runs the 32F417 RTC for just a few days (actual data)

[SiliconWizard]

Ahah, man. Exaggerations.

ST makes ultra-low power MCUs (in the STM32Lx lines), so they are definitely sensitive to power consumption and that's a good thing.
Now when you use a STM32F4, you rarely are after ultra low power consumption, so obviously this note has less place in this datasheet. I suspect this is the same note in many others of their datasheets, that's all. I do not remember what's the typical power consumption of a F417 in one of its stop modes though. Might be in the µA range so depending on your applications, a few µA could matter.

Now what boggles me a bit is that action on the NRST pin should be pretty rare under normal operation, so even for an ultra-low power design, I don't really see how charging and discharging through the NRST pin could affect the average power consumption in any measurable way. (And OTOH when you're using a debugger, you rarely care about power consumption.) So, yeah.

As to this cap on NRST, I personally use at least 100nF for reasonable robustness against spurious resets that could be due to external noise (EMI.) Never had any problem pulling it down with a SWD adapter. Entirely depends on the adapter you use of course.

[uliano]

For those who are interested - I have finished the tutorial. Added a section on UART, IO retargeting (printf redirect), debugging with Segger Ozone, and using a vendor-specific CMSIS headers.

If you find a mistake or wish to extend it, PRs are welcome.
https://github.com/cpq/bare-metal-programming-guide

Thanks to those who came up with suggestions!

That is really wonderful! Thank you so much!

I'm really looking forward to try your tutorial. (It will happen very soon as, for some twist of fate, I actually have one Nucleo-F429ZI at home, I just need some free time).

I understand that you are suggesting to flash the Nucleo embedded ST-Link debugger with Ozone firmware and that's a great possibility.

If I may I'd suggest one more tutorial section explaining how to use the ST-Link debugger as this would be useful for other (non Nucleo or non ST) boards, possibly the very cheap one that can easily be found on amazon or chinese markets.

[paulca]

Now what boggles me a bit is that action on the NRST pin should be pretty rare under normal operation, so even for an ultra-low power design, I don't really see how charging and discharging through the NRST pin could affect the average power consumption in any measurable way. (And OTOH when you're using a debugger, you rarely care about power consumption.) So, yeah.

Is the NRST pin not used to wake the device via the RTC?  IIRC ESP and arduino land, deep sleep calls halt on the CPUs, powers the board down, leaving the RTC's alarm pin connected to the RESET pin.

In a low power device you would send it to deep sleep for a minute or more, then wake, do something and straight back to sleep.  If your wake time is only a few milliseconds it's still more efficient to sleep and wake 100 times a second.  Thought that's maybe exagerating a bit.

[SiliconWizard]

Now what boggles me a bit is that action on the NRST pin should be pretty rare under normal operation, so even for an ultra-low power design, I don't really see how charging and discharging through the NRST pin could affect the average power consumption in any measurable way. (And OTOH when you're using a debugger, you rarely care about power consumption.) So, yeah.

Is the NRST pin not used to wake the device via the RTC? 

No, not at all. Wake-up sources on STM32 MCUs are entirely internal.