- 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)
I've complained about the horrible process that ST libraries go to set the baud rate for a long time.
I've complained about the horrible process that ST libraries go to set the baud rate for a long time.
I don't think it is a simple divider,
Nobody hears you here.
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.
QuoteI don't think it is a simple dividerit's a fractional divider, as described in the RM
And why do you use those "libraries", then?
QuoteNobody hears you here.
Nobody hears you anywhere.
2000 page RMs which nobody can read - well the people who can read them are those who already know most of it.
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.)
there's just so many people on the planet which possibly have the knowledge
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.
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.
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.
/* Call static constructors */
/* bl _libc_init_array */
looking at the schematic for a devboard is not really an excuse
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
>>> 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.
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 pageAN4488?
JW
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.
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!
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.
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?