Community news, upcoming events and general discussions
Threads: 36 Posts: 88
Get technical support from the community
Threads: 1409 Posts: 7545
Threads: 18 Posts: 64
Tell us how to make XDK better!
Threads: 36 Posts: 119
Share and discuss community member projects
Threads: 78 Posts: 343
I think I have a pretty advanced topic: I want to use A/D-C channel 6 in order to sample a analog signal with max. frequency of 20 kHz. Thus my sampling rate should be rather high (Nyquist: > 40 kHz) and I want to offload the uC as much as possible (I have to do other calculations there).
All in all, I think I have to use diret memory acces (DMA) and maybe the peripheral reflex system (PRS) of the uC. The question is how?
Looking at SiliconLabs' application notes AN0013 "DMA" (https://www.silabs.com/documents/public/application-notes/AN0013.pdf) and AN0021 "ADC" (https://www.silabs.com/documents/public/application-notes/AN0021.pdf) and the corresponding examples (subfolders of https://github.com/hrshygoodness/EFM32-Library/tree/master/v2/an), I come to the conclusion that I need the following system:
Timer (runs of HF clock, triggers every 1/40kHz) connects via PRS to
A/D-C (channel 6 - single or scan mode?).
Wenn conversion is finished
DMA (I require the ping pong mode as I need some buffer for further processing, while continuously reading sampling signals) is started - either by direct control of the A/D-C or via another PRS channel (suggestions?)
=> OK, how do I do that? Is there anything to be cautious about? Of course there is, because SiliconLabs examples do not - although I managed to compile them into a XDK project.
In order to be a bit more concrete:
Any help is appreciated.
BTW: I am on XDK Workbench 3.0.0
Hello Stephan! I had the same request during a project Iḿ developing here, the result, I provided the combo ADC+TIMER+PRS of microcontrooller to generate a CPU offloaded and precise sampled ADC triggerings, the only task left to do is to add DMA, I configured but needs some debugging. In other hand the PRS/Timer/ADC combo actually works like a charm and only using hardware it gathers samples at 48KHz and deposit into a ping-pong data structure. When it is full it triggers a Semaphore from ISR and swaps to next empty buffer. Se if my implementarion below helps you: https://github.com/uLipe/beeinformed_edge_fw/blob/master/source/edge_audio_acq.c Just a observation, the PRS driver is not added to source tree by default in workbench 2.x, you need to edit the file:
On line 76/77 just add this line: BCDS_EMLIB_SOURCE_FILES += $(BCDS_EMLIB_LIB_SOURCE_PATH)/emlib/src/em_prs.c With this mod you will able to use the PRS module which can trigger peripherals without CPU intervention. Please let me know if this info was useful to you, and of course count with me to help you ;) Felipe
I guess Felipe answered some of your questions already and you can use his application as starting point. As such, I will add some additional information.
Regarding your first question, as far as I know, is the ADC not used on any channel on the XDK in the latest XDK-Workbench 3.0.1, neither does it have a high-level API currently available.
The ping pong mode DMA feature is currently not implemented in the high-level DMA API. Regarding the usage of DMA in other components, I assume that only the SPI and UART transceiver for the Wi-Fi and Bluetooth chip use DMA channels. But if you do not use one of them, the channels should be free to use.
Regarding the implementations in the high-level API, as your application requires a fast runtime, I would prefer to use the emlib library for the performance gain in terms of speed. This also gives you the benefit of being independent of the availability of high-level implementations for PRS, Timer, ADC, and DMA. As such, only DMA and Timer are available as high-level API implementation.
Please let me know if that was helpful and do not hesitate to ask if you have further questions.
Kind regards, Franjo
I think I can answer your question in this thread here. But for the future, please open a new thread for a new question.
I mentioned that the MCU of the XDK gets the data of the BLE chip via UART, and UART uses DMA on the latest XDK-Workbench version 3.0.1. This is correct. As such, it is supported by the UART-BLE transport.
Unfortunately, the implementation files of the UART interface are capsuled with the other implementations of the BLE library in archive files.
thanks a lot for sharing your application. I really appreciate that. I have been trying to get the code running in my own vanilla application on XDK Workbench 3.0.0, but am still struggling: With the introduction of HAL, the em_* libraries are no longer easily accessible/linkable with the project (I have to find out).
Looking at your code, all the DMA stuff is commented. Am I right that you are not using DMA right now? Is there any reason for that?
Thanks, Franjo, for your comments.
Just for the file - just in case anybody is looking for this info: The WiFi module uses the DMA channels 2 (Rx) and 3 (Tx) for the SPI interface to the WiFi IC. The BLE/UART uses DMA channel 2 (Tx) and 3 (Rx) [reuse??]- as of the macro definitions in BSP_BoardSettings.h.
Furthermore, from the same file I conclude that the SPI to the SD card seems to use DMA channel 0 (Tx) and 1(Rx).
Status update: I wrote another implementation (using timer, PRS, ADC IRQ - basically the code from Felipe) of BSP_mic_AKU340.c/h/BCDS_BSP_Mic_AKU340.h (folders: SDK/xdk110/Platform/BSP/source and /SDK/xdk110/Platform/Essentials/include/bsp), which fits into the SDK architecture/HAL.
Thanks to Felipes thread (kudos!), I managed to include the PRS from EmLib - I had to add the line to efm32.mk make file: http://https://xdk.bosch-connectivity.com/community/-/message_boards/message/268087#_19_message_268099
However with WB3.0.0 the added line should look read:
BCDS_SOURCE_FILES += $(BCDS_EMLIB_LIB_PATH)/src/em_prs.c
BCDS_SOURCE_FILES += $(BCDS_EMLIB_LIB_PATH)/src/em_prs.c
BTW: adding the line
somewhere in between after "BCDS_SOURCE_FILES = \" now works (opposite to that mentioned in the threat, which referred to a previous verions of Workbench < 3.0.0)
I have not checked how this wirks, but I will keep you informed.
I am glad to help. Thank you for updating us on your progress with your application too. It is great to see that you could use Felipe's implementation as starting point.
Thus, I took a look at the interface BSP_BoardSettings.h, too. Thus I think you are right, the DMA channels 2 and 3 are used for Wi-Fi and BLE and the DMA channel 0 and 1 for SD-Card/SPI.
Regarding your findings of including the interface of the peripheral reflex system, I will add the information to our internal improvement list.