Skip to content

stm/boards: Add support for SparkFun STM32 MicroMod Processor board. #5060

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 2 commits into from
Aug 11, 2021
Merged

stm/boards: Add support for SparkFun STM32 MicroMod Processor board. #5060

merged 2 commits into from
Aug 11, 2021

Conversation

cdwilson
Copy link

@cdwilson cdwilson commented Jul 25, 2021 •
edited
Loading

This is a work-in-progress PR for supporting the SparkFun STM32 MicroMod Processor board.

This is my first attempt at adding support for a new board in CircuitPython and there are a couple areas outlined below where I would appreciate some early feedback before this is finalized.

Peripheral numbering question

When I was reviewing the SparkFun MicroMod Tech Specs, I noticed that the MicroMod spec appears to use a zero-based peripheral numbering scheme. The 0th peripheral is the default and the "0" is omitted from the peripheral name. Some examples for different types of peripherals:

  • UART: UART, UART1, UART2
  • I2C: I2C, I2C1
  • SPI: SPI, SPI1
  • CAN: CAN
  • SDIO: SDIO

The Designing with MicroMod tutorial seems to confirm this assumption when it discusses the UART peripheral:

Note: UART1/2 must be unencumbered (not attached to a USB-to-serial conversion IC).

Note: UART0 is not shown. Primary debug serial is done over USB. Serial.print() should print over USB, not TX1.

However, when I reviewed the existing MicroMod board definitions in CircuitPython (sparkfun_samd51_micromod and sparkfun_nrf52840_micromod), it looks like the pin name QSTR definitions do not always conform to the MicroMod spec (they are inconsistent across boards).

For example, looking at the pin definitions for the "0th" I2C peripheral, the sparkfun_samd51_micromod board aliases the SDA and SDA1 pins to the same I2C bus, while the sparkfun_nrf52840_micromod defines SDA and SDA1 on separate I2C busses:

    // sparkfun_samd51_micromod
    
    // I2C
    { MP_ROM_QSTR(MP_QSTR_SDA), MP_ROM_PTR(&pin_PA17) },
    { MP_ROM_QSTR(MP_QSTR_SDA1), MP_ROM_PTR(&pin_PA17) }, <-- should be removed
    { MP_ROM_QSTR(MP_QSTR_SCL), MP_ROM_PTR(&pin_PA16) },
    { MP_ROM_QSTR(MP_QSTR_SCL1), MP_ROM_PTR(&pin_PA16) }, <-- should be removed

    { MP_ROM_QSTR(MP_QSTR_I2C_INT), MP_ROM_PTR(&pin_PA18) },

    // I2C2 <-- MicroMod spec doesn't have an "I2C2"
    { MP_ROM_QSTR(MP_QSTR_SDA2), MP_ROM_PTR(&pin_PA13) }, <-- should be SDA1
    { MP_ROM_QSTR(MP_QSTR_SCL2), MP_ROM_PTR(&pin_PA12) }, <-- should be SCL1

vs.

    // sparkfun_nrf52840_micromod
    
    // I2C
    { MP_ROM_QSTR(MP_QSTR_SDA), MP_ROM_PTR(&pin_P0_08) },       // 0.08 - SDA
    { MP_ROM_QSTR(MP_QSTR_SCL), MP_ROM_PTR(&pin_P0_11) },       // 0.11 - SCL (TRACEDATA2)

    { MP_ROM_QSTR(MP_QSTR_I2C_INT), MP_ROM_PTR(&pin_P0_15) },   // 0.15 - I2C_INT

    { MP_ROM_QSTR(MP_QSTR_SDA1), MP_ROM_PTR(&pin_P1_01) },       // 1.01 - SDA1
    { MP_ROM_QSTR(MP_QSTR_SCL1), MP_ROM_PTR(&pin_P0_24) },       // 0.24 - SCL1

In this PR, I have defined the pin names strictly according to the MicroMod spec, which is also consistent with the pin definitions for this same board in micropython. Since there is some inconsistency across MicroMod boards in CircuitPython, I just wanted to confirm that adhering to the MicroMod naming convention was the preferred approach moving forward for MicroMod boards in CircuitPython. If desired, I can submit a separate PR to fix the other MicroMod board definitions to be more consistent & compliant with the MicroMod spec.

Peripheral prefix question

The MicroMod spec prefixes the pin names with the peripheral type (I2C_, SPI_, etc). For example, I2C pins are named I2C_SDA1 & I2C_SCL1 instead of SDA1 & SCL1.

In this PR, I have defined the pin names using these explicit prefixes, but it looks like many of the existing CircuitPython board definitions don't use these prefixes for the UART, I2C, and SPI peripherals (and maybe others?). For example, the feather_stm32f405_express pin definitions don't use a prefix for I2C pins SDA and SCL, but it does for SDIO pins ( SDIO_CLOCK, SDIO_COMMAND, etc). If there is an existing convention in the CircuitPython community for when a pin definition should be prefixed with the peripheral type, I'm happy to update this PR to follow any existing convention.

@tannewt
Copy link
Member

tannewt commented Jul 26, 2021

@stonehippo and @nitz have added the other boards. I'd love to see consistent pin naming across the boards.

@cdwilson
Copy link
Author

PID request (not sure if there is a more "official" way to request these from SparkFun):

https://forum.sparkfun.com/viewtopic.php?f=182&t=56105

@cdwilson cdwilson force-pushed the cdwilson/circuitpython/sparkfun-stm32f405-micromod branch 2 times, most recently from 86c5726 to ef47b4c Compare July 29, 2021 15:55
@tannewt
Copy link
Member

tannewt commented Jul 29, 2021

I'm ok if you want to get them all consistently named. We can say it's something changing with 7.

@hierophect hierophect added stm board New board or update to a single board labels Jul 30, 2021
@cdwilson
Copy link
Author

@tannewt sounds good, I'll work on some changes to the other MicroMod board definitions to get everything consistently named.

Couple questions:

  1. OK if I make those changes as part of this PR, or do you want those as a separate PR?
  2. When is V7 targeted for release?

@tannewt
Copy link
Member

tannewt commented Aug 2, 2021

@tannewt sounds good, I'll work on some changes to the other MicroMod board definitions to get everything consistently named.

Couple questions:

  1. OK if I make those changes as part of this PR, or do you want those as a separate PR?

Here is fine.

  1. When is V7 targeted for release?

No date specifically.

@cdwilson cdwilson marked this pull request as draft August 3, 2021 05:56
@cdwilson cdwilson force-pushed the cdwilson/circuitpython/sparkfun-stm32f405-micromod branch 4 times, most recently from b886f19 to c2f8056 Compare August 9, 2021 07:14
@cdwilson cdwilson force-pushed the cdwilson/circuitpython/sparkfun-stm32f405-micromod branch from c2f8056 to c0902da Compare August 10, 2021 06:37
@cdwilson
Copy link
Author

@tannewt @stonehippo @nitz I updated this PR to include an attempt at consistent pin names for all the existing MicroMod board definitions.

The table below shows the standard MicroMod primary and alternate pin names I'm using:

SAMD51 nRF52840 STM32F405 RP2040 M.2 Pin MicroMod Primary MicroMod Alt 1 MicroMod Alt 2 MicroMod Alt 3 CircuitPython
N/C VBUS N/C N/C 9 USB_VIN
PA19 P1.15 N/C N/C 4 P3V3_EN
PB03 P0.30 PA1 GPIO29 49 BATT_VIN3
RESETN P0.18 NRST RUN 6 RESET
N/C P0.07 BOOT0 N/C 11 BOOT
PA24 D- PA11 USB_D- 5 USB_DM
PA25 D+ PA12 USB_D+ 3 USB_DP
N/C N/C PB14 USB_D- 37 USBHOST_DM
N/C N/C PB15 USB_D+ 35 USBHOST_DP
PB15 N/C PB8 N/C 41 CAN_RX
PB14 N/C PB9 N/C 43 CAN_TX
PB31 P1.03 PA2 GPIO0 17 UART_TX1 TX
PB30 P1.10 PA3 GPIO1 19 UART_RX1 RX
N/C P1.02 N/C GPIO3 13 UART_RTS1
N/C P1.09 N/C GPIO2 15 UART_CTS1
PA12 P1.07 N/C GPIO8 22 UART_TX2
PA13 P1.05 N/C GPIO9 20 UART_RX2
PA17 P0.08 PB11 GPIO4 12 I2C_SDA SDA
PA16 P0.11 PB10 GPIO5 14 I2C_SCL SCL
PA18 P0.15 PB1 GPIO8 16 I2C_INT
PA13 P1.01 PB7 N/C 51 I2C_SDA1
PA12 P0.24 PB6 N/C 53 I2C_SCL1
PA06 P0.02 PA6 GPIO20 61 SPI_CIPO CIPO
PA04 P0.31 PA7 GPIO23 59 SPI_COPI LED_DAT COPI
PA05 P0.28 PA5 GPIO22 57 SPI_SCK LED_CLK SCK
PA07 P0.20 PC4 GPIO21 55 SPI_CS CS
N/C P0.19 N/C GPIO14 60 SDIO_CLK SPI SCK1
N/C P0.14 N/C GPIO15 62 SDIO_CMD SPI COPI1
N/C P0.21 N/C GPIO12 64 SDIO_DATA0 SPI_CIPO1
N/C P0.22 N/C GPIO11 66 SDIO_DATA1
N/C P0.23 N/C GPIO10 68 SDIO_DATA2
N/C P1.00 N/C GPIO9 70 SDIO_DATA3 SPI_CS1
PB17 N/C N/C GPIO24 58 AUD_MCLK
PA21 N/C PB4 GPIO10 56 AUD_OUT I2S_OUT PCM_OUT CAM_MCLK
PA22 N/C PB5 GPIO11 54 AUD_IN I2S_IN PCM_IN CAM_PCLK
PA20 P0.26 PA4 GPIO2 52 AUD_LRCLK I2S_WS PCM_SYNC PDM_DATA
PB16 P0.25 PB3 GPIO3 50 AUD_BCLK I2S_SCK PCM_CLK PDM_CLK
PA31 SWDIO PA13 SWDIO 23 SWDIO
PA30 SWDCLK PA14 SWCLK 21 SWCLK
PA02 P0.05 PC5 GPIO26 34 A0
PB00 P0.04 PB0 GPIO27 38 A1
PB01 P0.06 PC6 GPIO13 32 PWM0
PB02 P0.16 PC7 GPIO24 47 PWM1
PB04 P0.27 PC0 GPIO6 10 D0
PB05 P1.08 PC1 GPIO7 18 D1 CAM_TRIG
PB06 P0.29 PD2 GPIO16 40 G0 / BUS0
PB07 P0.03 PA8 GPIO17 42 G1 / BUS1
PB08 P1.13 PA0 GPIO18 44 G2 / BUS2
PB09 P1.12 PC8 GPIO19 46 G3 / BUS3
PB10 P1.11 PC9 GPIO20 48 G4 / BUS4
PB11 P0.17 PC13 GPIO21 73 G5 / BUS5
PB12 P1.06 PC2 GPIO22 71 G6 / BUS6
PB13 P1.04 N/C GPIO23 69 G7 / BUS7
PA14 P1.14 N/C N/C 67 G8
PA15 P0.09 N/C GPIO28 65 G9 ADC_D- CAM_HSYNC
N/C P0.10 PB13 GPIO25 63 G10 ADC_D+ CAM_VSYNC
PA27 N/C PB12 N/C 8 G11 SWO

For the I2C, SPI, and UART peripherals, I wasn't sure if it was preferable to omit the peripheral type prefixes or leave them more consistent with the MicroMod spec (e.g. CIPO1 vs. SPI_CIPO1). I opted for matching the MicroMod spec as close as possible, but I can rename these pins to remove the I2C/SPI/UART prefixes, or add additional aliases if desired (i.e. we can have both aliases SPI_CIPO1 & CIPO1). For all other peripherals, I followed the MicroMod spec and included the peripheral type prefixes (e.g. CAN_TX).

Also, since there are lots of existing CircuitPython tutorials that use the default peripheral pin names (e.g. SCL & SDA for the default I2C interface), I added CircuitPython aliases for the default I2C, SPI, and UART pins.

One other thing worth noting: I updated the board names to include "Processor" (e.g. "SparkFun STM32 MicroMod Processor") and restricted the pin definitions to those specific to each processor module. Since we don't really know which "Carrier Board" a processor module could be plugged into, I'm not sure if it makes sense to define pin aliases for the carrier boards.

I don't have access to all the MicroMod processor hardware modules, so if you have the hardware and can get a chance to do some sanity check testing on this PR, I'd appreciate it.

@cdwilson cdwilson changed the title [WIP] stm/boards: Add support for SparkFun STM32 MicroMod Processor board. stm/boards: Add support for SparkFun STM32 MicroMod Processor board. Aug 10, 2021
@cdwilson cdwilson marked this pull request as ready for review August 10, 2021 07:28
@nitz
Copy link

nitz commented Aug 10, 2021

Fantastic work, @cdwilson — I've got some stuff on my plate this week but if I can get some spare time I'll check vs the modules I have :)

@cdwilson
Copy link
Author

One area I'd like some closer review is the audio pin definitions. I haven't done anything with audio on any of these MCUs, so I'm not as familiar with these pins. I took a simple approach of defining the pins for each interface if all the pins for that interface were exposed on the M.2 edge connector. So, for example, on the STM32 processor, AUD_MCLK is not connected, so I I didn't define the AUD_* pins. However, I did define I2S_*, PCM_*, and PDM_* pins because those pins were fully exposed on the M.2 interface.

@cdwilson
Copy link
Author

Another thing I wanted to mention: when I added the sparkfun_stm32f405_micromod board, I followed the <vendor>_<mcu>_<product line> naming convention that seemed to be used by most other SparkFun MicroMod boards:

sparkfun_<mcu>_micromod

  • sparkfun_nrf52840_micromod
  • sparkfun_samd51_micromod
  • sparkfun_stm32f405_micromod

The exception is the RP2040 boards, which all seem to use <vendor>_<product line>_<mcu> format:

  • sparkfun_micromod_rp2040
  • sparkfun_pro_micro_rp2040
  • sparkfun_thing_plus_rp2040
  • etc...

I just wanted to confirm whether we wanted to leave the sparkfun_micromod_rp2040 board name as-is or rename it to match the other MicroMod boards since we're in the middle of updating things (I'm assuming that consistency within each port is more desirable, so I was planning to leave it as-is).

@tannewt
Copy link
Member

tannewt commented Aug 10, 2021

I totally agree that the board shouldn't know anything about the carrier board.

Your pin naming makes sense to me.

I wouldn't rename any of the existing board folders because we use it as a unique id. Renaming it could lead to multiple listings or missing older listing. So, I think it's simplest to leave the board name as-is.

@nitz
Copy link

nitz commented Aug 11, 2021

I totally agree that the board shouldn't know anything about the carrier board.

Definitely on this side as well. Might be a fun exercise at some point to do some sort of "overlays" that provide per-carrier symbols for the different "common" carriers, but I'd certainly rather the boards themselves know nothing of them 🙂

@cdwilson
Copy link
Author

Might be a fun exercise at some point to do some sort of "overlays" that provide per-carrier symbols for the different "common" carriers

Yeah, it would be nice if Micro/CircuitPython eventually supported something like Zephyr Shields for carrier or add-on boards.

@cdwilson
Copy link
Author

@tannewt I don't know if it matters, but I think the build-arm (feather_mimxrt1011) check might be stuck on this one. When I look at the details, it says Started 1d 8h 39m 41s ago, but the log just shows Starting job....

@tannewt
Copy link
Member

tannewt commented Aug 11, 2021

Might be a fun exercise at some point to do some sort of "overlays" that provide per-carrier symbols for the different "common" carriers

Yeah, it would be nice if Micro/CircuitPython eventually supported something like Zephyr Shields for carrier or add-on boards.

We don't need to support this in the core. A library would be able to provide the carrier specific functionality.

@tannewt I don't know if it matters, but I think the build-arm (feather_mimxrt1011) check might be stuck on this one. When I look at the details, it says Started 1d 8h 39m 41s ago, but the log just shows Starting job....

Ok, let's ignore it. I'll merge it anyway.

tannewt
tannewt approved these changes Aug 11, 2021
View reviewed changes
Copy link
Member

@tannewt tannewt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@tannewt tannewt added this to the 7.0.0 milestone Aug 11, 2021
@tannewt tannewt merged commit 0632a1e into adafruit:main Aug 11, 2021
@cdwilson cdwilson deleted the cdwilson/circuitpython/sparkfun-stm32f405-micromod branch August 12, 2021 04:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@tannewt tannewt tannewt approved these changes

Assignees
No one assigned
Labels
board New board or update to a single board breaks api stm
Projects
None yet
Milestone
7.0.0
Development

Successfully merging this pull request may close these issues.
4 participants
@cdwilson @tannewt @nitz @hierophect