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

Bidirectional Queue

Posted by Ruben_saz on April 2, 2010
Hi there.

I'm doing some code now to interface with I2C devices using freeRTOS. As the I2C communications are half duplex, I was wondering if I could safely use a single queue for incoming and outgoing data. That means, using the same queue to communicate with the ISR when transmitting and receiving.

Hope someone can help me.

Best wishes ;)

RE: Bidirectional Queue

Posted by MEdwards on April 2, 2010
Queues are very flexible and can have any number of readers and any number of writers. Your only problem is going to be coordinating your multiple readers and writers. If a task wrote to a queue and then read from the queue they would just read out what they had just written.

You could use two queues? One in each direction if you have enough resources.

RE: Bidirectional Queue

Posted by Richard Damon on April 2, 2010
While I won't say you can't use one queue, it may make things more difficult, as you will need to do something to make the task that is taking data from the I2C input not grab the date being sent out. (And then it consumes all the data that has come in before sending data back out).

While the bus itself may be half duplex, making it a single queue says you will need to keep the concept of half duplex all the way to the program terminal task. I suspect that in most cases, the whole reason you are using a queue there at all, and not just a mailbox with a data ready flag, is that you want to allow for the data coming in to have the option of getting a bit ahead of the consuming task, and/or let what ever is producing data be able to get ahead of the actual bus. At this point the half-duplex assumption is no longer valid, and the standard model of an input and output queue is suggested.

RE: Bidirectional Queue

Posted by Ruben_saz on April 3, 2010
Well richard, I've implemented a I2C routine that handles reading or writing a block of N bytes of data, it has the following prototype:
unsigned int iI2CDriverTransaction( xI2CHandle xI2CResources, unsigned int iDevAddress, unsigned int iMemAddress, unsigned int iBusDirection, unsigned int iBytesToTransfer, void * pvDataBuffer )

I don't know if that's what you mean with the mailbox. This function basically takes a mutex, writes data to a structure (which is used by a Finite State Machine running on the I2C ISR), and generates a interrupt which causes a FSM to start working. Then the function(task) blocks and waits for a message from the ISR on what I called a ''Control Queue''. This message contains a code indicating what happened inside the FSM. When the message arrives from the ISR, the function gives back the mutex and returns with the code received from the control Queue. If data was successfully read or written this function returns E_SUCCESS, other codes are also provided, for example E_ERROR_NACK indicates that master did not received ACK from the given slave address.

What I'm trying to do now is to implement a layer of compatibility that allows me to use the MPFS(microchip file system) that is used in the TCP/IP stack and other application notes from Microchip. The TCP/IP stack I'm using includes files for SPI and I2C interface with eeprom memories. In the i2ceeprom.c file I find functions like this:
static unsigned char getcI2C( void )
{
I2C2CONbits.RCEN = 1; // enable master for 1 byte reception
while(I2C2CONbits.RCEN); // wait until byte received
return I2C2RCV; // return with read byte
}


Here for example, I'm looking for a way to replace this with a function that uses the Rtos to do something usefull instead of just checking the RCEN bit (with the bus at 400 Khz this may be too much wasted time). As we intend to receive only a byte at a time, a large queue doesn't makes sense. But for TX a large queue would be, in theory OK. I'm still wondering how to do this and I thought that I could use a single queue for TX and RX, so the question.

Well, those are some random thoughts, of what I'm trying to do. If anyone has worked with anything similar or know about a embedded filesystem for use in small eeprom or flash memories, or have some comments, it would be cool. Meanwhile I'll be checking in detail the MPFS implementation.

Thank you guys, have a nice day!


[ 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