...but I stumbled on conflicting definitions of LDMA_IRQHandler from the required "dmadrv" module (I believe the serial plugin uses this).
Are you planning on integrating CSLIB with Thread sample projects anytime soon? Perhaps in the form of a plugin?
For starters, it's important to note that if you are using the serial plug-in for the Thread SDK, it makes use of UARTDRV, which, in turn, depends on DMADRV. Both of these drivers are components of emdrv, a driver abstraction layer that is part of the Gecko SDK platform. It is common for other emdrv components, like GPIOINT, RTCDRV, SLEEP, TEMPDRV, and USTIMER, to be used in a Thread application, including the samples that can be selected when creating a new project in Simplicity Studio.
Emdrv, in turn, sits on top of emlib, which is the hardware abstraction layer for the EFM32 and EFR32 device families and is also part of the Gecko SDK platform. So, while emlib simplifies the task of configuring the underlying MCU hardware on a given EFM32 or EFR32 device, emdrv allows portable code to be written that can run on any EFM32 or EFR32 device. These distinctions are important because they help explain why the CSLIB example code for the Pearl Gecko 12 Starter Kit cannot be incorporated into a Thread project.
In particular, the conflicting definitions of the LDMA_IRQHandler() occur because CSLIB has its own implementation of the function in the device_CSEN/hardware_routines.c file that is a required part of all projects that make use of CSLIB:
void LDMA_IRQHandler(void)
{
uint32_t pending;
/* Read and clear interrupt source */
pending = LDMA_IntGetEnabled();
if ((pending & 3) == 3) {
/* Setup LDMA for next transfer, common for single and scan mode */
LDMA->IFC = 0x03;
setupCSENdataDMA();
CSLIB_autoScanComplete = 1;
CSENtimerTick = 1;
}
}
This is not allowed in a project that makes use of UARTDRV because DMADRV (which is required by UARTDRV) must have its own implementation of LDMA_IRQHandler() in order to dispatch callback functions. Furthermore, CSLIB performs its own LDMA configuration using emlib functions:
As you might imagine, this programming of the LDMA is not possible because DMADRV must handle the allocation of all channels and manage all descriptors. This is especially important when you consider that DMADRV manages LDMA resources dynamically while the emlib code above does so in a static fashion. Put simply, DMADRV and CSLIB, as currently written, cannot coexist because it would be a case of the right hand not knowing what the left is doing.
Radio stack plug-in support for CSLIB is in development. For users with immediate needs, setupCSENdataDMA() could be rewritten to use DMADRV, and the LDMA_IRQHandler() instance in device_CSEN/hardware_routines.c would be eliminated and replaced with a callback function.
Can CSLIB be used with the Thread SDK?
I'm wondering if/when you'll have a sample project for utilizing the capacitive touch features of the EFR32 parts.
As an investigation, I tried porting the sample code found in...
C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.0\app\mcu_example\SLSTK3402A_EFM32PG12\cslib
...but I stumbled on conflicting definitions of LDMA_IRQHandler from the required "dmadrv" module (I believe the serial plugin uses this).
Are you planning on integrating CSLIB with Thread sample projects anytime soon? Perhaps in the form of a plugin?
For starters, it's important to note that if you are using the serial plug-in for the Thread SDK, it makes use of UARTDRV, which, in turn, depends on DMADRV. Both of these drivers are components of emdrv, a driver abstraction layer that is part of the Gecko SDK platform. It is common for other emdrv components, like GPIOINT, RTCDRV, SLEEP, TEMPDRV, and USTIMER, to be used in a Thread application, including the samples that can be selected when creating a new project in Simplicity Studio.
Emdrv, in turn, sits on top of emlib, which is the hardware abstraction layer for the EFM32 and EFR32 device families and is also part of the Gecko SDK platform. So, while emlib simplifies the task of configuring the underlying MCU hardware on a given EFM32 or EFR32 device, emdrv allows portable code to be written that can run on any EFM32 or EFR32 device. These distinctions are important because they help explain why the CSLIB example code for the Pearl Gecko 12 Starter Kit cannot be incorporated into a Thread project.
In particular, the conflicting definitions of the LDMA_IRQHandler() occur because CSLIB has its own implementation of the function in the device_CSEN/hardware_routines.c file that is a required part of all projects that make use of CSLIB:
This is not allowed in a project that makes use of UARTDRV because DMADRV (which is required by UARTDRV) must have its own implementation of LDMA_IRQHandler() in order to dispatch callback functions. Furthermore, CSLIB performs its own LDMA configuration using emlib functions:
As you might imagine, this programming of the LDMA is not possible because DMADRV must handle the allocation of all channels and manage all descriptors. This is especially important when you consider that DMADRV manages LDMA resources dynamically while the emlib code above does so in a static fashion. Put simply, DMADRV and CSLIB, as currently written, cannot coexist because it would be a case of the right hand not knowing what the left is doing.
Radio stack plug-in support for CSLIB is in development. For users with immediate needs, setupCSENdataDMA() could be rewritten to use DMADRV, and the LDMA_IRQHandler() instance in device_CSEN/hardware_routines.c would be eliminated and replaced with a callback function.