W. H. Heydt wrote: ↑

Thu Nov 13, 2025 10:48 pm

Not sure I've ever seen a dual-UBS-C device.

I can name three: Macbooks, Mac Minis, and Microsoft Surface. And some desktop PC motherboards. There are probably more. My Surface Pro 9 has four ports: 2 USB C (both support PD and displayport alt mode), a propitiatory charger port, and a propitiatory keyboard port.

As for the other point... What "chipset"? The Pi5 (the only model--counting the Pi-500+) that has an exposed PCIe lane has that lane directly as part of the SoC. The only thing on a Pi5 that could be remotely be considered a "chipset" is the RP1 that handles the low speed I/O, and is--therefore--a sort of equivalent of a north bridge chip.

Nope. The RP1 handles high speed IO too. It contains ethernet, USB 3 and USB 2 controllers and interfaces to the 2712 via four PCie lanes just like a PC chipset/southbridge does (though that calls the link to the CPU by another name). Add a PCIe packet switch to that and you'd get more lanes almost the same way an x86 box does.

Knowledge, skills, & experience have value. If you expect to profit from someone's you should expect to pay for them.

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

W. H. Heydt wrote: ↑

Thu Nov 13, 2025 10:48 pm

I can see future Pis going to either more PCIe lanes exposed (with the resultant trace routing nightmare) or a faster PCIe lane (with its own difficulties), or both.

I think you immediately run into space problems on the standard Pi size. One possibility is for RPL to add short distance optical links. There's a really good paper on how this is done on the Synopsys website
https://www.synopsys.com/articles/pcie-over-optics.html

RPL seem to use Synopsys IP in their own custom devices so could go in an RPx device.

Always interested in innovative audio startups needing help and investment. Look for InPoSe Ltd or Future Horizons on LinkedIn to find me (same avatar photograph)

A commercial version of SolaSec's Raspberry Pi based DEF CON badge would be nice, though perhaps something more for a third-party to deliver than Raspberry Pi themselves.

I would prefer an LCD touch screen but I'd take whatever I could get. I would create something myself but I don't have the skills. Cost, power delivery, and compactness, are probably the biggest challenges as always. This is one of those product domains where access to the CM0 could prove useful.

Having just struggled to fit a potential project onto a CM5, I'd like to see an option with more I/O, more PIO blocks, possibly a wider range of peripherals, and possibly more choice in pin assignments. (I should probably be looking at alternative SOMs but, as with others, the support for the CM5 makes it worth persevering with it unless I hit a road block).

For me, the number of SPI, UART and I2C peripherals is just enough (after repurposing a few otherwise unused pins), but pin allocation constraints got in the way, and the last SPI instance actually uses PIO (which fortuitously may benefit one of my functional blocks).

[I did consider implementing the UART transmit channels on PIO, which would also improve RS-485 performance in controlling RTS, but that would take a significant extra effort to "patch" it into the serial interface; and possibly not enough PIO capacity anyway]

Lack of I/O pins means I'm using an external PAL to sequence some of the logic (this could easily go in the PIO, if enough I/O pins were available), and extra I/O is over I2C where I'd prefer direct access or SPI.

I've also added an interface to support 2 x CAN channel, and possibly industrial Ethernet (which takes up an SPI port and CSn pins).

The 1.2/2.4 usec latency on the PCIe interconnect to the RP1 was very nearly a killer, since I need to do a lot of small read/write transfers (think accessing a "classic" 8-bit data bus), although I've worked out a way to do that which is still a bit slow, but acceptably so.

This would probably necessitate a bigger variant of the RP1, and either a bigger footprint CM5 or one with a repurposed second connector (One HDMI output, one display output and one or two USB ports would suffice) so unfortunately probably wouldn't justify the investment unless it fits in with plans for successor modules. Or could two RP1 be used?

stevend wrote: ↑

Fri Nov 14, 2025 3:20 pm

The 1.2/2.4 usec latency on the PCIe interconnect to the RP1 was very nearly a killer, since I need to do a lot of small read/write transfers (think accessing a "classic" 8-bit data bus), although I've worked out a way to do that which is still a bit slow, but acceptably so.

Though not a product, I would like to see a thread on solutions to deal with the PCIe latency seen on Pi 5 and CM5 GPIO.

W. H. Heydt wrote: ↑

Wed Nov 12, 2025 10:21 pm

ejolson wrote: ↑

Wed Nov 12, 2025 9:12 pm

No dangerous splitter cables for me please. I'd like to see a 1000W supply with 40 USB-C PD outputs that each negotiate 5V at 5A.

I shudder to think what that would cost. On the other hand, a 110W with 4 USB PD 5.1v 5A ports is something I'd find useful. Though to go with it, I'd like to see 1M and 2M USB cables with 18GA power wires, rated to handle 5A at 5v (and, of course, with the needed internals to pass along the relevant PD data).

Such cables exist. Only issue is that the genuine 5A smart cables, especially if encased in the woven high bend/durable fiber sleaves, are bulkier and stiffer. They are backwards compatible with the lower standards, and result in one less cable I have to carry in my travel bag.

Only issue these days is you have to pay a double premium for them (name brand/reputable supplier premium to actual get a spec compliant cable, and thicker wire, lower volume premium). However, after dealing with a number of issues that turned out to be crappy cables, I am happy to pay more, rather than play Amazon or AliExpress purchase/return roulette with noname cables.

thagrol wrote: ↑

Thu Nov 13, 2025 11:46 pm

W. H. Heydt wrote: ↑

Thu Nov 13, 2025 10:48 pm

Not sure I've ever seen a dual-UBS-C device.

I can name three: Macbooks, Mac Minis, and Microsoft Surface. And some desktop PC motherboards. There are probably more. My Surface Pro 9 has four ports: 2 USB C (both support PD and displayport alt mode), a propitiatory charger port, and a propitiatory keyboard port.

Lenovo chromebook 2/1 as well. I love mine though I wish in had the taller form factor that the Surface does. Is amazing at the price point. My Surface 10 Pro also has the same 2 USB port config as the 9... just costs 7 times as much as the chromebook.

stevend wrote: ↑

Fri Nov 14, 2025 3:20 pm

Having just struggled to fit a potential project onto a CM5, I'd like to see an option with more I/O, more PIO blocks, possibly a wider range of peripherals, and possibly more choice in pin assignments. (I should probably be looking at alternative SOMs but, as with others, the support for the CM5 makes it worth persevering with it unless I hit a road block).

We ended up going back to CM4s with lots of RP2354s to do all the I/O and even some of the processing.
And I've yet to find a peripheral other than USB and Ethernet that isn't better on a PIO :-)

Always interested in innovative audio startups needing help and investment. Look for InPoSe Ltd or Future Horizons on LinkedIn to find me (same avatar photograph)

MikeDB wrote: ↑

Fri Nov 14, 2025 6:02 pm

And I've yet to find a peripheral other than USB and Ethernet that isn't better on a PIO :-)

Having done a lot with STM32 single chip devices, that's rather the impression I'm getting as I dig further. (and then you run out of PIO....). But I'm already on a steep learning curve with the CM5, so with one exception I'm going to live with the specific peripherals until I hit a snag.

stevend wrote: ↑

Fri Nov 14, 2025 11:17 pm

MikeDB wrote: ↑

Fri Nov 14, 2025 6:02 pm

And I've yet to find a peripheral other than USB and Ethernet that isn't better on a PIO :-)

Having done a lot with STM32 single chip devices, that's rather the impression I'm getting as I dig further. (and then you run out of PIO....).

Same here. We used to use the STM32H750 in large numbers to get enough I2S ports, so the RPL devices with PIOs do this much cheaper. I ditch all the random other peripherals and just add more PIOs.

Always interested in innovative audio startups needing help and investment. Look for InPoSe Ltd or Future Horizons on LinkedIn to find me (same avatar photograph)

an extra GPIO header would be fine, feat an 8-channel 12bit ADC, driven by a common widespread μC (e.g., MCP3208 or comparable, supported by wiringPi libs) plus 1 or 2 extra i2c ports (as i2c-0 is reserved to HATs and having just i2c-1 is too limited)

bigkahuna wrote: ↑

Sat Nov 15, 2025 11:46 am

an extra GPIO header would be fine, feat an 8-channel 12bit ADC, driven by a common widespread μC (e.g., MCP3208 or comparable, supported by wiringPi libs) plus 1 or 2 extra i2c ports (as i2c-0 is reserved to HATs and having just i2c-1 is too limited)

WiringPI is deprecated and has been for years.

Why use an MCP3208 when the in house RP2 could be used?

IIRC more I2C busses are available on 2711/2712 based Pi.

Knowledge, skills, & experience have value. If you expect to profit from someone's you should expect to pay for them.

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

thagrol wrote: ↑

Sat Nov 15, 2025 1:17 pm

Why use an MCP3208 when the in house RP2 could be used?

IIRC the Pico A-D has some odd characteristics which limit its accuracy. IMHO there's no point putting a separate A-D chip on-board; having it external means that users can pick the most appropriate one for their application (and aren't paying for it if an A-D isn't needed). There may be some mileage in having an A-D if its integrated into an RP1 successor or similar as an optional use of a pin. Then those for whom the performance of the on-chip A-D is adequate would benefit, and those who need better performance are no worse off.

thagrol wrote: ↑

Sat Nov 15, 2025 1:17 pm

IIRC more I2C busses are available on 2711/2712 based Pi.

AFAIK some of the Pis use hardware multiplexers to share a couple of I2C interfaces round a number of separate busses.
The Pi5/CM5 has more separate I2C interfaces (thanks to the RP1), which are potentially usable if not assigned for their intended purpose; for example, two more interfaces are available if not using cameras. Straightforward on the CM5; however on the Pi5 physically accessing the relevant pins might be challenging. (See viewtopic.php?t=393448)
There's a PINCTRL command which shows all possible uses of all I/O (specify the upper limit of the pin range as about 55), so is very helpful in seeing your options. (The "official data sheet" only lists options for the pins brought out to the 40-pin header).