Jump to content
  • 0

Protocol SPI pin assignment through a script


Jonboy

Question

I am fairly new user of Waveforms 2015 and I have both an Analog Discovery 2 and a Digital Discovery that I am trying to use for some for some tests with custom scripts.  I am having difficulty finding the documentation or some example code that instructs me how to assign the pins I want to use for the Select, Clock, DQ0 (write), and DQ1 (read) functions.  I have two different devices I need to communicate with through SPI but there is only one "select" line. 

I have two transceiver/MCU nodes connected together in a system and I need to communicate with the SPI port of one node to have it send a data packet to the second node, and then I need to switch my SPI bus pins to the second board and read verify it received the data I just sent from the first node.

I am able to script up a sequence of Read/Write transactions using the pin assignments set in the Waveforms GUI for my first device, but I now need to re-assign the pins in the script so that I can configure my second device without having to manually change the pin assignments in the Waveforms GUI. 

For example, if I use my Digital Discovery, the SPI pin assignments I would like to use are:

Node 1: Select = DIO 24, Clock = DIO 25, DQ0 = DIO 26, and DQ1 = DIO 27. 

Node 2: Select = DIO 28, Clock = DIO 29, DQ0 = DIO 30, and DQ1 = DIO 31. 

Could I get some example code to show how to assign the DIO pins for the various SPI signals Select, Clock, DQ0, DQ1 in both the Protocol/SPI/Custom script and the general Script tool in Waveforms 2015?  I'm sorry if this is a newbie question or documented somewhere already, but this has been elusive to me.

 

Thanks!

Link to comment
Share on other sites

3 answers to this question

Recommended Posts

Hi @Jonboy

In WF v.3.6.8 changing of interface settings is only allowed from Script tool and it is blocked in other places like: Protocol Custom, Logger...
The custom scripts are running in separate thread and this could cause problems.

Please try implementing the script in the Script tool. From here you can access the SPI Protocol with Protocol.SPI. and you can also access other instruments if you need.

i1.png.3df7226f5efbed53bb97e8a39cf25098.png

 

Link to comment
Share on other sites

Hi Attila,

Thank you for the information, it answered my question and I actually prefer to use the Script Tool instead of the custom scripts feature from within the protocol tool.  I had thought I tried the Protocol.SPI.value command and I am not sure why I didn't figure this out on my own with my Analog Discovery 2 module.  What I think was somewhat confusing me was that I had switched over to my Digital Discovery module because it has a higher sample rate and allowed me to achieve faster SPI clock data rates.  In your example, the Protocol.Select.value = 10; corresponds to DIO 10 pin which makes sense and the "10" is a direct correlation.  However, on the Digital Discovery pin indexes don't directly correlate and I had to use different numbers in the assignment to select the various SPI pins and this was confusing to me.  Have I overlooked the documentation that identifies the pin indexing on the Analog and Digital discovery modules?

For the Digital Discovery I found the following:

Protocol.SPI.Select.value = 1;   //Assigns pin DIO 24

Protocol SPI.Clock.value = 2;   //Assigns pin DIO 25

Protocol.SPI.DQ0.value = 3;   //Assigns pin DIO 26

Protocol.SPI.DQ1.value = 4;   //Assigns pin DIO 27

To switch to a different set of wires for my second SPI port:

Protocol.SPI.Select.value = 5;   //Assigns pin DIO 28

Protocol.SPI.Clock.value = 6;   //Assigns pin DIO 29

Protocol.SPI.DQ0.value = 7;   //Assigns pin DIO 30

Protocol.SPI.DQ1.value = 8;   //Assigns pin DIO 31

 

I do now have an additional question on the Select line timing that I didn't fully comprehend until today.  I noticed that there is a significant amount of time that elapses between the Select line toggling and the start of the Clock and data, as well as even more time elapsing following the last data bit and the Select line toggling again.  I now understand that the select signal is activated from software, therefore it does not have exact timing with the bit serialization. My total SPI data transaction takes about 500uS, but there is about ~3.5mS that elapses between the Select line toggling, and then another ~5.5mS of time following the data before the Select line toggles again to end the transaction.  This gives me about one complete transaction every 9-10mS.  This is a lot of overhead when I'm trying to send data across a bus through my transceivers that results in a lot of idle time on my system bus since a packet of data is only transmitted every time it receives the transmit command I'm sending over SPI.  Is there any work around I could do to decrease this time between Select line toggling and the Clock/Data?  It would be ideal if the tool would automatically transition the Select line automatically when a Read/Write command was executed. But since it doesn't work this way, would creating a custom script to do SPI allow faster overall speeds, or would the overhead be even slower?

Thanks!

 

 

Link to comment
Share on other sites

Hi @Jonboy 

On Digital Discovery the DIO line name numbering starts from DIO24 and the DIN lines can only be used by Logic Analyzer.
When switching a project from Analog Discovery to Digital Discovery the DIO lines will remain used for the project to be usable, DIO 0->24, 1->25,...

In Protocol SPI the select and read/write operations are controlled separately by the software. For read/write a custom pattern is generated on clock and data lines. This depending on custom pattern bits available in the device (1k for AD default configuration, 16k in 4th, 32k for DD) and the number of bits to transfer might be performed in one or multiple successive operations.

The only way to speed this up is by creating a custom channel in Patters interface which controls the select, clock and data lines at the same time. In this case you will have to use the Logic Analyzer events to decode the received data similar to the following I2C:

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...