Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

critical sections in cr queue implementation

Posted by Peter A. Bigot on July 26, 2012
While implementing optimized critical section macros for the MSP430 port, I notice that xQueueCRSend and xQueueCRReceive use portDISABLE_INTERRUPTS()/portENABLE_INTERRUPTS() instead of portENTER_CRITICAL/portLEAVE_CRITICAL to implement a critical section (at least, in V7.1.1).

An unusual but valid design for MSP430 programs is to leave interrupts disabled at all times except when in low power mode. The new macros I've implemented restore the interruptibility state to what it was when the first critical section was entered, rather than unconditionally enabling interrupts, so FreeRTOS can be used with applications that follow this design.

Explicitly enabling interrupts in xQueueCRSend and xQueueCRReceive breaks this feature for MSP430 programs that use coroutines.

Since taskENTER_CRITICAL is defined in terms of portENTER_CRITICAL, I believe it should be possible to assume the port-named versions are available, and to use them (if the intent was to avoid "task*" invocations in coroutine support). Is there a reason why the existing critical section approach is required for these functions?

Thanks.

RE: critical sections in cr queue implementation

Posted by Richard on July 26, 2012
I don't really recall, although the co-routines run at the lowest priority and are co-operative, so the critical section nesting is not as necessary.

I would be interested in seeing your code, as I'm sure would others, so please post it up to the FreeRTOS Interactive site once it is complete.

Regards.

RE: critical sections in cr queue implementation

Posted by Peter A. Bigot on July 26, 2012
Since the blocking coroutine calls are leaf functions and must be invoked from the coroutine function itself I would not expect a fully coroutine-based application to involve nesting, but I also wouldn't want interrupts enabled for me after the call completes if they were disabled before the call. Refining "critical section" so that doesn't happen would seem to make things more clear.

I'm working on a generalization of freertos-mspgcc (already on github at https://github.com/pabigot/freertos-mspgcc). The new version will provide FreeRTOS support for all MSP430 chips in a single port, leveraging an external library for peripheral/MCU-specific functionality and reducing the dependency on mspgcc (IAR and CCS should, at least theoretically, be supported as well). I'm optimistically hoping to have some compelling examples implemented in an initial public release in about a week, and will post an announcement when that happens.

RE: critical sections in cr queue implementation

Posted by Richard on July 26, 2012
The official FreeRTOS MSPGCC port has issues with the latest MSPGCC versions, and this is noted in the "Known Issues" list on the download page. Could you please post a link to your github repository in the FreeRTOS Interactive site, then I will add a link to the FreeRTOS Interactive post in the Known Issues list so people know where to go for up to date versions. Thanks!


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists