I’m continuing RP2040 Microcontroller Expansion Card but instead of reviving an old thread, it would make more sense to create a new thread, I’m going to be continuing this idea, but it will not have a customizable cover but instead, a flash chip to store a program. I will post more information and possibly some images.
RP2040s are an amazing platform, but my concern is utility. Are you going to be including any inbuilt interactivity devices like buttons or LEDs?
1 Like
That’s an awesome idea.
I think the most useful peripheral connections would be an SWD output. I’m imagining you would use the RP2040 expansion card to punch out boilerplate code for, duh, RP2040 based hardware. And then flash and debug it using the same explanation card.
A Stemma QT port would have lots of education value as a way to very quickly interface with sensors using one RP2040 card to rule them all.
The struggle is selecting the bus. I2C and SPIO would probably be the most useful? Would space allow a hardware jumper to select between them?
LEDs and Reset, Select, or GPIO buttons would also be super handy.
I think a easy interface between laptops and microcontrollers is long overdue. Fortunately RO2040 has this with tinyusb, but not every project will have USB.
I’ve got an Rp2040 design ready to be fabbed, but it’s painful to know what to include/not to include as I rarely use microcontrollers in this format, I do think I integrated a QT port in there and a few different interfaces, if people want I can post my schematic up here for feedback.
I would be happy to see the design and give some feedback!
Here you go, only main question is should I have i2c lines on both the header and also the QT port, I currently have a switch just to switch which connector it is going to. (probably not the best idea though) RP2040-Expansion-Card/RP2040 MCU.pdf at main · jyancat/RP2040-Expansion-Card · GitHub
1 Like
Hey, that looks really good to me.
The only changes I would recommend are:
- Make the LED GPIOs contiguous e.g. GPIO23-25. Seems more user friendly.
- Use JST or similar instead of test points for SWD. Given the small form factor, I think this is almost a must.
I don’t understand the use of the diodes in the USB-C connector. Don’t remember needing that for USB Micro with my last (and only) RP-2040 project.
Also, what is J1 for. Is that a JTAG class debugging port? Or for peripherals.
Space seems like a serious concern. A neopixel instead of RBG LEDs could save a lot of space and be a lot more fun!
Thanks for the feedback, with the LED GPIOs, I get what you mean so I’ll change that, along with the test points for SWD. I usually implement some kind of ESD protection on anything that people would be directly handling which is what the diodes are for, J1 is a basic header to breakout some standard interfaces and basic GPIO (i2c, UART, SPI and SWD) and I may look into using a neopixel. I’ll make some changes whenever I get time and after I pack your order and then post the schematic after editing. I’m bundling up a heap of PCBs so I can send them off in one go, I’ve actually received a fair few parts for 4 or 5 expansion cards today so waiting on those PCBs.
1 Like
Have you thought about taking a small format 2040 Microcontroller like the Seeduino and putting a male usb-c header on it? You could the just make a “Hat” to bring the GPIO where you need it to be.
There are two ways of handling this, have a very fine pitch connector to break out essentially every single pin on the RP2040, or just break out some standard GPIO, UART and i2c signals.
Breaking out some pins should be fine. AFAIK you can asign different functions to the pins, so you probably dont need every pin. You should remember the analog pins, though
If you need most pins on the 2040, you might as well use a Pico. If you need every single pin, you are making your own boards. There is no one the expansion card form factor could expose every pin, unless it was even larger than the Ethernet expansion.
The reason to use an RP2040 expansion card, to me, would be to rapidly prototype code for use with common sensors and actuators. Therefore the hardware interface should also be one that is common with educational and prototyping sensors and actuators.
I2C (or even I3C, why not) and SPI seem like the best options to me. I2S and UART are close runner ups. GPIO… how would it be accessed? Screw terminals? Would take a lot more space than a QT or JST connector.
If you just put like 10 female jumper pins on the card, it could have i2c, spi, uart and also adc pins. The cool thing on the pico is, that pins have multiple functions. So you can choose, what you need for your “project” and configure it on the go
2 Likes
I’ve just assembled my 5 prototype units, they do work and I have managed to break out mostly all of the GPIO (except for 4), these were quite simplified so I’ll be working on that and then post photos of my rev2 and then look into producing them.
7 Likes
I’m excited to see the photos, and sign me up for one if you reach production.
I second that, happy to build one of these from BOM or purchase one
wow I am working on this as well. I am doing it as a one-off so I tried to base it on waveshare rp2040 zero board
the soldering are absolutely horritying since they used resisters that are like 0402 or smaller but I get it working eventually, I am currenting working on the enclosure for it.
imo this is really just an inexpensive way to add gpios to framework laptops, whether you want to make it a logic analyzer, an interface adapter, or something else is just up to what people can code
1 Like
That looks like an absolute soldering nightmare but if it works, that’s amazing, thanks for sharing!
Nice. I love the small size of the waveshare rp2040-zero boards. Great for squeezing a rp2040 into a small space. I do wish there were solder pads for usb D+, D-.