Wed Aug 29, 2018 7:31 pm
Hi,
I have a Neo2 and 2.8" resistive TFT module. I would like to connect some custom peripherals and build an application to control those custom peripherals with display+control via the TFT module. The custom peripherals I am thinking of will mostly likely be an i2c GPIO 'port expander' and some SPI bus DACs. Looking at which Neo2 pins are not used by the TFT I see I2C0_SDA/GPIOA12 and I2C0_SCL/GPIOA11 are free which is good for my port expander. I was thinking of connecting the DAC chips SPI bus lines to SPI0_MOSI/GPIOC0+SPI0_MISO/GPIOC1+SPI0_CLK/GPIOC2 and using the outputs of the port expander as the individual DAC chips SPI bus chip-select lines. The thing that worries me is the sharing of the SPI MOSI,MISO,CLK bus lines between my (driven from user mode, probably using WiringNP) DAC chips and the (driven from the kernel) TFT module. Am I likely to get conflicts on those bus lines when the kernel pre-empts my (user mode) application to update the TFT display? If so is there a workaround or will I need to write a kernel driver to control the accesses to my peripherals? I'm sorry if the answer is obvious but I'm new to this!
Many thanks
Tom Crane
I have a Neo2 and 2.8" resistive TFT module. I would like to connect some custom peripherals and build an application to control those custom peripherals with display+control via the TFT module. The custom peripherals I am thinking of will mostly likely be an i2c GPIO 'port expander' and some SPI bus DACs. Looking at which Neo2 pins are not used by the TFT I see I2C0_SDA/GPIOA12 and I2C0_SCL/GPIOA11 are free which is good for my port expander. I was thinking of connecting the DAC chips SPI bus lines to SPI0_MOSI/GPIOC0+SPI0_MISO/GPIOC1+SPI0_CLK/GPIOC2 and using the outputs of the port expander as the individual DAC chips SPI bus chip-select lines. The thing that worries me is the sharing of the SPI MOSI,MISO,CLK bus lines between my (driven from user mode, probably using WiringNP) DAC chips and the (driven from the kernel) TFT module. Am I likely to get conflicts on those bus lines when the kernel pre-empts my (user mode) application to update the TFT display? If so is there a workaround or will I need to write a kernel driver to control the accesses to my peripherals? I'm sorry if the answer is obvious but I'm new to this!
Many thanks
Tom Crane