]It can be done, but a special framebuffer driver has to be made. One that pushed the values being read somewhere. The problem with this approach, is that no pins will be read if there is no display updates. Of course additional logic can be added to the driver to handle this. But it's not a good solution, separation of concerns is a good design principle.
I totally agree with the separation sentiment. However, squeezing it all into the available hardware sometimes requires compromises. I did figure that I'd need to customise the fb driver. I also thought of the update issue and I think it'll be OK like that, see below.
I would say making a SPI slave inside the CPLD to read the pins is a good approach, if there is room for that. But then we have the touch panel that uses SPI. Using SPI for the display and the touchpanel occupies the whole SPI bus (CE0 and CE1).
There is definitely room for that, and there is another possibility. If we're modifying the kernel anyway, it would be possible to build another SPI channel into the kernel, at the cost of one additional GPIO signal and one CPLD pin.
What sampling rate do you need? Could you make a I2C slave for instance (400kHz)?
The application is a micro MAME cabinet, so the poll frequency does not need to be super high, I think the display refresh rate would be plenty. Also because of the application, we can be sure that the display will be updated very frequently, especially during game play.
I do want to implement everything inside the CPLD if possible but I have not yet tried to implement I2C with the CPLD. I anticipate challenges with it because some I2C signals must be bidirectional. This is not impossible with the CPLD, but is uncharted territory for me. Also, I2C will eat a lot more CPLD resources because the protocol is that bit more complex.
Thank you very much for your order. I'll ship a kit out to you on Monday morning.
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki