It may not be just the cc2652 that has these pitfalls, it is estimated that they exist in the cc26xx series.
CCS precompiled macro configuration location
Clock acquisition
Clock get__STATIC_INLINE uint32_t SysCtrlClockGet(void) is in sys_ctrl.h, sys_ctrl.h is not under the project path, it is in its sdk
The tick time is obtained by ICall_getTicks(); the unit is 10us and is incremented by 1; ICall_getTickPeriod() is the unit, which is 10us;
Callback function settings
There are two ways to set the callback function: set it in the Callback Function of .syscfg, or set it to NULL and use GPIO_setCallback in the program for callback binding;
No matter which of the above methods is used, you need to add GPIO_init() in front of GPIO_enableInt(CONFIG_GPIO_IRQ_3993), otherwise the interrupt cannot be entered.
IRQ needs to get its level in ENEXTIRQ
Official reference document: /ti/simplelink_cc13x2_26x2_sdk_5_20_00_52/docs/drivers/doxygen/html/_g_p_i_o_8h.html
nanosecond delay
Limited by the maximum 48M crystal oscillator of CC2652, it is impossible to achieve ns level delay. The fastest can only achieve 62ns delay as follows:
/* 3 cycles per loop: 1 loop @ 48 Mhz ~= 62 ns ; 8 loop @ 48 Mhz ~= 0.5 us */
CPUdelay(1);
SPI and low power consumption
SPI normal mode reference file for CC2652: ti/simplelink_cc13x2_26x2_sdk_5_20_00_52/docs/drivers/doxygen/html/_s_p_i_8h.html
CC2652 SPI DMA mode reference file: ti/simplelink_cc13x2_26x2_sdk_5_20_00_52/docs/drivers/doxygen/html/_s_p_i_c_c26_x2_d_m_a_8h.html
Because SPI transmission uses a high-frequency crystal oscillator, the device cannot enter the standby state during SPI communication. It can enter the standby state after calling SPI_transferCancel().
CONFIG_SPI_3993 in SPI_open(CONFIG_SPI_3993, &SPIparams) is configured in .syscfg
Main and co-processor multiplexing SPI problem
After testing, the main co-processor cannot reuse GPIO (including SPI)
After the main processor configures the SPI pin, if the initialization of the coprocessor is called, the pin will be preempted by the coprocessor; the pin of the main processor is configured in Board_initGeneral();, but if Board_initGeneral(); is called a second time; Preemption will cause a crash.
The current test result should be that when the coprocessor is turned off, control will automatically be transferred to the main processor. This needs further verification.
DAC loading
The load capacity is relatively weak, uA level, and it takes a little effort to drive voltage-type MOS tubes.
Pin configuration
Pin configuration can use the GPIO_write method or the PIN_setOutputEnable method.
When DIO31 is configured as output, the program crashes in Board_initGeneral() (this is very strange, and it should not be expected); currently, configuring the pin as DIO26 can