08-31-2009 11:14 AM
Hello Freitas,
If you are using the LM3s8962 target it is actually possible to specify a GPIO line to act as the chip select through the SPI VIs. If you are using another target, you can use the GPIO EIO to toggle the pins seperately.
If you are on the LM3s8962:
The chip select input on the ARM SPI Create Configuration Reference.vi can take the following input to use GPIO as a chip select (rather than SFss pin)..
chip select, if needed. If no GPIO is specified, then the normal Fss
signal is used.
The interface parameter is arranged by bytes as follows:
[07:00] interface number (only 0 is valid now)
[11:08] GPIO pin number (0-7)
[15:12] GPIO port number (1-7, where 1=A, etc)
08-31-2009 01:28 PM
Here is the list with the Slave Select and the corresponding Processor Flags Pins for Blackfin BF537 using BF AD7476A Control vi:
SS1 - PF10
SS2 - PJ11
SS3 - PJ10
SS4 - PF6
SS5 - PF5
SS6 - PF4
SS7 - PJ5
Now the problem is, this vi only accepts Slave Select from 1 to 7, how do I change it to accept more? Do I need to change the control vi? how? if I click on it it has only a library .dll..
Thanks
09-01-2009 11:49 AM
Hi freitas,
I've investigated your position a bit, and this is what I've discovered:
1) Option 1 - change the VI such that you can enter numbers greater than 7......
Yes, the BF AD7476A Control VI
(C:\Program Files\National Instruments\LabVIEW 2009\vi.lib\Embedded\vdk\device\AD7476A\BF AD7476A Control.vi)
calls into the DeviceStub.dll
(C:\Program Files\National Instruments\LabVIEW 2009\vi.lib\Embedded\vdk\DeviceStub\Debug\DeviceStub.dll).
That DLL doesn't actually contain the C source code for that VI. The C source code is located here.
(C:\Program Files\National Instruments\LabVIEW 2009\Targets\ADI\Embedded\vdk\common\lv_device\ad7476a.c)
You are more than welcome to change the above C code; however, I don't recommend it, because the parameter of ADI_AD7476A_CMD_DECLARE_SLAVE_SELECT is defined by Analog Devices in this header file as only expecting values 1-7.
(C:\Program Files\Analog Devices\VisualDSP 5.0\Blackfin\include\drivers\adc\adi_ad7476a.h)
It's possible that you could break other Analog Devices code that rely upon this value (and only expect values between 1 and 7). If you want to do this, I would recommend contacting Analog Devices in order to inquire further into the matter.
2) Option 2 (a work around) - use LabVIEW Elemental I/O on your Block Diagram to implement your other chip select lines.
3) Option 3 (a work around) - use LabVIEW Elemental I/O in the Block Diagram of the BF AD7476A Control VI. You can enter whatever number you like into the control VI, and then you can determine the range. If the range is from 1-7, pass that value into the DLL. If the range is above 7, use Elemental I/O on that Block Diagram to implement your own chip select. The only item to be taken into account is that some number always has to be passed into the DLL, so you would need to not use one of the 1-7 chip select lines. (Anytime a number greater than 7 comes into the control VI, run your own chip select code with Elemental I/O, and pass the unused number into the DLL such that there won't be an SPI conflict.)
4) (There are potentially other options as well, but the ones above are the only ones I could immediately think of.)
You've definitely benefited from my curiousity into this matter. I hope this information helps.
Kevin S.
Applications Engineer
National Instruments
09-01-2009 12:30 PM
Hi Kevin_S!
Many, many thanks!
I'm going to try those options, but I think I can get a way of using just 6 ADC's.. I'm working on it!
Now I have a basic problem to solve, change from chained buffers to circular buffers (SPI), since I want to process the acquired data (via SPI) processed in real time..
Once more, thanks for all your effort!
Best regards,
António Veríssimo de Freitas
04-09-2011 06:36 PM
"I can post here couple workarounds here if needed."
Could someone please elaborate a lttle bit more on the issues on might get using multiple spi devices (with GPIO as CS), SD-card File I/O and usage of the OLED on the LM3S8962 board ?
Workarounds - if still needed would be highly welcome ...
04-12-2011 10:18 AM
Hi tbet,
The issue you are describing is documented in KnowledgeBase 56P8HLXY: LabVIEW for ARM and Using the OLED and MicroSD Card Reader on the Luminary Board and should be resolved in LabVIEW for ARM 2010. The KnowledgeBase appears to be offline at the moment...here is the text:
Problem
I'm using the LabVIEW Embedded Module for ARM Microcontrollers (LabVIEW for ARM) with the Luminary Micro LM3S8962 evaluation board. I can use the OLED display and write to file independent of each other. However when I try to do both at the same time, nothing is written to file, and static is displayed on the OLED. Why?
Solution
The issue arises as both the OLED and microSD card reader are connected
to the same communication bus (the same SPI lines). For file
read/writes, there is a way to automatically reserve and release the
communication bus, but for display writes, there is only a way to
automatically reserve the bus. After performing a display write, the
bus must be manually released.
A work around is outlined in the
VI snippet attached below. Note that there is no current way to output
to the display and interact with files in parallel. The C code function
of spi_init() is used to manually release the SPI bus after a display
write.
I am unable to get the VI snippet at the moment, but I will post back here as soon as I do.