What other RP2040 microcontroller board do we want to support that compliments the RPi Pico?

[jhodapp]

What is the second RP2040 microcontroller boards that we want our crate to immediately support and test out of the box (other than Pico)?

Candidates (from the list of boards rp-hal currently supports):

1. adafruit-feather-rp2040
2. adafruit-itsy-bitsy-rp2040
3. adafruit-kb2040
4. adafruit-macropad
5. adafruit-qt-py-rp2040
6. adafruit-trinkey-qt2040
7. pimoroni-pico-explorer
8. pimoroni-pico-lipo-16mb
9. pimoroni-plasma-2040
10. pimoroni-tiny2040
11. rp-pico
12. solderparty-rp2040-stamp
13. sparkfun-pro-micro-rp2040
14. sparkfun-thing-plus-rp2040

[jhodapp]

Adafruit Feather

Pro's:

• Adafruit makes solid microcontroller boards and their RP2040 series are also high quality
• Decent stock of their different models
• Decent worldwide distribution to reduce or eliminate import fees
• Includes a LiPo battery connector

Con's:

• Smaller flash size than the others

Flash size: 8 MB SPI flash

Cost: $11.95 USD

[jhodapp]

Sparkfun Thing Plus

Pro's:

• High quality board, metal buttons including a reset button
• USB-C connector
• Decent worldwide distribution to reduce or eliminate import fees
• Includes a LiPo battery connector
• Includes an SDCard slot on the bottom
• Large flash size for program code

Con's:

• Currently out of stock as of late May 2022 (straight from Sparkfun)
• Different debug header than the RPi Pico

Flash size: 16MB of external QSPI flash memory

Cost: $19.50 USB

[jhodapp]

Pimoroni Pico Lipo

Pro's:

• USB-C connector
• Includes a LiPo battery connector (QT/Qwiic compatible)
• Large flash size available for program code (2 different configs)

Con's:

• Different debug header than the RPi Pico
• Plastic buttons (solder heat risk when attaching headers)
• Not the best worldwide distribution, might add extra import fees

Flash size: 4MB/16MB of QSPI flash supporting XiP

Cost: $11 - 14 (USD)

[glynos]

I don't have a strong preference at all, but I like any board that has a USB type-C connector. I can find the SparkFun Thing Plus in Europe (which I can't say for all of the boards I researched):

https://www.elektor.com/sparkfun-thing-plus-rp2040

[calebbourg]

I believe the Adafruit Feather actually does come with a USB C connector. I think either the Adafruit Feather or the SparkFun Thing Plus sound good.
A quick search on the relative popularity of each doesn't turn up much to speak of.
My thought process there being to support the most widely used products where we can.

If @glynos can easily find the SparkFun thing then that seems like a good ➕ 1 there.

it's also available in the US

[jhodapp]

You're right @calebbourg, it does come with one. I must have been looking at a different one when I wrote that down about the Adafruit board. I already personally have the Sparkfun Thing Plus, so I can start playing around with it starting with putting soldered headers on it.

[calebbourg]

Looking more into how the embedded-hal crate is designed and intended to be used it's seeming like maybe it's possible (and potentially preferable) to actually have our crate be agnostic of the specific microcontroller it can communicate with. The embedded-hal crate provides traits that we can require in such a way that any HAL that implements the traits will work.

For example the BME280 new_secondary function in bme280-rs is bounded by the embedded_hal::blocking::i2c trait meaning that any underlying struct that implements embedded_hal::blocking::i2c can be used.

The way that I understand it is that if we choose to design our crate using these traits we will not need to choose which rp2040 boards to support. Or at least we can opt to support any bsp that implements the traits defined in embedded-hal.

Let me know if that sounds right

[jhodapp]

I think you're spot on Caleb - I've not been seeing any major reason why we need to care about what RP2040 series board our crate is run on. rp-hal abstracts all of these differences for us.

The one exception might be certain board specific features, such as taking advantage of an sdcard where available (e.g. storing sensor values until the board gets a connection again), but we may be able to detect the presence of these features or have some kind of feature flag to turn on/off support for this at compile time.

[calebbourg]

That's a good point on sdcard and other board specific features. What do you think about only supporting features of the boards which actually have and use an ESP32? In other words we can let other projects (like rp-hal) support features of boards that run on an RP2040. An example would be if we wanted to support the SD feature of the Pimoroni ESP32 WIFI board then that would fall within the scope of our project

Not sure if this is how things are typically done but I'd us to come to a solid understanding the boundaries and scope of our specific project.

[jhodapp]

Great question. I think this is something that we'd want to support in our project crate, but I submit the idea that we don't necessarily need to concern ourselves with this level of detail just yet. I think the most useful functionality to support is what the generic nina-fw on each ESP32 board can support for providing network functionality. Board-specific items could be implemented once we have core networking functionality implemented and solid. Do you agree with this?