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 Bluetooth sample projects anytime soon? Perhaps in the form of a plugin?

For starters, it's important to note that the sample Bluetooth projects include dmadrv.c in the bgapi folder. DMADRV is a component of emdrv, a driver abstraction layer that is part of the Gecko SDK platform. Other commonly used emdrv components include GPIOINT for pin interrupt event callback dispatching, UARTDRV for asynchronous serial communications, and USTIMER for microsecond-level delays.

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. Given that dmadrv.c is included in sample Bluetooth projects, it should come as no surprise that em_ldma.c is, too. 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.

Although both dmadrv.c and em_ldma.c are included in the sample Bluetooth projects, such as soc-smartPhone, it might come as a surprise that none of the samples actually use LDMA. Given this, can't the existing CSLIB code for EFM32PG12 simply be grafted into an EFR32BG12 project? The answer is "not exactly" because an implementation of LDMA_IRQHandler() is found 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;
  }
}

The trouble arises because DMADRV has its own implementation of LDMA_IRQHandler() in order to dispatch callback functions. Other components of emdrv, like UARTDRV and SPIDRV depend on DMADRV, so removing dmadrv.c will not eliminate the conflict. As an alternative, would it be possible to rewrite the LDMA-related functions in CSLIB to make use of DMADRV? Looking again at the code in device_CSEN/hardware_routines.c reveals another area of concern:

static void setupCSENdataDMA(void)
{
  static const LDMA_Init_t ldma_init = LDMA_INIT_DEFAULT;

  LDMA_TransferCfg_t csenTransfer =
    LDMA_TRANSFER_CFG_PERIPHERAL(LDMA_CH_REQSEL_SIGSEL_CSENDATA | LDMA_CH_REQSEL_SOURCESEL_CSEN);

  LDMA_Descriptor_t csenTransferDesc = LDMA_DESCRIPTOR_SINGLE_P2M_BYTE(&CSEN->DATA,
                                                                       CSLIB_autoScanBuffer,
                                                                       DEF_NUM_SENSORS);

  LDMA_TransferCfg_t baselineTransfer =
    LDMA_TRANSFER_CFG_PERIPHERAL(LDMA_CH_REQSEL_SIGSEL_CSENBSLN | LDMA_CH_REQSEL_SOURCESEL_CSEN);

  LDMA_Descriptor_t baselineTransferDesc = LDMA_DESCRIPTOR_SINGLE_M2P_BYTE(CSLIB_autoScanBuffer, &CSEN->DMBASELINE,
                                                                           DEF_NUM_SENSORS);

  /* Initialize descriptor for CSEN DATA LDMA transfer */
  LDMA_descCh0 = csenTransferDesc;
  LDMA_descCh0.xfer.doneIfs = 0;
  LDMA_descCh0.xfer.blockSize = ldmaCtrlBlockSizeUnit1;
  LDMA_descCh0.xfer.ignoreSrec = 0;
  LDMA_descCh0.xfer.reqMode = ldmaCtrlReqModeBlock;
  LDMA_descCh0.xfer.size = ldmaCtrlSizeWord;

  /* Initialize descriptor for CSEN BASELINE LDMA transfer */
  LDMA_descCh1 = baselineTransferDesc;
  LDMA_descCh1.xfer.doneIfs = 0;
  LDMA_descCh1.xfer.blockSize = ldmaCtrlBlockSizeUnit1;
  LDMA_descCh1.xfer.ignoreSrec = 0;
  LDMA_descCh1.xfer.reqMode = ldmaCtrlReqModeBlock;
  LDMA_descCh1.xfer.size = ldmaCtrlSizeWord;

  /* Initialize the LDMA with default values. */
  LDMA_Init(&ldma_init);
  LDMA_StartTransfer(1, &baselineTransfer, &LDMA_descCh1);
  LDMA_StartTransfer(0, &csenTransfer, &LDMA_descCh0);
}

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.

So, if CSLIB compatibility with DMADRV isn't immediately possible (more on this later), would it be possible to exclude DMADRV from a Bluetooth project and allow CSLIB to manage the LDMA? As noted above, the Bluetooth examples don't make use of DMADRV. Why not exclude it altogether?

While this entails giving up emdrv and making use of emlib to write peripheral drivers, it is, arguably, the simplest option for integrating CSLIB functionality into a Bluetooth stack application. After creating a new project, say from one of the existing examples, either delete dmadrv.c from the bgapi folder or disable it via Properties -> C/C++ Build -> Exclude resource from build when right-clicking on the file. Having done this, CSLIB can be added to the project. Just be sure to add the CSLIB middleware directories to the project's #include paths along with the relevant source files.

Plug-in support for CSLIB across the various Silicon Labs radio stacks is in development. In the meantime, for users requiring emdrv support, the only option would be to dig into device_CSEN/hardware_routines.c and rewrite the relevant functions to use DMADRV. The first and most obvious task would be to eliminate the LDMA_IRQHandler() instance and replace it with a callback function.