Stackable Raspberry Pi Pico dev system

[Rob110829]

This is the latest iteration of an idea I’ve had for several years and even posted about here before. I have however simplified the design and changed the host processor to a Pico.

The first item being designed is a carrier board for the Raspberry Pi Pico that can have up to eight other addressed boards stacked or any number of unaddressed boards.

More details can be found on this web page I knocked up as a temporary measure until the project gets it’s own web site.

www.quub.org

And a PDF of the current schematic here.

schematic.pdf (294.1 KB)

I’ve never had any dealings with the Pico and haven’t started laying out tracks yet so it’s not too hard to change things and if anyone here has some input it will be gladly accepted.

Rob

[Michael]

Ah yeah! I remember when you mentioned this on a Factory Episode thread! Good so see you’re still keen on it.

If you haven’t worked with the Pico before pick one up and see how it goes to get familiar with the user experience. A fair bit has changed since 2021 as well - they have wifi now

[Rob110829]

Life got in the way since then, and now I’m extending my house which take up most of my energy but I still have some spare time at night

[Rob110829]

Just a little status update. The MCU boards have been fabbed but I’ve already decided on some changes so I doubt I’ll populate them, after all they cost naff all so I’ll just get some more made when I’ve made the changes.

Meanwhile here are five of them stacked, giving some idea of where the QUUB name came from

Of course one would not stack five MCU boards, I just wanted to check the mechanical aspects of the idea.

[Michael]

Now I understand the namesake very tidy.
How will the boards communicate? Will there be a driver board and other device boards respond over eg. i2c?

[Rob110829]

The board you see here is the “driver board” I guess, meaning that it has the MCU that controls all the daughter boards. The stackable backplane (stackplane) has all the signals required to talk to peripheral chips.

Here’s the current pinout.

There are three headers, a 24-pin that have the data signals and two 3-pin ones that have power, one of them (P3) is optionally a 7-pin to allow for 4 user-defined signals.

In simple mode the system works as per all other such boards and the signals are as shown here as net names. But if you want to address boards and use “interrupts” then you lose the ADC and/or DIO signals as it is assumed that IO is performed entirely by daughter boards using I2C/SPI IO chips. In this case the names in blue tell the functions, IE BSn (board select) and the interrupt signals.

I will probably have some combination of the two modes that allows direct IO from the MCU and addressable daughter boards as well.

The schematic shows duplicates of each header, that is because they are really SMD header/socket pairs on each side of the board.

There is provision to solder side panels and a “lid” to make the system self enclosing, IE no box required unless you really need a high IP rating.

[Rob110829]

Almost as soon as I received the last PCBs I had a few ideas for some changes. So I’ll be getting new ones made and won’t be using the last ones. They cost almost nothing to make these days so might as well get it as right as possible eh?

For most applications the three stackplane headers will be enough to mechanically secure the circuit boards together. However to applications with a lot of movement and/or vibration this will not be enough so the following provisions have been added.

• There are two mounting holes located at the opposite side of the PCB to the 24-pin stackplane header. These can be used for 16mm male/female standoffs that will mechanically hold the stack together.
• Each mezzanine board position has an optional broaching nut set into the main PCB, this can be used to mechanically secure the boards.

[Michael]

@Rob110829

Almost as soon as I received the last PCBs I had a few ideas for some changes

An all-too-familiar experience

Some thoughts:
You’ve really gone all-out with the heatsinking for the SOT23 regulator there! I haven’t seen it done like that but it looks great.

I’m afraid without solder mask you may find soldering it to be a little tricky eg. solder bridges…

The added mechanical features sound prudent - stops things flapping in the breeze

[Rob110829]

Yeah I went a bit overboard on the heatsinking eh? Still I had the real estate so why not.

There might be a problem soldering, but I’ve been soldering for about 40+ years so I’ll handle it. I always solder by hand but maybe it’s time to get a stencil made and use hot air or even finally set up an oven.

[Rob110829]

Well the project seems to have suffered from some mission creep, but that’s OK, I think it’s better for it for the most part.

The PCB is larger (100x125mm or 4x5") and the circuitry more complex than before, so it’s no longer a beginner’s project but that’s OK as well, there are 100s of simple prototyping boards out there already and anyway this is not a prototyping board, it’s to be used in real-world monitoring and control applications.

The main differences between the new version and the above versions is the increase of addressable daughter boards from 8 to 16, the implementation of vectored interrupts for plug in modules, and the removal of most IO from the main PCB. This IO removal was done because all applications need different IO so I have designed a system of small modules that solder onto the main PCB. There are 4 of these on the main PCB and up to another 60 can be addressed on stackable boards.

It’s all too much to describe here but there is a pretty full description of the QUUB as it stands today on my web site (https://www.robgray.com/quub/).

Also here is a link to the current schematic.

https://www.robgray.com/quub/documentation/MCU-schematics.pdf

And finally some 3D renders of the board design as it stands today.

A bare PCB with four empty docking stations for IO modules.

A fully loaded PCB with four modules installed. Pictured here are modules for power supply, RTC, SD card and a dual RS485 serial link. Plans are in place for many others such as a PiicoDEV/STEMMA-QT/QWIIC interface, GPIO, analogue input, current shunt monitoring, relay output, isolated digital input, isolated digital output, LORA, serial port(s), etc

And finally a board loaded with two normal sized modules and one double sized module.

The standard IO module is 32x42mm in size, large enough for most IO with today’s highly-integrated chips. But if you need more real estate the double module is 32x94mm or you can design a full-sized board (100x75mm) to stack onto the MCU.

There is also provision to “remote” the modules with ribbon cables so things like SD cards and serial ports can easily be accessed from the outside on the sides or top of an enclosure.

[Liam120347]

Hi Rob,

It’s really really cool seeing this progress.
It reminds me of the Yukon series that Pimoroni just released,

Love the website and all of the renderings!

[Rob110829]

Thanks Liam, I was not aware of the Yukon and have just had a look at it. It is indeed very similar although aimed at a different market, IE robotics, whereas I’m interested in BMAC (Building Monitoring and Control).

One take away I got from it is that the modules are plug-in as opposed to my soldered ones. This obviously has many advantages and they actually use the same connector I had on an earlier version for a mezzanine board. I am seriously considering changing my design to use this plug-in arrangement, I have not laid any tracks yet so changes are not difficult to make, plus this would give me a lot more room to run the tracks as the cutouts on the current design restrict that a lot.

Their modules are too small for the things I have in mind, I think I’ll stick with the size, just maybe change to the plug-in model.

Thanks for alerting me to the Yukon, I now have some research to do

[Rob110829]

OK, I’ve done more research and some deep thought and decided to use plug-in modules, details to be decided.

One thing I noticed was that they took 2.5 years to develop the Yukon system and they have a team and a company. I’m a one-man-band sitting in a shipping container in outback Queensland with a million other things to do right now (like building my house)

and only a couple of hours per day to work on this project, so progress will be slow, at least until the house is finished and I set up a lab. To be honest even when I have the time I’m not sure I’ll have the resources to really make a product of this, it might just be used to monitor my off-grid setup and other things around the property. Time will tell I guess.

[Michael]

well this is an interesting take on modularity
It’s pretty cool to consider what modules could drop in, especially since you’ve left cutouts to allow components mounted on both sides of each DOCK module.
I’m guessing each DOCK location use a dedicated set of pins so there are no overlaps - which seems like the most straightforward way to proceed since very pin group is good for I2C and SPI. Very flexible! Thanks for the update @Rob110829 things are looking more and more mature.

[Liam120347]

Hi Rob,

@Rob110829

It is indeed very similar although aimed at a different market, IE robotics, whereas I’m interested in BMAC (Building Monitoring and Control).

Yeah even from the form-factor they looked pretty close - noting the application (and target end users) it makes sense for the Yukon to have a connector but I feel yours could go both ways quite easily!

@Rob110829

One thing I noticed was that they took 2.5 years to develop the Yukon system and they have a team and a company.

Geez, it looked like an involved project but didn’t realise it would have taken quite that long!

Was quite rushed with my response last night…

Its super neat that you have an EEPROM onboard each module as well, Pi Foundation have just started doing that for their HAT+ standard.

The debug features are also soooo good.

Also that board from Insta:

(Source: roy86robotics | Instagram)

Again robotics applications but very neat and makes use of the stacking features (I think?)

[Rob110829]

@Michael

I’m guessing each DOCK location use a dedicated set of pins…

Most are common to all modules and some are unique.

Here is the current pinout for the docks

The highlighted signals are unique, so for example all are connected to SPI and it is up to the module to tristate it’s outputs if it’s #SELn signal is not asserted.

[Rob110829]

I’ve been researching board-to-board connectors today and the lowest profile one I can find is 4.7mm high, I have 16mm headroom between boards and am not sure I want to lose nearly 5mm of that. For example a typical RJ45 socket is 15mm high, that will just make it if I solder modules directly to the PCB, but won’t with any connector.

I like the idea of being able to quickly swap out modules but I think this is a deal breaker and anyway despite there being 26 signals most modules will only use 5-6 I think so that won’t be difficult to unsolder.

Maybe there’s a way to allow plug ins while prototyping with an adapter or something. Nothing springs to mind immediately but I’ll think about it…thinks, if all those connections are on a 100-thou grid it would be possible to mount sockets to the main board and solder header strips to the castellations on the module. In this scenario you would have one main board with socket strips that is dedicated to prototyping, and modules with headers soldered and also dedicated to prototyping or you unsolder the headers and use the module on another main board.

Also this would allow the easy connection of some Vero board for prototyping.

Re the EEPROMs, I would like to learn what information they will have on theirs. I’m thinking I’ll have just module name, type, revision, IO capabilities etc. But wouldn’t it be great to have driver code that could be downloaded into RAM. I don’t know if that’s practical on the RP2040 or even possible, but it would be nice.

[Rob110829]

I’ve decided to stick with the original idea of solder-on modules, partly because the low-profile header/socket strips are expensive, partly because the end result looks better, partly because it is more robust, and partly because I just like it.

But have made a small change to accommodate plug-ins, really just for prototyping but it could also be used in a final application although it’s a bit of a kludge for that.

The dock connections have been slightly realigned to be on a 100-thou grid, the pads in each group where always 100 apart but the three groups of pads where not on the grid as it didn’t matter before. The pads now have through holes to allow the soldering in of socket strips.

This also means that any old proto board can be plugged in.

Apart from a slight realignment of the castilated pads the modules have not changed. Header strips can be soldered onto them and then they can be plugged into the main board like so.

I’ve shown the standard 8mm high socket strips here but lower profile ones could be used and if so the arrangement might still fit under a stacked board. It may not as well but for prototyping that doesn’t matter as the MCU can be on the top of the stack if required.

Thanks everyone, this shows the importance of “spitballing” ideas with a few people as it’s very easy to get locked into an idea and not see variations that make more sense. One of the down sides to working alone I guess

Oh, and I found the specs for the HAT+ EEPROM, pretty simple so nothing to learn there except that it seems the Pi can indeed fetch the driver firmware from the file system, I can’t see a way to do that at present and even if I could I’m not sure that the RP2040 can run position-independent snippets of code.

[Robert93820]

Hi Rob
Interesting project, you have gone to a lot of trouble to finish up (finish???) with a very professional product.

@Rob110829

The dock connections have been slightly realigned to be on a 100-thou grid, the pads in each group where always 100 apart but the three groups of pads where not on the grid as it didn’t matter before.

Well done. You seem to be the only one who considers this. Arduino is a classic example.
Now if all manufacturers had any mounting holes on the same grid it would be marvellous.
Cheers Bob

[Rob110829]

Thanks Bob.

Re the Arduino pin spacing stuff up. I was #3 contributor to the Arduino forum for many years and this was often a topic. I once asked Massimo what the story was and he said that they somehow got the spacing wrong with the 1st prototype and then just decided to run with it.

What?!

So fix it on the 2nd prototype. I find that incomprehensible, but maybe Italians aren’t fussed about such things That decision has caused a lot of anguish over the years.

Anyway, WRT the this design, I may have to reduce the size of the cutouts to give me more real estate to run tracks as all my logic has to be crowded into the middle of the PCB and there are a lot of tracks to run. I’ve done worse but if I don’t have to I won’t. That will reduce the space available for components on the solder side of the docking boards but there’s still plenty for most things I think.