More than two SPI devices on an Arm board that sup

2019-02-15 08:30发布

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?

2条回答
我只想做你的唯一
2楼-- · 2019-02-15 08:56

If you have enough pins, you can bitbang the whole SPI protocol and use as many CS as you need.

查看更多
手持菜刀,她持情操
3楼-- · 2019-02-15 08:58

You don't mention what processor it is. You have three possibilities.

  1. 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.
  2. Don't connect one SPI chip select. Use a pull-up/down for ESD protection.
  3. 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.

查看更多
登录 后发表回答