The Arm processor on one of our boards has an spi port with two chip select lines.
It is mentioned in the processor's datasheet that it can control upto two spi devices.
Is it possible to use a GPIO as a slave select for an additional spi device?
How to modify the existing libraries/device drivers to support this change?
So far i've found a file in the kernel's source which contains the addresses of SPI port pins. Can anyone plz tell in which direction should i proceed?
If you have enough pins, you can bitbang the whole SPI protocol and use as many CS as you need.
You don't mention what processor it is. You have three possibilities.
If the processor has an i/o mux capabilities, turn off the SPI chip select functionality. The SPI controller will think it has asserted the line, but it won't go external.
Don't connect one SPI chip select. Use a pull-up/down for ESD protection.
Multiplex the chip select as per Joachim Isaksson
In first two cases, connect GPIOs to the additional device's chip select. Toggle the GPIO manually before running spi_write(), etc. This will allow the SPI controller to transfer at higher rates than are possible with bit banging and is a better system design. Ie, lower power consumption, lower CPU use, faster data rates, etc. If the peripheral is just for setup/boot, then the bit banging makes sense for simplicity. However, if your main operation depends on the SPI bus, you could consider this solution.
If only one peripheral needs the SPI for setup AND you have the i/o mux, you can disable the chip select functionality during setup, using a GPIO to select the setup peripheral and then re-enable the spi chip select during standard system operation for the other peripheral.
Using a GPIO doesn't require user space intervention. Drivers can provide call backs to set the GPIO when in use, so SPI commands can be buffered/queued and these solutions still work. For instance, the IMX SPI driver supports GPIO toggle by passing a negative chip select number to denote a GPIO id.
Note: Some SPI devices may require the chip select to toggle between words; what ever a word is for the device. Some controller may leave the chip select asserted when transferring multiple words. You need to get this right if you use a GPIO to manually select devices. I am sure some standard defines this, but definitely some device don't follow the standard.
Addendum: Most drivers support a GPIO chip select; via a negative chip select value. They will call Linux GPIO functions. Write a GPIO handler that does the de-multiplexing. No need to alter the SPI drivers.
Related
I am using STM32H7 family of microcontroller as SPI Master Transmit device which needs to talk to 4 SPI slave devices receive only which are also all STM32H7 MCU's. Both master and slave are configured for software slave management.
The confusion is how slave will identify when master wants to talk to it or transmit data to it without using hardware NSS pin?
How slave device will start receiving in this scenario and stop receiving when all data transmitted?
If you use software slave select (NSS), you must select and deselect the SPI interface by software.
Typically, you would setup an external interrupt on the pin used as NSS/CS and select/deselect the SPI interface when the interrupt is triggered.
On an STM32F1 chip, the SPI interface is selected/deselected by setting/clearing the SSI bit in the SPI_CR1 register. I assume it's very similar on a STM32H7 chip.
Update
I've just checked the STM32H7 and it's exactly the same.
It is very simple. Every slave has one pin called CS. You need to select this device by setting this pin just by using the GPIO. Then you can transmit or receive data. Remember that master has to supply clock even if it wants only to receive data.
It seems that the code shown below can manage the problem.
__HAL_SPI_ENABLE(&hspi1);
__HAL_SPI_DISABLE(&hspi1);
I am trying to connect an analogue to digital converter to the raspberry pi. As far as I am able to understand, the RPi doesn't support Bi-directional SPI mode. The adc I am using says it is SPI compatible but only has the inputs SCLK, CNV and outputs CLKOUT+ and CLKOUT- and SD0+ and SD0-. This leads me to understand that it will only work with bi-directional SPI as there is only the serial data out. I am thinking of using a PWM for CNV (which I think CE), GPIO clock for SCLK and then an interrupt on the falling edge of the GPIO clock to just digitally read each bit from the adc. I don't understand SPI in detail but from what I've read quite often it requires sending data in order to receive it. Do you know if the setup I mentioned (without using SPI) will work? Or am I missing something about SPI and the adc will work with that while not in bi-directional mode?
We are using the Raspberry Pi 3 b
adc - http://cds.linear.com/docs/en/datasheet/232316fa.pdf
Thanks for any help you can provide.
Read the data sheet carefully, in particular pages 8 and 9. I suggest that you tie CMOS/LVDS pin to ground to enable CMOS mode. Then use only the "+"-pins. Use the SCK for SPI clock, SD01+ for SPI data input to the Rpi. Connect a GPIO pin to CNV.
Also observe that the RPi runs at 3.3V, and the ADC's max rating is also 3v3, that is running the IC right to the edge.
I am attempting to make a retro computer using a z80 and ideally would like to give it the ability to boot from an SD card. I am 100% set on using a z80 and do not want to use a microcontroller with an internal SPI hardware interface. I want to understand both the hardware and software aspects of a computer, so arduinos and microcontrollers are off the table as the hardware side is completed before you even purchase it. Anyways, my main question is would it be possible to combine a shift register, some decoding logic, and software to read from an SD card via SPI mode? I have searched the internet for hours and read several articles and cant seem to find a tutorial. I understand SPI protocol, however, there is a lack of information regarding the hardware side because microcontrollers tend to have all the hardware built in. I planned on connecting the SOMI of the SD card to the serial input pin of a shift register, the SIMO of the SD card to the serial out pin of the shift register, and then connecting a few data pins to some flip flops with some decoding logic inbetween, so that if I output to a specific port, it will toggle the flip flops. The flip flops would serve as the clock and chip enable lines to the SD card. I would also connect a pin of the z80 to the latch pin of the shift register (again with decoding logic inbetween) so that if I output to a specific port it will latch the data of the shift register. Im unconcerned with speed/efficiency, as long as I can accurately read data from the SD card. Also, would I connect the shift register clock input to the same clock as I connect the SD card to? Any advice on how to implement this would be appreciated, thanks!
You really could just bit bang SPI on regular IO's. All you need is an edge interrupt for the clock signal and a level interrupt for the chip select. Everything else can be done in software. To send, hold the chip select low, and clock out bits on MOSI at the desired rate. To receive, handle chip select going low by sampling bits off MISO on the desired edge on the clock line. Stick everything in a buffer and process the buffer when the chip select line goes back high.
I am using a USB device from FTDI called FT4232H and I want to write on the EEPROM to make sure that some pins are set to inputs at start. I am using the D2XX drivers (pdf here). Here I found at page 106 that there is a struct called FT_EEPROM_4232H. Could this be something to use to make sure the pins are set to inputs at the beginning or is this totaly wrong? There are four UCHAR variables called A-, B-, C- and DDriverType. Does anyone know what these should be used for?
I realise this question is 3 months old now but I believe pins on the FTx232H series of chips only get set as GPIO once the MPSSE command SetOutput is issued.
The EEPROM configuration is used to define things like drive strength, slew rate and whether the pin is a schmitt input and what each of the 4 ports are set up to be (async FIFO akin to FT245 series, serial port (FT232), etc).
If anyone else can disprove this, I would be interested to know also!
I just plugged my FT232H board in my PC and ran FTDI FT_Prog, it does not appears you can control the GPIO mode input/output at start time. There is nothing in the FTDI FT_Prog UI that allow to set a mode for GPIO pins and set them as input.
I did set programmatically my FT232H board as an SPI device with 8 GPIOS
but this was done after the chip was started.
A video experimenting with the FT232H
I also once asked FTDI support a similar question for the FT232RL which is as default a UART and I asked if there was a way to configure the chip to start in Synchronous bit banging mode and set the GPIOs as OUTPUT. The answer was no.
The FT232RL will always start as a UART and then by software I can activate Synchronous bit banging mode, and set the mode of my GPIO.
I suppose it is the same for the FT232H, FT2232H and FT4232H.
The Arm processor on one of our boards has an spi port with two chip select lines.
It is mentioned in the processor's datasheet that it can control upto two spi devices.
Is it possible to use a GPIO as a slave select for an additional spi device?
How to modify the existing libraries/device drivers to support this change?
So far i've found a file in the kernel's source which contains the addresses of SPI port pins. Can anyone plz tell in which direction should i proceed?
If you have enough pins, you can bitbang the whole SPI protocol and use as many CS as you need.
You don't mention what processor it is. You have three possibilities.
If the processor has an i/o mux capabilities, turn off the SPI chip select functionality. The SPI controller will think it has asserted the line, but it won't go external.
Don't connect one SPI chip select. Use a pull-up/down for ESD protection.
Multiplex the chip select as per Joachim Isaksson
In first two cases, connect GPIOs to the additional device's chip select. Toggle the GPIO manually before running spi_write(), etc. This will allow the SPI controller to transfer at higher rates than are possible with bit banging and is a better system design. Ie, lower power consumption, lower CPU use, faster data rates, etc. If the peripheral is just for setup/boot, then the bit banging makes sense for simplicity. However, if your main operation depends on the SPI bus, you could consider this solution.
If only one peripheral needs the SPI for setup AND you have the i/o mux, you can disable the chip select functionality during setup, using a GPIO to select the setup peripheral and then re-enable the spi chip select during standard system operation for the other peripheral.
Using a GPIO doesn't require user space intervention. Drivers can provide call backs to set the GPIO when in use, so SPI commands can be buffered/queued and these solutions still work. For instance, the IMX SPI driver supports GPIO toggle by passing a negative chip select number to denote a GPIO id.
Note: Some SPI devices may require the chip select to toggle between words; what ever a word is for the device. Some controller may leave the chip select asserted when transferring multiple words. You need to get this right if you use a GPIO to manually select devices. I am sure some standard defines this, but definitely some device don't follow the standard.
Addendum: Most drivers support a GPIO chip select; via a negative chip select value. They will call Linux GPIO functions. Write a GPIO handler that does the de-multiplexing. No need to alter the SPI drivers.