> startup_stm32f407xx.s - it is odd why this is in asm
Chicken/egg. Startup code is to prepare everything needed to run C, so how could startup be in C if it haven't had things prepared?
OTOH, if that C is simple enough and doesn't use globals/statics, it should be fine. I personally don't like it because of the "fundamental" reason above.
Also, what I don't quite get is the urge to set SP. I see that regularly. But, it's set by hardware from the first word in the vector table, after all. Is this some cargo-cult thing or is there any material reason for it? I couldn't find any hints. After all, cargo-cult followers don't know it's a cargo-cult, do they, so they can't report.
> __libc_init_array - you confirm it is C++ only
Following discussion here (also in your "CubeIDE is crap" thread) and
elsewhere, I don't; the upcoming version of the 101.5 text is rephrased.
My text is aimed at minimal. Your application is everything but (use of RTOS, printf()...). The more "magic" which comes with the tools you use, the less you will be able to kick out the "why would I need this" stuff.
> STLINK-V3 - I may be wrong but I think you need V3 to get the "high speed debugging UART" - the SWV ITM data console
SWO "UART Rx" is available in STLink/V2, too.
> today's PCs are so fast that a batch file based compile-all is fine
There are merits of using make beyond speed, too, but generally, this is a valid point.
> some libc functions are not reentrant (not in this thread, you've mentioned it elsewhere, but I think it's relevant to the "minimal" and "have control" overarching topic)
It may come as a nasty surprise, but by the C standard, *none* of the standard library functions are to be considered reentrant. In other words, thou shalt not use e.g. abs() both in main and interrupts.
(Also, the standard claims *all* symbols defined in the library chapter (C99 chapter 7) to be reserved, yes, writing your own abs() may result in nasty surprises and it did in the past - and I know you say the library functions as they are supplied with Cube can't be simply overriden - this is likely to be dependent on several minute details of how exactly things are compiled/linked, not just having library functions weak, and matter for further extensive painful discussion, not here and not now).
Programs written so are not strictly conformant thus not portable. OTOH, who cares about strict standard conformance and portability? Isn't functionality the ultimate goal? Is there any relevant mcu *application* where code portability is of any concern whatsoever?
Now for many library functions (e.g. <math.h>) it would be rather strange if they would be non-reentrant. I can imagine system-level library functions (i.e. those which are not covered by the "freestanding" clause of C99) to be non-reentrant - the printf()/scanf() family may be prime example, although <time.h> may be the prime counter-example, too.
Here's newlib's documentation promising that only a portion of it is non-reentrant, and that they can be made reentrant too.JW