This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I was looking at samples of code for CC2340 versus the MSPM0 yesterday. In particular I was looking at code samples for the Simple Link approach to reading and writing GPIO and ADC compared to the code for the MSPM0. It looked like the API was quite different where the Simple Link code especially the examples using the RTOS were done at a higher abstraction level.
My question is if there is an approach where I can code once and have it port easily back and forth between the simple link and MSPM0 series CPU?
My second question is why is there such a difference between the two coding styles between the two set of examples? Am I just missing or have not found the higher level library for the MSPM0?
Third question: Is there a version of the driver libraries that works with the same API at least for shared components like ADC, GPIO, Comparators, etc between the two families? If so can you point me to the documentation for this and examples of moving code between these families without having to change the app level code?
Hello Joseph,
If you refer to the high-level Driver Interfaces, you will likely find similarities. This is because the drivers are centered around a portable application programming interface (API) which enables migration across the SimpleLink SDK portfolio, and similar M0 ARM cores
However, there are minor differences in the hardware implementation of either product, and thus device-specific implementations are necessary for further utilizing specific device features. This can occur even amongst similar product categories, such as the CC23XX SDK and CC13XX / CC26XX SDK (ADCLPF3 for instance). You will also find that each device of interest (CC23XX and MSPM0) is maintained by separate product categories within TI, so examples for the SDKs are further developed by different stakeholders which can introduce variance.
If you stay within the higher-level, more vague implementation of these peripherals then the code should remain fairly portable. It is when exposing device-specific implementation of these drivers that you will find variance which must be accounted for.
Regards,
Ryan