Hi,
It appears that A0-A5 just go to a pin header so I need to use jumper wires to take these to an appropriate PMOD header so I can use these as Digital I/O?
Note: I
D0 RX use as is (not required in my design)
D1 TX use as is (not required in my design)
D2 Digital I/O use as is
D6 Digital O shared with LED1, this is OK as I want to use as an output, should I unsolder LED1 or will it work a bit like a pull-down output port?
D7 Digital O shared with LED0, this is OK as I want to use as an output, should I unsolder LED0 or will it work a bit like a pull-down output port?
D8 Digital I/O shared with "FLASH_CS" how / can I use this pin with an Arduino shield as looking at the Logo-Pi schematic this appears to interfere with U10 the flash chip??
D9 Digital I/O shared with "FLASH_SDI" how / can I use this pin with an Arduino shield as looking at the Logo-Pi schematic this appears to interfere with U10 the flash chip??
D10 Digital I/O use as is
D11 Digital I/O use as is
D12 Digital I/O use as is
D13 Digital I/O use as is
SCL/SDA how to I use this on the FPGA vs how to route it to the Raspberry Pi?
Is it possible to map the SPI / I2C from the Raspberry Pi to different pins so I can route them to A0-A5, D0, D1, D12 & D13 to create an I2C interface ( 2 pins) and a SPI interface (3 pins) with 5 CS for 5 devices, or is it easier to simply create a I2C and SPI interfaces on the FPGA and route to those pins??
The standard UCF file doesn't seem to have a full Arduino section, has anyone written one for Arduino Shields as such?
Cheers
Douglas
Comments
Yes, it can be a bit tricky if you are trying to use all the arduino pins. We had to share some of the fpga pins in order to get all of the functionality onboard. We tried to only share pins that would cause have minimal impact. Hope you are able to work around this as needed.
"It
appears that A0-A5 just go to a pin header so I need to use jumper wires
to take these to an appropriate PMOD header so I can use these as
Digital I/O?"
Correct. The idea is that is if the arduino shield uses an analog input it will need to be jumpered to an ADC or to a device with analog functionality.
O shared with LED1, this is OK as I want to use as an output, should I
unsolder LED1 or will it work a bit like a pull-down output port?
with LED0, this is OK as I want to use as an output, should I unsolder
LED0 or will it work a bit like a pull-down output port?"
You should have no problems using as is. The drive for this line will only need to power ~ 1mA to maintain, high/low with the LEDs running (current depends on forward voltage of LED).
Are you planning on using flash simultaneously? If not then it will not be a problem as the flash CS line is Hiz and will not conflict with alternate usage. If using SPI simultaneously you will need to time the functionality and tristate the fpga pin of the line sharing devices to avoid conflict.
Same as above.
You can use the FPGA as a master or slave I2C device. For mast mode you will need may need to disable the I2C on RPi. The i2C pins from the RPi connect to the FPGA and to the Arduino shield. You can disconnected these from the arduino shield using solder jumpers JP6/JP7 which are connected by default. To disconnect you will need to cut the small jumper trace - then solder to reconnect if wanting to use again.
Is it
possible to map the SPI / I2C from the Raspberry Pi to different pins so
I can route them to A0-A5, D0, D1, D12 & D13 to create an I2C
interface ( 2 pins) and a SPI interface (3 pins) with 5 CS for 5
devices, or is it easier to simply create a I2C and SPI interfaces on
the FPGA and route to those pins??
You can route the RPI SPI pins to any of the FPGA pins as needed. You just need to route them internal to the FPGA. So if you are not using all of the PMOD pins you could route the SPI pins to a pmod and then jumper them to the AN pins. For D0,1,12,13 you can directly re-route the SPI within the FPGA. I2C will not work this way as all of the lines need to be externally physically connected in order for the open drain to pull all lines low. It may be easier to just instanciate SPI/I2C within the FPGA and have communication logic within the FPGA.