3 ms·

> It can cause surprising problems if you don't check the dev board manual's pin table Nah, you got it all wrong. You need to pull up the devboard's Pinout, U

> It can cause surprising problems if you don't check the dev board manual's pin table Nah, you got it all wrong. You need to pull up the devboard's Pinout, User Guide, and Overview documents. Sometimes cross reference those to the devboard's schematic for the trickier pins. Alongside the specific User Guide and Programming manuals for the MCU on the board. Plus the MCU's guides don't typically cover stuff that's common to all MCUs in a particular Cortex family, so you need to pull up the Cortex documentation. And then, finally, the errata documents. Typically speaking you'll need to cross reference across all of those documents, all at once, and several places _within_ each document ... all at once. That's assuming you're using one of the more common pins. If you've decided to dabble with any of the more exotic functionalities you'll want to pull up one or several Application documents, as the former pile of documentation is unlikely to accurately describe the necessary "voodoo" to get things working. (I kinda wish this comment was a joke ... but it's not. The STM line of chips are truly wonderful machines but ... golly are they a pain to develop on. There's a reason most people just use Arduino to plaster over this stuff.) EDIT: Oh and make sure you don't confuse the labeling of the pins on the board, with the label of the pins on the pinout, with the label of the pins on the schematic, with the label of the pins in the registers, with the label of the pins in the various HAL libraries... EDIT2: Geez, how could I forgot the most crucial thing: you of course have to modulate all of these by which specific package of the chip you're actually working with. No sense spending half an hour of your life wadding through all of this documentation only to get to the dev board pinout to find that pin is only available on the largest package and the dev board only came with the 2nd to largest package... (and also doesn't include that one peripheral you were planning to use because ... reasons).

the__alchemist 6y ago
Those issues transcend the discovery board. It's frustrating how much the Reference Manuals leave to the imagination. A lot of the peripherals are similar or identical across families. Some have subtle differences, and some have large ones. I haven't found a shortcut - seems you really need to bring up parallel reference manuals. For example, the RTC periph is the same on most STM32 devices. Clocks vary significantly between families, as expected, but at their core, are just different combos of multipliers and internal oscillators, which you can break out by comparing clock trees. Things like I2C vary wildly between families, and sometimes within families.
- duskwuff 6y ago
  > For example, the RTC periph is the same on most STM32 devices. There's actually two major versions of the RTC peripheral. :) The v1 RTC counts in seconds, v2 has explicit date/time fields. A lot of other STM32 peripherals can be seen as "versioned" in similar ways. There's a lot of different combinations of those peripherals on different parts, but there's usually only two or three major revisions present of each peripheral across the entire product line, and they tend to follow a pretty consistent timeline. (That is, a newer part will usually use the newest version of each peripheral at the time it was designed, rather than using a mixture of old and new peripherals.)
- cerplum 6y ago
  One potential shortcut is if you install their CubeMX and take a look in it's data files there are XML files for each distinct peripheral. So there'll be something like RTC_v1.0.xml and RTC_v2.0.xml. Someone uploaded an old copy of them [1] if you just want a quick look. Then there's also device & device family xml files that link to the various peripherals they have [2]. There's probably no guarantees but in my experience if two devices link to the same version xml file their peripheral registers at least will be identical. Quirks and silicon bugs, you are on your own of course... but then the ref manual doesn't help with that either! [1] https://github.com/esden/stm32cube-database/tree/master/db/mcu/IP https://github.com/esden/stm32cube-database/tree/master/db/m... [2] https://github.com/esden/stm32cube-database/tree/master/db/mcu https://github.com/esden/stm32cube-database/tree/master/db/m...

the__alchemist 6y ago

Those issues transcend the discovery board. It's frustrating how much the Reference Manuals leave to the imagination. A lot of the peripherals are similar or identical across families. Some have subtle differences, and some have large ones. I haven't found a shortcut - seems you really need to bring up parallel reference manuals. For example, the RTC periph is the same on most STM32 devices. Clocks vary significantly between families, as expected, but at their core, are just different combos of multipliers and internal oscillators, which you can break out by comparing clock trees. Things like I2C vary wildly between families, and sometimes within families.

duskwuff 6y ago
> For example, the RTC periph is the same on most STM32 devices. There's actually two major versions of the RTC peripheral. :) The v1 RTC counts in seconds, v2 has explicit date/time fields. A lot of other STM32 peripherals can be seen as "versioned" in similar ways. There's a lot of different combinations of those peripherals on different parts, but there's usually only two or three major revisions present of each peripheral across the entire product line, and they tend to follow a pretty consistent timeline. (That is, a newer part will usually use the newest version of each peripheral at the time it was designed, rather than using a mixture of old and new peripherals.)
cerplum 6y ago
One potential shortcut is if you install their CubeMX and take a look in it's data files there are XML files for each distinct peripheral. So there'll be something like RTC_v1.0.xml and RTC_v2.0.xml. Someone uploaded an old copy of them [1] if you just want a quick look. Then there's also device & device family xml files that link to the various peripherals they have [2]. There's probably no guarantees but in my experience if two devices link to the same version xml file their peripheral registers at least will be identical. Quirks and silicon bugs, you are on your own of course... but then the ref manual doesn't help with that either! [1] https://github.com/esden/stm32cube-database/tree/master/db/mcu/IP https://github.com/esden/stm32cube-database/tree/master/db/m... [2] https://github.com/esden/stm32cube-database/tree/master/db/mcu https://github.com/esden/stm32cube-database/tree/master/db/m...