Update on LCD module connection ideas

GOOD NEWS - CAN PICK ANY FPGA SIDE IO PIN TO TRIGGER LINUX INTERRUPTS

The System on Chip (SoC) integrated circuit includes a handy feature to deliver up to 32 interrupts to the Hard Processor System (HPS) side to be handled by Linux, allowing me to route a signal from the Field Programmable Gate Array (FPGA) side including from external connector pins. Thus, I can route the Touch Screen interrupt over a general purpose I/O pin on the FPGA.

From a software side, I need to register an interrupt service routine (ISR) for the interrupt that will be seen when my I/O pin goes active from the Touch Screen. Interrupt numbers from 73 upwards are assigned to the block routed from the FPGA side. I have example code thus I expect this to be relatively painless to accomplish. One signal down, several still to go. 

BAD NEWS - STILL HAVE SHORTAGE OF HPS SIDE GPIO PINS

That still leaves me with a deficit of external connections to the HPS side. I need two pins to select the two devices - LCD and touchscreen - of the module. I need another signal to indicate when a particular communication is data and when it is a command to the LCD. Why not route the HeadLoad signal the same way, as it is probably just as easy to route five as four. That does mean I don't need to tack onto the User Key pushbutton at least. 

HOW I THINK THIS CAN BE HANDLED

Four of these signals are outputs - the HPS side will write to these and we just need them to get to an external connector. We can make the H2F bridge responsible for sending these bits in addition to its role reading and writing blocks of four 16 bit words for cartridge loading and unloading. All we need is to assign unique addresses to the two roles, use address range splitting to route the write transaction from the HPS side to a new bridge and state machine to accept and output those signals on the I/O pins. 

The HeadLoad signal is, however, an input not an output. Therefore the H2F bridge is not ideal for this because it is the Linux side that decides when to read or write, possibly missing a drop of the signal for a while. There are two methods that come to mind for dealing with this input signal. 

One is to continue with my plan to wire to the User Key pushbutton on the HPS side. That way the Linux program can simply read the state of that 'pushbutton' to see whether the heads are still loaded or not. That way the Linux program can check often and immediately send the command to turn off drive_ram. 

The other way is to update my H2F LW bridge to interrogate the state of drive_ram by reading to a new dedicated address different from the Status word. This runs the risk of extended delay recognizing the signal having gone off. I can minimize the impact by ensuring that the FPGA side immediately shuts off drive_ram and not waiting for the HPS side to send that command.