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


Best way to handle While on buses

Posted by Damien Etienne on September 16, 2013
Hi There,

Often we use SPI or I2C with a while into some flag bits, for instance while(I2C2CONbits.SEN); for Microchip I2C.

Question is how the best handle such while with considering that our task should not be allowed to stop in case that a component fails.

Several ways to work around, maybe the simplest is a
for (i=0; I2C2CONbits.SEN; i++) if (i>500) return ERROR;

But with an RTOS we probably can go further like
for (i=0; I2C2CONbits.SEN; i++) { if (i>5) return ERROR; vTaskDelay( 1/ portTICK_RATE_MS ); } 

But in this case 1ms delay will probably be too long in most bus.

Maybe another way would be to use co-routine an create a routine for each of the sub components, if one fails then the co routine fails and a check on failed co-routine could stop them to release the bus resources ?

Of course there is always the interrupt-way but this pose other problem and the failing device always pause the same problem. In a RTOS environment I would prefer the while style.

I'd like to know how the expert are handling this the nicest way.


RE: Best way to handle While on buses

Posted by Richard Damon on September 16, 2013
In an RTOS environment you NEVER prefer the while loop if it is going to go on for any period of time (like longer than a pair of context switches). You configure the system to generate an interrupt on the status bit, and in the interrupt do simple operations and interface to the task with queues/semaphores. The task can wait for these, with a timeout, to detect when something has go wrong.

Best way to handle While on buses

Posted by damieneti on September 17, 2013

Following your advice I've start implementing the interrupt.

For information, before the RTOS we were handling the all I2C by interrupt, but the complexity of the code made it difficult to maintain.

First problem come to the point the the all microchip I2C library has to be rewritten, I've spend several hours doing so but problems keep accumulating as: 1. The time for handling the semaphores seem too long, a packet before took about 300us while it takes about 4ms with semaphore and interrupt. 2. Some interrupt are missed because the semaphore task switch takes too long time. 3. Some of the state doesn't have interrupt.

It is also important to specify that the microchip PIC24 generate about 5 interrupt for each byte transferred (either way) that all needs to be handled.

Driving the microchip I2C (I'm not talking about other uC) through interrupt with the RTOS is basically a big headache while having a low priority task doing the job blocking on "while" will work as good (if not better).

So I don't really get your point.

Best way to handle While on buses

Posted by richard_damon on September 17, 2013

I have implemented I2C drivers on the PIC24/dsPIc that sends data at full 400KHz speed, so if it is taking you 4ms to send a small message, you are doing something wrong. Unfortunately, due to the contractual obligations the software was developed under, I will need to get permission to share the code.

Yes, you do NOT just take their sample I2C code and replace the wait loops with semaphore waits, THAT would be very inefficient. The ISR does most of the I/O operations, the "Task" level code initiates the start bit and loads data queues, and the ISR cycles through the phases of the I2C transaction.

I don't understand "missing" interrupts, on the PIC, I2C interrupts are persistent until cleared, so you can't "miss" an interrupt, at worse you are slow to respond.

I didn't find any operation that needed a response that didn't provide an interrupt to key that operation on.

[ 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