Silicon Labs
|
Silicon Labs Community Silicon Labs Community
  • Products
    1. 8-bit MCU
    2. 32-bit MCU
    3. Bluetooth
    4. Proprietary
    5. Wi-Fi
    6. Zigbee & Thread
    7. Z-Wave
    8. Interface
    9. Isolation
    10. Power
    11. Sensors
    12. Timing
  • Development Tools
    1. Simplicity Studio
    2. Third Party Tools
  • Expert's Corner
    1. Announcements
    2. Blog
    3. General Interest
    4. Projects
How to Buy
English
  • English
  • 简体中文
  • 日本語
//
Community // Blog

Making Peripheral Drivers Thread-safe

06/177/2019 | 03:27 PM
Janos Magasrevy
Employee

Level 5


If you are running in a multi-threaded environment in which you have more than one task making use of a peripheral driver such as USART, SPI, I2C, etc., you should consider making it thread-safe.

The Micrium OS kernel offers a variety of services designed to protect shared resources. In our case, let’s make use of the Mutual Exclusion Semaphore also known as mutex. Why a mutex? Because we want our resource (peripheral driver) to be accessed only by one task at a time. Regular semaphores present a vulnerability with priority-inversion. Mutexes, on the other hand, are implemented in a way that priority inversions are prevented by using priority inheritance.

For this exercise, you will be editing files from the Gecko SDK, which is not recommended therefore do this with caution.

In the peripheral driver file that you want to protect, include the following file:

#include  <kernel/include/os.h>

Now we have to declare a global variable for our mutex, for example, if you want to protect the SPI you could declare it as follows:

OS_MUTEX  SPI_Mutex;

With the mutex now declared, you need to invoke the kernel call to create it. My recommendation is to make this in the initialization function of the peripheral driver that you are using. You create the mutex by calling:

OSMutexCreate(&SPI_Mutex, “SPI Mutex”, &err);

Notice how the function requires an error argument, just declare RTOS_ERR  err locally and pass it on.

Always make sure to check the error returned, if it’s not RTOS_ERR_NONE then something went wrong.

The mutex is now created and registered with the kernel. Now you will need to wrap around the driver calls that your application is using with:

void foo () {

  RTOS_ERR  err;

  OSMutexPend(&SPI_Mutex,            /* Pointer to the mutex */
               0,                    /* No timeout */
               OS_OPT_PEND_BLOCKING, /* Block if not available */
               DEF_NULL,             /*Timestamp not used */
              &err);

  if (err.Code != RTOS_ERR_NONE) {
      /* handle error */
  }

  /* peripheral driver function code */
  ...
  ...
  ...

  OSMutexPost(&SPI_Mutex,
               OS_OPT_POST_NONE,
              &err);

  if (err.Code != RTOS_ERR_NONE) {
      /* handle error */
  }
}

Please make sure to check the returned errors. A common one is RTOS_ERR_NOT_READY, this happens when the pend or post calls are made before the kernel is in its running state (after the call to OSStart()).

If the driver initialization function can potentially be called multiple times from more than one task, my recommendation is to also protect it.

With this setup, you can be sure that your peripheral is only being accessed by one task at a time.

Beware also that some drivers have abort functions, you have to be careful with this and not lock your system on a mutex pend. For more information on how to protect a resource using Micrium OS please visit https://doc.micrium.com/display/OSUM50600/Resource+Management+Using+the+Kernel

  • Blog Posts
  • Micrium OS
  • Janis Atecayombo

    Level 3


    Replied Apr 28 2020, 9:32 AM
    I’m very pleased with my essay, glad was ready for today! Checking out prices and terms and placing an order took less than 10 minutes and then I received a confirmation call from the call centre worker almost at once. The paper quality is top-notch. I think it's love to https://ewriters.pro service for all study life. I really appreciate it.
    0

Tags

  • Wireless
  • High Performance Jitter Attenuators
  • EFR32FG22 Series 2 SoCs
  • EFR32MG21 Series 2 SoCs
  • Security
  • Bluegiga Legacy Modules
  • Zigbee SDK
  • ZigBee and Thread
  • EFR32BG13 Series 1 Modules
  • Internet Infrastructure
  • Sensors
  • Wireless Xpress BGX13
  • Blue Gecko Bluetooth Low Energy SoCs
  • Z-Wave
  • Micrium OS
  • Blog Posts
  • Low Jitter Clock Generators
  • Bluetooth Classic
  • Makers
  • Flex SDK
  • Tips and Tricks
  • timing
  • Smart Cities
  • Smart Homes
  • IoT Heroes
  • Reviews
  • RAIL
  • Simplicity Studio
  • Tiny Gecko
  • EFR32MG22 Series 2 SoCs
  • Mighty Gecko SoCs
  • Timing
  • Temperature Sensors
  • Blue Gecko Bluetooth Low Energy Modules
  • Ultra Low Jitter Clock Generators
  • General Purpose Clock Generators
  • EFR32BG22 Series 2 SoCs
  • Industry 4.0
  • Giant Gecko
  • 32-bit MCUs
  • Bluetooth Low Energy
  • 32-bit MCU SDK
  • Gecko
  • Microcontrollers
  • Jitter Attenuators
  • EFR32BG21 Series 2 SoCs
  • News and Events
  • Wi-Fi
  • Bluetooth SDK
  • Community Spotlight
  • Clock Generators
  • Biometric Sensors
  • General Purpose Jitter Attenuators
  • Giant Gecko S1
  • WF200
  • Flex Gecko
  • Internet of Things
  • 8-bit MCUs
  • Wireless Jitter Attenuators
  • Isolation
  • Powered Devices
  • Power

Top Authors

  • Avatar image Siliconlabs
  • Avatar image Jackie Padgett
  • Avatar image Nari Shin
  • Avatar image lynchtron
  • Avatar image deirdrewalsh
  • Avatar image Lance Looper
  • Avatar image lethawicker

Archives

  • 2016 March
  • 2016 April
  • 2016 May
  • 2016 June
  • 2016 July
  • 2016 August
  • 2016 September
  • 2016 October
  • 2016 November
  • 2016 December
  • 2017 January
  • 2017 February
  • 2017 March
  • 2017 April
  • 2017 May
  • 2017 June
  • 2017 July
  • 2017 August
  • 2017 September
  • 2017 October
  • 2017 November
  • 2017 December
  • 2018 January
  • 2018 February
  • 2018 March
  • 2018 April
  • 2018 May
  • 2018 June
  • 2018 July
  • 2018 August
  • 2018 September
  • 2018 October
  • 2018 November
  • 2018 December
  • 2019 January
  • 2019 February
  • 2019 March
  • 2019 April
  • 2019 May
  • 2019 June
  • 2019 July
  • 2019 August
  • 2019 September
  • 2019 October
  • 2019 November
  • 2019 December
  • 2020 January
  • 2020 February
  • 2020 March
  • 2020 April
  • 2020 May
  • 2020 June
  • 2020 July
  • 2020 August
  • 2020 September
  • 2020 October
  • 2020 November
  • 2020 December
  • 2021 January
  • 2021 February
Silicon Labs
Stay Connected With Us
Plug into the latest on Silicon Labs products, including product releases and resources, documentation updates, PCN notifications, upcoming events, and more.
  • About Us
  • Careers
  • Community
  • Contact Us
  • Corporate Responsibility
  • Privacy and Terms
  • Press Room
  • Investor Relations
  • Site Feedback
  • Cookies
Copyright © Silicon Laboratories. All rights reserved.
粤ICP备15107361号
Also of Interest:
  • Bring Your IoT Designs to Life with Smart,...
  • A Guide to IoT Protocols at Works With...
  • IoT Hero Rainus Enhances the In-Store Shopping...