Reply
Posts: 18
Registered: ‎11-03-2015
Accepted Solution

Thought about performance of EZRadioPRO driver

Hello,

 

I'm writing program for EZR32 and I noticed that information exchange between MCU and EZRadioPRO isn't fast (ezradiodrv v.4.1.0). For example MCU at 28MHz spends about 100us to transmit 2 bytes by calling ezradio_hal_SpiWriteData. Driver sets desired SPI speed to 8MHz, real value after calculating CLKDIV is 7MHz, so time to transmit 2 bytes should be 2 * 8 / (7*10^6) = 2.3 us. What's happening in the remaining 97.7us?

 

After diving into SPI driver I found out the reason of this behavior. The culprit is DMA that SPI uses to transmit/receive bytes. Ok, DMA works fine, but MCU spends a lot of time to setup it before each transaction with radio. From my point of view DMA isn't necessary in that case.

 

So, I have rewritten SPIDRV_MReceiveB and SPIDRV_MTransmitB.

 

The main idea to send a byte:

// wait for tx buffer to empty

while (!(handle->initData.port->STATUS & USART_STATUS_TXBL))
{
}
handle->initData.port->TXDATA = tx_byte;

 

// wait for valid RX data 

while (!(handle->initData.port->STATUS & USART_STATUS_RXDATAV))
{
}
(void)handle->initData.port->RXDATA; // clear RX buffer

 

The main idea to receive a byte:

// wait for tx buffer to empty

while (!(handle->initData.port->STATUS & USART_STATUS_TXBL))
{
}

// send dummy byte

handle->initData.port->TXDATA = 0xFF;

 

// wait for valid RX data

while (!(handle->initData.port->STATUS & USART_STATUS_RXDATAV))
{
}

// clear RX buffer

rx_byte = handle->initData.port->RXDATA;

 

With these changes function ezradioInit that sends RADIO_CONFIGURATION_DATA_ARRAY from radio-config-wds-gen.h takes 54ms instead of 140ms. Also time to reenter EZRadioPRO in RX mode after receiving a packet is 440us instead of 2,000us.

 

Maybe for someone this information would be useful. I also attached spidrv.c with changes to this post.

 

 

Posts: 583
Registered: ‎09-18-2015

Re: Thought about performance of EZRadioPRO driver

[ Edited ]

Hi Dmitriy,

 

Thanks for your suggested improvements to the SPI driver. I have passed them along to the EFM32 SDK development team so they can take a look at them. The SiLabs radio folks who have assisted you agree with you about the source of the slowness in the SPI driver, so it seems the SDK developers ought to have a look and see if your improvements would be useful for all customers.

 

Thanks for commenting on this and proposing the improvement.

 

Posts: 18
Registered: ‎11-03-2015

Re: Thought about performance of EZRadioPRO driver

Hi John,

 

Thanks for answer and just a quick note that in the suggested SPIDRV_MTransmitB instead of: 

while (count-- && handle->transferStatus == ECODE_EMDRV_SPIDRV_OK)

 

should be:

while (count--)

 

As checking handle->transferStatus not necessary.

 

Dmitriy

Posts: 60
Registered: ‎03-13-2013

Re: Thought about performance of EZRadioPRO driver

Hi,

I noticed the DMA driver was a bit bloated too. However I have modified their driver to allow it to set up the DMA descriptors only on the first call (per dma channel) , and hence reduce some of the unnecessary overhead.

However some calls still pass the src inc field as both true and false , those cases need to be changed in the spi driver to assign a different DMA channels for spi transfers with and without source incrementing.

I have got it to work, but so far have not tested the performance gain from this mod. 

Thanks.

Posts: 60
Registered: ‎03-13-2013

Re: Thought about performance of EZRadioPRO driver

Update on testing:

I changed the spidrv.c file to the non dma one uploaded here.

I tested it on our radio setup and tested actual data thoughput.

I tested it against my modified version of the spi driver which only sets up dma descripor once instead of each  time a dma is started. 

The performance of dma (with only intial decriptor setup) was about 200Kbits/s

The performance of non dma version (uploaded in this thread) was about 140 Kbits/s.

 

The DMA version is still out performing the non DMA version in real throughput tests.

I didn't check actual times of transmit, but the overall usage of dma appears to be better.

 

 

Posts: 18
Registered: ‎11-03-2015

Re: Thought about performance of EZRadioPRO driver

Hi kentmartin99_gm,

 

Could you attach your spidrv.c for those who would use a better dma version?

Highlighted
Posts: 60
Registered: ‎03-13-2013

Re: Thought about performance of EZRadioPRO driver

See attached,

Note changes required to both files. An extra dma channel has been added to allow for two cases, one where the src or dst doesn't move and one where it does. Can't remember exactly now. Note this dma driver might not work in all cases and I had to modify the spdriver in this case to add another dma channel, so if use this dma driver elsewhere you need to consider how it is being used and whether it will work for you. There is no implied warranty and the user should determine for themselves if it is suitable for use in their application. Also I believe I reversed the order DMA channels were allocated , this was due to an issue I had with serial dma and spi dma causing a dma fault. Reversing the priorities fixed it, but depends on which dma channel assignment you call first. Again use at your own risk.