This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SPI interface

Note: This was originally posted on 10th October 2008 at http://forums.arm.com

Hi all,
   I am using an 180 MHz, 200 MIPS ARM920T.  My question is
How can one have an SPI interface to a device(any)?? What are the steps involved??  :wacko: The O.S used is linux. One thing i noticed is there is no SPI in /dev !!!!! It would be really be helpful if any one can suggest or give any link to solve this.

Thanks,
jfor.
  • Note: This was originally posted on 10th October 2008 at http://forums.arm.com

    Hardware
    Firstly, check the manual (or user guide) for the chip you're using. It's very likely that it does have an SPI peripheral on-chip, but it might not. In addition, it's common for peripherals to share I/O pins as most applications only use a small subset of the available peripherals. Thus, even if it has SPI, you may not be able to use it if you're using other peripherals that share the same pins.

    If you don't have a hardware SPI peripheral, you can probably still interface with SPI because you can control the I/O pins manually from software; this is known as "bit banging". However, the data rate will probably be lower and you'll get more CPU overhead, especially if you want your device to act as a slave. In addition, it'll take longer to implement and debug the SPI interface if you have to do it all manually.

    Linux
    It is likely that you do have SPI on your chip, but that Linux simply doesn't have a driver for it. In this case, you'll probably have to write your own driver. If you're lucky, there may be one available on the net, but I couldn't tell you where to look.

    Also note that Linux may not regard SPI as a device in its own right. It may think of it more as a bus. However, I've never used SPI from Linux so I can't be sure about this. Can anyone be sure of anything in Linux? :-)



    Well at least i am not sure of some of things in Linux. :) Thanks Jacob for the prompt reply.
       About the pin sharing though it has pins for SPI it is also shared as I/O. But i do not intend to use it for any other purpose other than SPI.
                    There seems to be not much of sample driver code for SPI..... :wacko:
    Is SPI char or block device??
  • Note: This was originally posted on 10th October 2008 at http://forums.arm.com

    You should be fine then, unless some other part of Linux is using it as I/O. That is unlikely. Your driver will need to configure the pins to connect them to the SPI peripheral internally. You'll need to look at the chip's user manual for details on how to do that.


    SPI is neither a char or a block device because those are abstract Linux terms used to classify a device. However, your driver should probably present SPI as a char device.

    What exactly are you trying to achieve with SPI? It sends and receives synchronously, so a slave cannot simply send data, and similar a master cannot simply receive data. It doesn't work like a normal UART-like device.


    I plan to develop an application which can be used to interface to any SPI interfaced device.
     
    Yep , its different from UART. In linux applications can work only as master device. Can you suggest any steps/methods to be followed in developing a driver for SPI device??
  • Note: This was originally posted on 10th October 2008 at http://forums.arm.com

    Hardware
    Firstly, check the manual (or user guide) for the chip you're using. It's very likely that it does have an SPI peripheral on-chip, but it might not. In addition, it's common for peripherals to share I/O pins as most applications only use a small subset of the available peripherals. Thus, even if it has SPI, you may not be able to use it if you're using other peripherals that share the same pins.

    If you don't have a hardware SPI peripheral, you can probably still interface with SPI because you can control the I/O pins manually from software; this is known as "bit banging". However, the data rate will probably be lower and you'll get more CPU overhead, especially if you want your device to act as a slave. In addition, it'll take longer to implement and debug the SPI interface if you have to do it all manually.

    Linux
    It is likely that you do have SPI on your chip, but that Linux simply doesn't have a driver for it. In this case, you'll probably have to write your own driver. If you're lucky, there may be one available on the net, but I couldn't tell you where to look.

    Also note that Linux may not regard SPI as a device in its own right. It may think of it more as a bus. However, I've never used SPI from Linux so I can't be sure about this. Can anyone be sure of anything in Linux? :-)
  • Note: This was originally posted on 10th October 2008 at http://forums.arm.com

    About the pin sharing though it has pins for SPI it is also shared as I/O. But i do not intend to use it for any other purpose other than SPI.

    You should be fine then, unless some other part of Linux is using it as I/O. That is unlikely. Your driver will need to configure the pins to connect them to the SPI peripheral internally. You'll need to look at the chip's user manual for details on how to do that.

    There seems to be not much of sample driver code for SPI..... :wacko:
    Is SPI char or block device??

    SPI is neither a char or a block device because those are abstract Linux terms used to classify a device. However, your driver should probably present SPI as a char device.

    What exactly are you trying to achieve with SPI? It sends and receives synchronously, so a slave cannot simply send data, and similar a master cannot simply receive data. It doesn't work like a normal UART-like device.
  • Note: This was originally posted on 10th October 2008 at http://forums.arm.com

    I'd suggest looking at a Linux driver for a similar device, and using that as a tutorial.

    A UART probably isn't a bad example to pick, as it has send and recieve channels - the only difference is the synchronous bit.

    Cheers,

    I