Home > On-Demand Archives > Theatre Talks >

Considerations for Abstraction Based Connectivity Solutions

Gokhan Tanyeri - Watch Now - Duration: 29:05

Considerations for Abstraction Based Connectivity Solutions
Gokhan Tanyeri
The purpose of this paper is to delve into the utilization of software abstraction strategies in order to overcome platform-specific limitations and foster the reuse of existing software across various platforms. The implementation of an abstraction-based approach requires careful consideration of several key elements, such as abstracting processor architecture, microcontroller/microprocessor unit (MCU/MPU), operating system/real-time operating system (OS/RTOS), Bluetooth or Wi-Fi chipset, hardware interface, TCP/IP network stack, permanent storage, and debugging software. As a demonstration of how abstraction-based connectivity solutions can be executed, we will showcase the example of ClarinoxSoftFrame, developed by Clarinox.
M↓ MARKDOWN HELP
italicssurround text with 
*asterisks*
boldsurround text with 
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with 
`backticks`
strikethroughsurround text with 
~~two tilde characters~~
quote
prefix with 
>
nathancharlesjones
Score: 1 | 8 months ago | 1 reply

Thanks for the talk! It seems that abstracting the OS/RTOS might be difficult if a vendor library uses features or function calls that are specific to a single RTOS implementation (such as using osDelay() (CMSIS-RTOSv2) or vTaskDelay() (FreeRTOS) instead of a generic delay function) or if the vendor library writes tasks with infinite loops (requiring the use of a preemptive scheduler). Do you see this problem in practice and, if so, how do you work around it?

GokhanTanyeri
Score: 0 | 8 months ago | no reply

Hi Nathan, this is an excellent question! You are absolutely right, if a vendor library is using API calls specific to a single RTOS then there is a problem with porting this code to another RTOS. We definitely see this a lot. Our approach is, as a minimum prepare RTOS wrapper for your code. But then the next stage of abstraction is handling the behaviour difference of each RTOS, your example delay function may be more easily found but some of the complex event or messaging mechanisms, or scheduling may be handled differently by each RTOS. One way is to prepare higher level functionality to be handled by the framework. Of course this means you spend a lot more effort to build such a framework. But if your product line require such an abstraction why not! We are currently providing our framework to handle for Wi-Fi, Bluetooth and Bluetooth Low Energy stack but a number of our customers use our framework for their own application as well. Hope this helps to address your question. Cheers, Gokhan

OUR SPONSORS