Implementation of Pi-Standard 40-pin header

[mo-g]

So in order to provide the high res 4-lane CSI, the i2c pins are needed. The i2s interface is also needed for sound capture from HDMI. By counterpoint, the CM4 exposes ADC interfaces on the SOM connector that are not exposed through the standard pi 40 pin. It also doesn't expose the 12V rail we have access to through the ATX PSU.

Additionally, the 40-pin IDC connector is not "external grade" hardware.

Since many hats already won't work with the hardware above missing, I propose making a "different" 40-pin connector exposed internally which is not pin-compatible with the standard Pi header, then breaking that out onto the I/O shield with a 37 pin D-Sub connector on a ribbon cable. - Inspired by the Be Inc Geekport.

[TheGuyDanish]

A good point. This is easy to change this early (because I haven't drawn the 40-pin header into the schematics yet). Next prominent question is what other pins we might want to cut away if we are to put the GPIO on an alternate connector? I'm still leaning more towards exposing the GPIO as an IDC header on the rear-panel to keep it user friendly to anyone who wants to experiment with the GPIO. Rather than someone having to break out whatever connector we'd use instead back into regular 2.54mm pins.

[mo-g]

By my count, 8 of the pins on the Pi header are Grounds. We could probably tie some of them together (says the non-electrical engineer)

Exposing it internally but offering a plug-in breakout gives people flexibility. They can use it entirely internally, for something like a panel-mount LCD or Fan control, or they can expose it through a safe and protected connector which has things like a screwlock to hold it in place, or they can just run a good old fashioned IDE cable out of any crack in the case to run it externally without having to solder up a DB37.

If we expose it only externally as IDC - they need to run a ribbon back into the case to do internal projects (fragile and inelegant) - and if using it on their desk, they risk knocking the cable out - potentially damaging their project or piatx logic, but almost certainly damaging the IDC header itself. I do NOT miss bending pins in IDE sockets trying to get a tight fitting drive cable out.

[volkertb]

You two are obviously more well-versed in this than I am, but what about the way how the Raspberry Pi 400 has exposed these pins on the back? Would it make any sense for us to maintain some compatibility with that?

[mo-g]

That's basically what @TheGuyDanish is proposing. The reasons I'm arguing against that approach:

1. We can't be pin compatible anyway, and doings something that "looks" like a Pi standard is likely to lead to people breaking things by plugging "Pi standard" things into it.

2. A fragile connector like that is fine on the Pi 400 because:

• It's a cheap, £70 computer. The board we're designing would likely be more expensive.
• It's designed to be used on your desk or table right in front of you. An ATX case isn't - this connector is going to be awkwardly hidden away from you, and ribbon cables are a poor choice for that scenario - which is why desktop PC's always use D-sub connectors for UART, GPIO and A2D - because they are rugged connectors.

3. And finally, as I said above, doing it this way prevents you from building something that sits internal to the computer - like an LCD or an ISA bus or a fan controller. That's fine on the Pi 400 because there's no free space inside it anyway and you can't easily open it to find out. Not true of an ATX case.

[TheGuyDanish]

(says the non-electrical engineer)

That's still more engineer than I am.

Entertain this thought for a moment. With the microATX standard, we can expect any case this board is put into to have room for four expansion cards. Given the PI7C switch IC we're using can only support three lanes, If we expose the IDC header (or whatever connector we end up using) at the bottom of the board, where the last PCI-e slot would be. It could be possible for a user to (somewhat elegantly, with a custom PCI-e bracket with the right cutout) expose the IDC header, should they really want to. Otherwise, it would be kept internal and can either be accessed or ignored, depending on the user preference.

[mo-g]

That's basically the same concept as mine, except using a backplane slot rather than a D-Sub on the I/O shield. I'm fine with that - reminds me of the way old Winmodems connected to boards in the late 90's, and allows people to export it as D-Sub, IDC, whatever they want - or mount it as an internal card, kind of like a custom "PiBus". I like that approach. Will need careful positioning to allow a simple PC case to have a standard ATX case bracket on and still align correctly with the IDC connector.

More elegant than my approach!

Oh, And I meant I'm a non-(electrical engineer), not an (non-electrical) engineer.

[volkertb]

I like this Winmodem/"PiBus" approach too, the more I think about it. Let the community develop all sorts of interesting cards around this new form factor. Legacy I/O (serial, parallel), sound cards, cards that would expose the pins on the backplate in the form of the aforementioned Geekport or the same port as on the Raspberry Pi 400 if they want, etc.

Are there any kinds of I/O that we would still want to integrate on the board, and which would take up any of the GPIO pins? I believe one of you mentioned an on-board RTC, for instance?

[TheGuyDanish]

On-board RTC is present in the CM4IO board and could easily be lifted if we want to integrate it.

[mo-g]

I'd definitely be in favour of RTC, since it is pretty mandatory for any kind of server needing certificates. I've also already mentioned using i2c and i2s so that which can turn the pair of CSI2 ports into something useful. And I've mentioned a few times I want to ADD the A2D pins to the header, which are missing on the standard pi header. That said, I've just stuck a question up on the Pi forum because I'm a little confused about how i2c plays out with the CSI, etc.

I want GLOBAL_EN, RUN_PG (reset), LED_PWR, LED_nACT (HDD) on the fpanel connector but I don't think any are on the 40-pin header to start with.

[TheGuyDanish]

@mo-g I've done some research this evening, and I actually think we can present i2c pins on the GPIO header without drawbacks. While the TC358743XBG internal registers can be modified over i2c, it doesn't seem to be a hard requirement. If you look to some of the boards that demo it, such as the Auvidea B101, they aren't connected to the GPIO pins at all, meaning the chip surely doesn't require the i2c connection.

In addition, after some more reading up, connecting two of these chips (which would be necessary to facilitate two HDMI inputs) to i2c would cause another conflict, in that they'd likely conflict on their i2c addresses. Newer versions of this IC have a specific selector to allow you to chose either a master or a slave i2c address to prevent these collisions, but the one we're looking at for this doesn't.

In summary: i2c for the people!

[mo-g]

And also on the fan controller and RTC! I think I was misunderstanding what i2c was being used for in the CSI connectors. Thanks for helping me understand.

Thinking about i2s - You have separate pins for din and dout, with the Pi's clock source defining it as the master. Which means, that we should also be able to include the clock and DOUT on the 40-pin.

I was thinking about a Pi Laptop/AIO board concept as well, and the idea that I can use i2s for both CSI in and a proper DAC for audio is appealing. I guess (if my assumptions about DSI are correct), we could route i2s and dsi to a Displayport connector on this ATX design, but dual HDMI plus Displayport seems excessive, don't you think?

[TheGuyDanish]

but dual HDMI plus Displayport seems excessive, don't you think?

Absolutely. For the time being, I'd like to keep the board to as minimal a number of specialized ICs as we can and, hopefully, provide a board that is cheap enough for most people to really get down with. I'd love to add features into eternity, but I'd also like to have a simple proof that it works. An IO board + PCI-e lanes, really. Anything else would be a benefit. Once we have a board that is proven and works, we can make the incremental improvements like more ports, chips, etc.

[mo-g]

100% on the KISS approach. :)

[volkertb]

Agreed.

My first instinct was to propose adding everything but the kitchen sink to this board. But on second thought, keeping it as simple as possible would indeed be the best way to go. The addition of any logic would increase price, make it more difficult to develop, add points of failure, and reduce flexibility from the perspective of the user. Basically: if it's something that the users can easily add themselves as a PCIe card or something that plugs into a USB port, don't integrate it.

Like you said, a deluxe version with more integrated stuff can always be developed later if an initial basic version proves successful.

Also, since there will only be a limited number of PCIe interfaces available, as well as a limited number of GPIO pins, perhaps we should try to use USB 2.0 as much as possible for whatever features we do end up integrating on the motherboard. For instance, are there any RTC chips out there that can work over USB? If so, wouldn't that be preferable over a GPIO-based RTC solution, since it would save precious GPIO pins while offfering the same functionality? It's not like an RTC requires a lot of bandwidth, right? Of would latency become too much of an issue?

[mo-g]

The connection for the RTC is by i2c, as is a fan controller (at least on the I/O board, but we should probably copy that). i2c is a shared bus, which means that you can hook it up to multiple things at once, as long as there aren't any weird conflicts like having two of the same device.

The "can't use i2c if we use it for the camera" thing was never actually a real issue, but came from my lack of understanding about these protocols (there's a reason I didn't make this design!) Thankfully @6x9 has helped clear up my confusion. In fact, we can actually expose two independent i2c interfaces on the header. (which we could also hook to our two HDMI chips as well. Yay, shared bus!)

As of right now, the only things we're "using up" in I/O is both CSI-2 interfaces (pretty useless inside an ATX case, but handy as HDMI in) and the data-in pin of the i2s interface - which can still be used for a DAC on the expansion header. It means you couldn't add an i2s microphone to the board - but big deal, that still leaves four other, better ways to connect a Mic. The only other thing is that the GPIO for the i2c clock can't be reused as normal GPIO - only as the clock for a DAC.

Long shot of this is we could TECHNICALLY still expose a standard pi 40-pin header, minus the i2s DIN pin. But I'm still not sure we should. Apart from other things, I really want to expose the ADC functionality which is not available on the Pi 40 pin. But, that could be achieved with say a 44-1 pin or 60-1 pin or w/e length header which carried the 39 remaining pins of the Pi's header in the standard layout, plus any others we care to expose - like the ADC's.

[paulwratt]

as long as there is a way to add a regular RPi 40pin (via an adapter) and that this different 40pin port wont fry a regular HAT or vice-versa. you might try placing it in such a way that RPi hats cant physically fit (without an adapter plate)

ie. having a "regular" 40pin port and that not being RPi compatible is just "begging for pain" in the future.

are there currently any N/C connections on the CM4 dual connectors, as these might be made use of in a CM4+ or CM5 in the future

the only things we're "using up" in I/O is both CSI-2 interfaces (pretty useless inside an ATX case, but handy as HDMI in)

there are already CSI-HDMI extension boards (I have one from 2016) that allow use of an HDMI cable to extend a RPi compatible Camera module over the CSI interface. There is also at least one HDMI capture board available for the CSI-2 interface: https://geekworm.com/products/raspberry-pi-hdmi-to-csi-2-adapter-board-with-15-pin-ffc-cable

whatever you do with this bus, try to use a physical interface that is easily available, either as ribbon connectors or pluggable connectors (so many grate computers have been killed of by expensive or non-exsistant interface parts)

[mo-g]

I wouldn't want to run CSI out of a case with something like a HDMI connector, for the same reason you don't want a 40 pin port if it's not a hat connector - standard port must have standard protocol. The geekworm product is where I discovered my idea was achievable, hah.

My thinking for the HDMI in was- gamers can use it to stream or just display the video from a console or another computer. Hackers can use it to have the display output from another pi or other "project" device available without needing to bring a second monitor. And anyone who needs a webcam can easily use an old video camera (probably for less than the cost of a Pi camera) without needing to rely on USB. A camera module doesn't seem an inherently useful device in an ATX case. Even DSI seems more useful since it can be hooked to like - drive bay displays, or server control panels - or just like, a "case window" that plays a movie of some badass gaming PC from 2010 instead of showing the raspberry pi.

I think it would be a really good way of exposing an internal only connector as a widely useful connector in a desktop PC environment. And if someone really wanted to build a desktop camera for an ATX pi using a CSI camera module - there are other ways to still achieve it - like, connect it to a 0 and run it over USB. I try to think of this not as what's useful in a dev board as what's useful in a PC. No-one is going to buy this to use it as a dev board when the CM4 I/O is literally 1/7th the price and much smaller. But I haven't put the engineering work into this, only conceptual stuff. So; I understand if it gets kicked. :laughing:

As for NC pins - yes, there are a couple. Good point. I've actually had the thought a few times about exposing the GPIO and other junk (which we've joked about calling the PiBus) as a card edge connector. That way no connectors at all are needed, just a PCB - and people could easily sell "protoboards" which are just a PCB with the correct edge connector pins and any pads you could want. Would be less fragile as a bus, cost about the same to implement - and an 8 bit ISA slot (positioned at the wrong distance so people can't actually plug an ISA card into it) would give us plenty of pins to spare for the A2D, NC, anything else that gets exposed by other IC's on the board.

[TheGuyDanish]

A crucial part of this is that I want to expose a 40-pin GPIO header that is, as closely as possible, pin-for-pin compliant with the pinout on the Raspberry Pi 4. I don't want to break compatibility with any HATs that people might want to use (except maybe the PoE hats, but that's a different debate) my primary idea for how to best achieve this is really also the simplest one.

Expose the 40-pin header as it is. If we need to connect something else (say an IC somewhere on the board like a fan controller or HDMI-CSI2 bridge), we only connect it if it can go on a bus like i2c. Last thing I want is for someone to plug in a HAT and fry it. We can write as much documentation as he want about how the pinout could potentially differ but someone, somewhere, is invariably going to not read that.

[mo-g]

To be fair, even my "I want i2s for HDMI audio capture" argument is as simple to solve as sticking a jumper or dip block on the board to route the pins, same way the I/O board does for i2c on the camera connector.

Would you agree in having a second connector, in line (and in pitch) with the 40 pin - for the "extra" pins like the reserved, a2d, etc?

[TheGuyDanish]

I could see it. I'd want to physically separate it from the GPIO header by a few millimeters, to prevent any unfortunate misunderstandings from anyone assuming it's a part of the regular 40-pin assembly, and have documentation for it on the silkscreen itself.

[mo-g]

Agreed. One thought I had was just to use a (picking a random number) 60 pin header with a few rows of pins removed to make a clear separation - while ensuring they're also held in pitch so they can be connected to with a single female connector?

[TheGuyDanish]

In 9a986fd, the 40-pin header has now been exposed at the bottom of the board. If anyone has requests for other pins, please post a comment in here with their names and locations and I'll look into including them on a separate header near to the GPIO header.

[TheGuyDanish]

As I've had no comments on this, and the 40-pin header is now exposed on the port (location pending final placement), I'll go ahead and close this issue for now. Any outstanding comments are still welcome.

[funkyguy4000]

Are we sure that we want the 40-pin header at the bottom of the board? It looks like there might be some overhang which might not allow the motherboard to fit in a standard Micro-ATX case if the user wants to use the 40-pin as is. It seems like we might have better luck having the spot where the 40-pin header is be some sort of other card edge connector, maybe a little offset a little closer to the bottom of the board, and then there would just be an adapter card that turned it into a standard 40-pin. That could then put the connector opposite the other side of the pi HAT so the traditional output side of the HAT is out the back like a standard PCIe card.

[TheGuyDanish]

I'm anticipating that we may have more spare room on the bottom of the board, especially behind where the 40-pin header is located now.

We could move the 40-pin header further back, perhaps behind where the PCI-e slots are now, then let users decide if they want to put a HAT on it, or use something like a 40-pin IDC header to bring it somewhere else.

One of the ideas I think we originally discussed for this was something like a simple PCI-e bracket/card to expose the 40-pin header externally, so it would be similar to the Pi 400 in appearance. That way, people can use it, both inside the case, and on the outside, if desired. Though the placement of the header itself doesn't really matter in that context.

As ever, I'm happy to hear other options, though. I really want to avoid adding another layer of complexity to it in the form of new connectors. If any new connector is to be added, I would like for it to be one that is fairly common, that people wouldn't struggle to track down cables and mating parts for.

[mo-g]

I previously had the same thought, @funkyguy4000 - but - if the 40-pin connector is aligned properly, a card with a female header block soldered to it and a standard PCIe bracket screwed on - would sit on the header no differently to using a card-edge.

If someone wants to use the hat connector, they could use a bigger case - or more likely, use a "vertical riser" that lets any ports on the hat stick out of the back of the case. That could also add a geekport connector, or a 40 pin HAT-on-the-Back, or something completely custom.

@TheGuyDanish

If anyone has requests for other pins, please post a comment in here with their names and locations and I'll look into including them on a separate header near to the GPIO header.

IP0, IP1. nRPI_BOOT, EEPROM_nWP would be the other pins I'd want exposed on that connector.

If you went for a 48 pin header, then you could have IP0/IP1 as a row, pair each of BOOT/nWP with a ground to allow them to be pulled low, then have a pinless-row to keep them physically separate from the rest of the 40 pin?

[TheGuyDanish]

@mo-g IP0 and IP1 will need to be exposed somewhere, for sure.

nRPIBOOT and EEPROM_nWP are already exposed on J20, the 2x4 pin header on the bottom right hand side of the board.

[funkyguy4000]

Just throwing an idea out here, since the nRPIBOOT and EEPROM_nWP are critical to using the CM4, relative to the board purchased, would it be possible to wire those to toggle switches somewhere? Maybe the IO Shield, maybe somewhere internal? It'd be a simple feature to implement and a large portion of the users will need to do this function already.

Edit: I like the idea of having it on a header too, we could have a jumper that chooses where the net goes, either to the toggle or the header.

[mo-g]

Simplest answer would just be to have them on a header adjacant to a ground pin - that way they can be jumpered where they are, or put on a toggle with nothing more than a crimped plug and two lengths of wire. That gives a lot more flexibility as well, since you can run the wire to the back of the case, or to a front drive bay.

I don't see an I/O shield toggle being useful. For the effort of getting to it where my desktop is, I'm as well off to take the side panel off and change a header. I appreciate everyone's desk is different! I'd also be worried about accidentally switching it while moving the PC into place. Since you only need these for a firmware update (and most users of this aren't going to need to set nWP) or if you spectacularly hose your OS (BOOT) - I don't see them really needing easy external access.

Maybe an I/O shield DIP switch would work better, if you were to move them anywhere?

[erkinalp]

With a +VCCs and a few GNDs merged amongst each other, a 29-pin HDMI dual link connector could be reused.