• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 41 subscribers
  • Views 2533 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC3120: porting host driver to STM32

Alain Werck
Prodigy 220 points
Part Number: CC3120
Other Parts Discussed in Thread: CC3100,

Hi,

My goal is to port the Simplelink host driver to a STM32 environment running without an OS, in a single threaded mode. I had a previous experience on the CC3100, which went well. However, I'm struggling here with the new SDK.

Based on my knowledge and the several documentation (SWRU455E - Part 16 / SimpleLink_Gen1_to_Gen2_SDK_Migration_Guide.html), I have managed so far:
+ to integrate and build successfully the host driver in my environment
+ obtain a working SPI communication between my processor and the CC3120
+ launch a sl_Start process and receive the started event

For that, I omitted all the Semaphore_ related functions (Semaphore_create_handle, SemaphoreP_delete, ...) which always return success; indeed I thought there were irrelevant for my non-OS implementation.
But after a quick test, I noticed that the Semaphore_ functions are called as soon as the sl_Start function is called !

Contrary to all I have seen in the documentation (see SWRU455E - Part 16.7 "This step is not required if the host application is based on a non-OS environment."), the sl_SyncObj and sl_LockObj are mandatory for the host driver to run properly, even in non-OS, non-multithreaded environment. Which I think is a little bit of a nonsense.

Is there any way to get support on this matter? Or am I missing something in the SDK configuration?

PS: I already went through the SemaphoreP_nortos.c / MutexP_nortos.c files included in the simplelink_msp432p4_sdk  to see semaphore/mutex examples, but they are too much hardware dependent to be ported easily. It is a lot more work than I expected reading the docs.

Thanks in advance,

Alain.

  • 0
    TI__Mastermind 40965 points

    Hi Alain,

    The CC3120 host driver does require synchronization objects to be implemented. With the currently released code examples, those sync objects are implemented within the driver porting layer (DPL). However, the CC3100 SDK method of implementing sync objects within the host driver can still be used.

    Let me explain. As you have noticed, in the CC3120 SDK the Semaphore/Mutex/other RTOS sync object functionality has been moved to the DPL within the MSP432 SDK. The idea behind this was that you would have one easy abstraction layer to adapt for any RTOS you want to use, beyond the TIRTOS and FreeRTOS supported by the SDK out of the box. Since each RTOS has its own way of handling sync objects, you would implement the DPL functions with your RTOS-specific APIs there. Then, all TI-provided drivers and code examples can use the same set of APIs for synchronization independent of the RTOS environment.

    Now, this approach works easily when porting between different RTOS environments, which typically provide implementations of all of the needed sync objects. However, in a noRTOS environment, you don’t have any of the implementations and have to figure out how to use your device’s hardware to implement the sync functionality. Thus, for MSP432 the noRTOS DPL uses hardware timers, the hardware interrupt controller, etc. to properly implement all of the functionality that would be given to you natively by an RTOS.

    In the previous generation, the CC3100 SDK took an entirely different approach to sync objects for noRTOS environments. The CC31xx host driver has always needed sync objects to be implemented, and the approach that was taken back then was that if “SL_PLATFORM_MULTI_THREADED” was NOT defined, it had to internally implement all of the sync functionality that it needed. If you look in the CC3100 SDK, specifically at nonos.c/.h of the host driver, you can see how the driver implements this functionality. The assumption made here was that for noRTOS, there would be no system-wide implementation of sync objects. The main drawback of this was that you could have redundant code if you already have sync APIs in your noRTOS system, and that it was hard to modify since these sync implementations were contained within the host driver.

    Regarding the porting documentation in section 16.7 of SWRU455e, the statement that you do not need to implement those objects is correct for the CC3100 host driver since it has the required functionality built in to handle noRTOS. It is indeed misleading for the currently released CC3120 host driver due to the aforementioned DPL dependency.

    With all that being said, for the CC3120 host driver you can also use the CC3100 SDK approach to handle the sync objects in noRTOS. In user.h, instead of defining all of the sl_SyncObj/sl_LockObj objects as DPL-implemented SemaphoreP/MutexP objects, redefine them to internal implementations. You can use the nonos.c/.h of the CC3100 SDK as a guide for how to do this. It should be possible to use that approach to completely avoid the need to port the DPL to your STM32 environment.

    Let me know if you need more guidance, or if you have any other questions.

    Regards,
    Michael

  • 0 in reply to Michael Reymond
    Prodigy 220 points

    Hi Michael,

    Thank you for the detailed answer ! This seems clearer to me.

    I will try to do what you suggested. I briefly looked into the nonos.c file from CC3100 SDK but I don't see the point yet.
    Anyway, I will port the DPL in a first approach.

    I let this thread open in case of future questions concerning the porting.

    Regards,

    Alain.