Image by Brian Penny

I am using a Promira Serial Platform with  SPI Active - Level 1 Application   and Promira Software API I2C/SPI Active connected to the lab computer via Ethernet connection. I have questions about the queue mechanism - I see it takes about 500uS for the Promira platform to clear a queue, which was confirmed with a logic analyzer.

The queue is very simple – it sends and receives 16-byte data through an SPI interface:

It also takes 500us if I create a GPIO queue, where I wait for a change of the GPIO state.

My question:

• Is this the normal duration?
• Can this process be accelerated?

Thanks for your question! The duration of clearing a queue is based on how often the queue is cleared. We’ll describe how the queue mechanism works, and provide a script that you can modify for your system.

How the Queue Mechanism Works

A typical SPI transfer example with Promira API queue mechanism should follow the below flow:

1. Call ps_queue_create to create a queue, and specify the queue type. For example: PS_MODULE_ID_SPI_ACTIVE.
2. Call ps_queue_clear to clear the queue.
3. Call ps_queue_spi_oe to add a command to the queue to enable SPI outputs.
4. Call ps_queue_spi_ss to add a command to the queue to assert SS line.
5. Call ps_queue_spi_write or ps_queue_spi_write_word or ps_queue_spi_read to add an SPI command that shifts data on the bus.
6. Call ps_queue_spi_ss to add a command to the queue to deassert the SS line.
7. Call ps_queue_spi_oe to add a command to the queue to disable master output.
8. Call ps_collect_resp to collect the first/next response from the previously submitted queue.

   1. If the return value is PS_SPI_CMD_READ, call ps_collect_spi_read to collect the response of with the SPI data.
   2. Otherwise, no additional functions need to be called.

9. Repeat step 8 until you receive from the function ps_collect_resp the return value PS_APP_NO_MORE_CMDS_TO_COLLECT.
10. Call ps_queue_destroy to destroy the queue, or go back to step 5 to submit the queue again.

At step 9, ps_collect_resp is called repeatedly called until no more data is available to read from the queue buffer. On collecting and storing it in a local buffer, the queue buffer is consistently emptied and re-filled by incoming data. To not lose data, this is achieved only when the SPI slave data is collected as soon as possible. That way, the 2MB buffer is not filled up, which leads to overflow – loss of data.

Accelerate Mechanism with Multiple Queues

As the above outline illustrated, to accelerate the process, multiple queues must be created and rapidly replenished. As soon as a queue finishes, handle it promptly and resubmit, ensuring there is always a pending queue at the Promira platform. Due to the significant latency between the computer and the Promira platform, a set of number of outstanding queues can be maintained. These will be maintained autonomously, helping to compensate for the latency.

We have a functional script that you can refer to and use: spi_nogap2.txt.  This script can stream at 20 MHz without gaps. The error checking is not ideal in this script – this is an example that you can modify to fit your system requirements. To execute the code:

• Rename the script from spi_nogap2.txt to spi_nogap2.
• Update the IP address for your Promira Serial Platform.

We hope this answers your questions. Additional resources that you may find helpful include the following:

• Promira Serial Platform System User Manual
• Promira Serial Platform I2C/SPI Active User Manual
• Promira Firmware Update

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application