Use LabVIEW Embedded Module for ARM Microcontrollers to read data from SPI interface

[frosturi]

So I am now using GPIO P2.1 as my SPI select line, using the EIO.  I couldn't get the P0 GPIO to work.  Using a scope I verified that the SPI clock, GPIO(used as my SSEL), MOSI, and MISO are all taking place.  However, my SPI device (LTC1856) is 16-bit device.  The SPI VIs are setup for 8-bit read/writes only.  How can I write a 16 bit SPI command to my device? 

I tried using 2 separate SPI Read/Write VIs, where I broke up my 16 bit command into 2 8-bit commands.  I also tried using 1 SPI Read/Write VI but broke up the 16-bit command into 2, where the first element element in the "write data" array correspondes to the 8 MSBs and the 2nd element corresponds to the 8 LSBs.

I have used the SPI device with LabVIEW emebedded on the Blackfin 537.  It works.  I goal is to send the command 0x9000 and recieve 0x4230.  

Thanks,

Jeff

[Kevin_S]

Hi Jeff,

I understand how you're trying to send 16 bits through the SPI port to your device.  I don't specifically have that device here in order to try, but I've attached an image as to how you could potentially do this.  I don't know how your device is needing to receive the 0x9000 command, so there are potentially 4 different permutations of how to code that (as you will see in the image).  If you have an oscilloscope, you can verify which orientation of the numbers gives the combination required by your device.

Also, you may need to take into account when you should be expecting the 0x4230 command in return.  Do you need to send the 0x9000 to your device and then receive the 0x4230 command in the same 16 clock cycles or in the following 16 clock cycles?  (In my attachment, I was assuming that you would receive 0x4230 in the same 16 clock cycles during which you're sending the 0x9000 command.)

Regards,

Kevin S.

Applications Engineer

National Instruments

[frosturi]

Hi Kevin,

The 0x9000 command needs to be sent as 1 16-bit command to correspond with 16 clock cycles.  Unfortuneately breaking up the command in any way makes this impossible, as the SPI Write Read VI can only send out 8-bits.  If the command is broken up, then 2 8-bit commands (and 2 separate 8 clock cycles) are sent.   I have used an oscilloscope to verify this.  The 0x4230 should be read back during the same 16 clock cycles as the 0x9000 command is sent.

[Kevin_S]

Hi frosturi,

Is your device expecting a clock cycle at a specific frequency?  If it's using the SPI port, it shouldn't matter that data is clocked over in different chunks unless all the data needs to make it within a certain time period.  There are no baud rates, stop bits, start bits, or parity bits involved with the SPI data transfer.  Just be sure you have the right state configured for the idle state.

Have you gotten any configuration to work at all?  I'd be curious to see a screen capture of the Blackfin waveform versus the ARM waveform.  As long as the valid data is available for either the rising or falling clock edge, it should work.

Kevin S.

Applications Engineer

National Instruments

Message Edited by Kevin_S on 06-08-2009 10:24 AM

[frosturi]

I have not gotten any configuration on using the ARM to work.  I can always send the SPI clock and MOSI, but the MISO signal appears to be the SPI clock and MOSI added together.

The attached documents contains oscilloscope screen shots.  The SPI ARM.pdf screen shot is on the ARM processor (NXP LPC2378), and the SPI BF537 screen shot is on the Blackfin537.  The same SPI command is being sent by both processors (0x9080).  The same SPI device (LTC1856) was used in both cases. 

Scope Channels             

CH1 = SPI clock            

CH2 = MISI                 

CH3 = MOSI                 

[Gmg]

hmm...  the output signals look exactly the same to me.  How does the SSEL signal look in relation to the SPI Clock?  Perhaps the SSEL is different on BF and ARM.

[David_NMRSA]

Jeff,

Looking at your SPI file from a previous post I notice some slight differences to mine, only because we had to change ours to suit. We are sending an 8-bit opcode, instead of your 16-bit, with the address info (etc) as a 1-D u8 array. This then ensures that all the information is clocked in when it is expected by the external flash on the SPI.

I'm adding the code we are using in the hope it gives you some ideas on how to implement what you are trying to achieve.

  switch (chipSelect) {
    #if SPI_INTERFACE_IN_USE(0)
    case 0:
      PCONP   |=  (1 << 8);                                     // enable power for SPI
      PINSEL0 &= ~0xC0000000;                            // clear pin settings
      PINSEL1 &= ~0x0000003C;                            // clear pin settings
      PINSEL0 |=  0xC0000000;                              // P0.15 (SCK) is SPI pin
      PINSEL1 |=  0x0000003C;                              // P0.16..18 (MISO, MOSI, SSEL) are SPI pins.

      S0SPCCR = (0x38);  //SPI_CLK / (clockRate * 1000UL);          // set clock rate - Run as fast as possible
  
      S0SPCR = 0;           // Clear the setup register
      S0SPCR = (( clockPhase    & 1) << 3)              // set clock phase
                                |  (clockPolarity << 4)            // set clock polarity
                                | (1 << 5)                             // set master mode
                                //| (1 << 6)                          // LSB trans. first ****** Require MSB first for DataFlash memory
                                | (1 << 11);                         // set 8 bit data
      break;

[frosturi]

I got my SPI device working.  My issue was in hardware setup.  In the end the only software change that I had to make was setting up an EIO node as a GPIO and  toggling that GPIO for the SPI select line.  Thanks for everyone's responses

[matmix1]

I'd like to renew this topic. It helped me to configure LPC2378 so as there is now access to GPIO ports (SSEL for SPI), however there are no functions for LCD display, push buttons and LEDs. I need at least those functions responssible for display on the mcb2300 board. How to cope with this problem ? 

[matmix1]

I've just noticed, that my SSEL as GPIO doesn't work properly. I selected P2.0 as SSEL in my communication between LPC2378 and MCP3204. Should I change some part of code in ARM_SPI.c ?