Alternate GPIO Control
Added by Tom Riddle over 6 years ago
Hi,
Direct GPIO control from the L138 is pretty nice to have. In our current task we need a number of GPIOs, more then what is available on the expansion connections when considering the other L138 functions we are using. The ability to use the Critical Link GPIO FPGA core is, of course an option.
So of the interfaces between the L138 and the FPGA, we only plan on using EMIFA and the uPP. With UHPI, MMCSD1, LCD and VPIF not utilized, the pin-mux tool shows a number of GPIOs in groups GP6, GP8 pretty much free. So if we configure them as GPIO and implemented a simple signal "pass thru" in the FPGA to the appropriate FPGA_IO pins we'd be good to go? Just wanted to make sure I'm not missing anything obvious with this approach. Thanks, Tom
Replies (2)
RE: Alternate GPIO Control - Added by Gregory Gluszek over 6 years ago
Hi Tom,
One concern I have regarding your proposed approach would be the case of your GPIOs needing to be run-time configured as inputs or outputs. Configuring your FPGA passthrough ports to be inouts may be sufficient, but you may also need some logic in the FPGA to indicate the direction of the passthrough. Of course if your GPIOs are always going to be inputs or outputs this will not be an issue.
Another option would be to add an instance of Critical Link's gpio vhdl core to your FPGA and connect it to the FPGA pins you want to use as GPIOs. The fpga_gpio Linux driver that interfaces with this core will allow you to control the GPIOs from the ARM via Linux in the same manner as any other Linux GPIO. Similarly the DspFpgaGpio DSP core library class would allow you to control these GPIOs from the DSP.
Let me know if you have any questions.
Thanks,
\Greg
RE: Alternate GPIO Control - Added by Tom Riddle over 6 years ago
Greq, good point WRT the inouts... thanks for bringing it up. In our case they were going to be dedicated outputs. Either way it's great that CL supplies those cores, no doubt they will be utilized. Regs, Tom
