new piCaps in the works?

[tbone321]

I hope that if they make any revisions to it that they add a header to access the GPIO pins for things like input switches or outputs to control relay boards. 

[JonB256]

I hope that if they make any revisions to it that they add a header to access the GPIO pins for things like input switches or outputs to control relay boards. 

If you were to build your own (like with Bwinter's 8 output DPIPixel board - scroll UP a ways to read about them. https://www.tindie.com/products/bwinter/pi-cape-8p/

just use a header with LONG pins and you will have plenty of GPIO access. (I don't know which ones would be available). I just got my parts to assemble 2 of them. I luckily have 2 Pi 3B+ doing nothing right now.

[Bwinter]

One thing to consider, is that the new DPIPixel protocol uses *all* the existing GPIO pins.  I'm not sure if there is a means to completely "disable/decouple" those extra GPIO pins from the DPI protocol (for example, on an 8-port hat)—or if that's even something that would be necessary.

[JonB256]

One thing to consider, is that the new DPIPixel protocol uses *all* the existing GPIO pins.  I'm not sure if there is a means to completely "disable/decouple" those extra GPIO pins from the DPI protocol (for example, on an 8-port hat)—or if that's even something that would be necessary.

The "all GPIO pins" by DPIPixel in use didn't occur to me. I know you are only using 8 of them so I assumed the others could be used. Perhaps I'll experiment when I get my last parts (the power terminals are backordered).

[Bwinter]

Side note:  the 4P terminal blocks may be back-ordered—but two 2P blocks can be coupled into one 4P (there's a small grove on the side that allows them to be joined).

[Bwinter]

The "all GPIO pins" by DPIPixel in use didn't occur to me. I know you are only using 8 of them so I assumed the others could be used. Perhaps I'll experiment when I get my last parts (the power terminals are backordered).

I have played around a little—and I can still toggle the GPIO outputs, so they are useable. Just have no idea how stable they would be as input/outputs given that they are still assigned by the DPIPixel protocol.

[CaptainMurdoch]

One thing to consider, is that the new DPIPixel protocol uses *all* the existing GPIO pins.  I'm not sure if there is a means to completely "disable/decouple" those extra GPIO pins from the DPI protocol (for example, on an 8-port hat)—or if that's even something that would be necessary.

The DPIPixels Channel Output code is smart enough to not enable a GPIO output pin for DPIPixels use if there are no pixels configured on that output.  So, if you use the 24-output config but only have pixels defined on the first 4 outputs, then the other 20 GPIO pins are still available for other use.

If your board has its own EEPROM instead of using the virtual EEPROM included with FPP, you can choose how many pins you want to allow for DPIPixels use. In this case, the above paragraph still holds true, if you configure the EEPROM for 8 but only use 4, the other 4 are available for normal GPIO use.  If you are only using GPIO as outputs, and had a pixel cape with unused outputs, you could actually connect your GPIO output wires to the data pins on the unused pixel output connectors instead of having to go to the pins on the Pi directly.  This would also give you 3.3V -> 5V level shifting and isolate/protect the Pi's GPIO pin.

[Bwinter]

Thanks—that's what I was hoping, but glad you confirmed.