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. :)