yogesh kulkarni

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

8 years, 5 months ago.

Compiler error -DEVICE_SPI_ASYNCH

I am trying to use the ASYNCH mode by setting the DEVICE_SPI_ASYNCH on FRDM K64 board.

since i want to use it for SPI DMA transfer, I plan to set DMA using set_dma_usage(DMAUsage usage) and then use transfer function to send and receive data.

When I set DEVICE_SPI_ASYNCH =1 and compile, these are the errors I get. (I have an updated mbed library).

Why i get compiler errors ? Do i need to include some extra .h files ?

compilation error


.\build\frdm_serial.axf: Error: L6218E: Undefined symbol mbed::SPI::queue_transfer(const void*, int, void*, int, unsigned char, const mbed::FunctionPointerArg1<void, int>&, int) (referred from main.o).
.\build\frdm_serial.axf: Error: L6218E: Undefined symbol mbed::SPI::start_transfer(const void*, int, void*, int, unsigned char, const mbed::FunctionPointerArg1<void, int>&, int) (referred from main.o).
.\build\frdm_serial.axf: Error: L6218E: Undefined symbol spi_active (referred from main.o).

- YK

Where do do you set that device_spi_asynch macro?

posted by Martin Kojtal 30 Oct 2015

In keil it can be set in the defines section of project properties...like mbed=1

posted by yogesh kulkarni 30 Oct 2015

1 Answer

Erik -
8 years, 5 months ago.

The K64F code base does not support the SPI (or I2C/UART) async functions. Neither does the LPC1768. Or the KL25. Or the NRF51822, or the STM F401. Or the LPC11u24. I can continue very long with this list, since only the Gecko boards support this, and afaik not a single other board supports it. It seems the main goal of those functions is to confuse users and give false expectations.

Short background: Silicon Labs (makers of Gecko boards) wanted async functions. So either they and/or mbed staff decided to make API. They did not for a moment consider discussing those functions with the community. They did (as far as I am aware) not discuss this with other companies. They did not bother to implement it for any other board. And after that they seriously expected the community to implement it for them :D.

Since no other boards support it, pretty much no community library bothers to use it, so there is really no need for other boards to support it.

And don't worry, I am not as bitter as you might expect from this post, it is just a bit stupid they screwed up their opportunity to properly implement this.

OK thanks. So what must be done to use spi with DMA. Any working example of spi DMA for k64 boards where I can transfer and receive data over spi using DMA functionality? - yk

posted by yogesh kulkarni 30 Oct 2015

There is the SimpleDMA lib which works for KL25 and KL40, and I believe the K64 DMA is similar, so that you can use as starting point for DMA.

However the next problem you have, is the K64 SPI. It is horrible. Especially in combination with DMA. For the KL series I do have code which runs SPI via DMA, and that works fine. The problem is: For every single MCU you can place for example 0xAA, 0xEE, 0x00, 0xFF in your memory, and if you set up DMA correctly it will transmit those 4 bytes. For the K64F you will need to do something like:

spi_config_byte1, spi_config_byte2, spi_config_byte3, 0xAA, spi_config_byte1, spi_config_byte2, spi_config_byte3, 0xEE, spi_config_byte1, spi_config_byte2, spi_config_byte3, 0x00, spi_config_byte1, spi_config_byte2, spi_config_byte3, 0xFF

to do the same thing. So you first need to place everything properly in your memory, and you can't just transmit an array via DMA.

posted by Erik - 30 Oct 2015

Thanks Erik for the pointers. I am trying to follow the simpleDMA for KL46. What does it mean when you say for the example data 0xAA,0xEE,0x00 and 0XFF you need to send it as

spi_config_byte1, spi_config_byte2, spi_config_byte3, 0xAA, spi_config_byte1, spi_config_byte2, spi_config_byte3, 0xEE etc etc.

What exactly spi_config_byte1, spi_config_byte2, spi_config_byte3 here are ?

- Yk

posted by yogesh kulkarni 02 Nov 2015

Those are the SPI settings. In the end transferring SPI via DMA for the DSPI (which is on the K64F, K22F, K20D50M, etc) is just not very handy.

See also: https://community.freescale.com/thread/314019 (second post).

posted by Erik - 02 Nov 2015

FWIW do you think the K64 DMA implementation was meant to allow changing config mid-DMA or did someone just mess up at chip level and forget to set the DMA transfer "width".

Also is the Asynch thing likely to stay as Gecko-only forever? My first reaction was it was something the MBED platform badly needed as there seem to be several "unofficial" attempts to do roughly the same thing.

I'm sort of guessing that SL weren't going to spend any time porting their code to non-SL CPUs.

posted by Oliver Broad 04 Apr 2016

I read here that someone managed to make the K64 DMA work properly using I believe two DMA loops, still not really straight forward. It might indeed have been someone who thought changing settings mid-DMA transfer is something someone actually would want to do, so for 'flexibility' they implemented this without realizing the consequences.

If the Async is going to stay Gecko forever is hard to say. When it was released that was my prediction, and for now it is turning out to be correct, but you never know. I guess in the end some others will also implement it, but as long as that stays a minority it isn't really more useful than the unofficial attempts, since the result is in both cases that they will not be widely used in libraries.

But mbed staff has said they aren't going to implement it themselves for any other target, and personally I refuse to implement it on anything because I disagree with the API choices made, and especially that they never even considered discussing such a new API with the community. So if they don't want to talk to us, I am not going to implement it.

posted by Erik - 04 Apr 2016