Preferences

osamagirl69 parent
I love the emphasis on breaking out all of the GPIO pins, it is incredible today how many dev boards either leave pins as not connected or hard wire them (no jumper to disable) to some onboad peripheral. Looking at you stm32 discovery boards...

the__alchemist
The Discovery boards are a bit of a minefield over which pins you're allowed to use. It can cause surprising problems if you don't check the dev board manual's pin table, or don't know how to interpret it. Additionally, you need to plug the jumpers into the bottom of the board; it looks like you can use the top, but the jumpers tend to fall out!

The nucelo ones are even weirder. The pins aren't labeled on the board, and they're in a weird layout, with some male and others female.

fpgaminer
> 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
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
> 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
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/m...

[2] https://github.com/esden/stm32cube-database/tree/master/db/m...

phendrenad2
It's amazing how many dev boards with 300 GPIOs on the chip give you... 50 (especially looking at you, Xilinx!). At least give me a tiny little header that I can use if I'm determined enough.

Signed,

Someone who needs 200+ pins in a current design and doesn't want to make their own board from scratch.

This item has no comments currently.