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

Atmel SAM4S-EK2 FreeRTOS TWI Master API

Posted by pugglewuggle on September 25, 2013

Hi Richard,

I've been working with my Atmel FAE on the SAM4S-EK2 eval board. I'm trying to get a TWI master working and can't seem to get it going. The board is pretty much the same as the SAM4S-EK, for which you have a demo application, except the CPU's RAM and flash are different... other than that the registers and peripherals are identical.

The FAE mentioned to me that the ASF implementation of FreeRTOS TWI, SPI, USART, and PDC (DMA) peripherals were actually personally written by you (developed for Atmel).

I've run the example code in the comments of the freertostwimaster.h file but don't see any traffic on the bus. I've got an oscilloscope attached to the lines for TWI1 (PB4 and PB5) and see no signals. The same pins are shared by the JTAG on the peripheral mux and I do see JTAG traffic when using JTAG, so I'm certain they're the right pins.

Also, the status code returned from freertostwiread_packet() is always "timed out". We are using synchronous mode.

I have also done:

gpioconfigurepin(TWI1DATAGPIO, TWI1DATAFLAGS); gpioconfigurepin(TWI1CLKGPIO, TWI1CLKFLAGS);

so the pins are certainly in the right mode.

I don't see a working example of TWI master anywhere. Can you please point me in the right direction/do you have any idea of what might be going on?

Also, what are the distinct advantages of the FreeRTOS TWI layer? Is it just the mutexes so it can be used by multiple tasks easily or is there some other advantage/purpose apart from running the regular TWI driver in a task?

Thanks!


Atmel SAM4S-EK2 FreeRTOS TWI Master API

Posted by richardbarry on September 26, 2013

Also, what are the distinct advantages of the FreeRTOS TWI layer? Is it just the mutexes so it can be used by multiple tasks easily or is there some other advantage/purpose apart from running the regular TWI driver in a task?

The integration uses the RTOS and the DMA to ensure a very efficiently, so no time is every spent polling for responses - the CPU can go off and execute other tasks while Rx and Tx transfers are in progress. Do you have the application note? http://www.atmel.com/images/doc42049.pdf

Look in Atmel Studio menu File -> New -> Example Project then when the dialogue box with ASF example projects search for "FreeRTOS peripheral control" to down select the number of projects found, then open the FreeRTOS peripheral control example for the SAM3X-EK. I believe that project uses the TWI to talk to an EEPROM (there are also other projects that do the same). You can use that as an example - although it uses TWI 0 rather than TWI 1.

Unfortunately the peripheral control example for the SAM4S-EK/EK2 does not contain the TWI example because no EEPROM was available on the board.

You mention the pins are muxed with the JTAG - could it be that you have not turned the JTAG off?

If you were to try using TWI 0 (just to experiment, not for your real app) - do you see anything on the scope then?

If you try using the standard ASF TWI drivers on TWI 1 (rather than the FreeRTOS drivers) do you see anything on the scope?

Those questions will help determine if it is more likely a hardware or software configuration issue.

[my availability will be a little limited for a few hours today]

Regards.


Atmel SAM4S-EK2 FreeRTOS TWI Master API

Posted by pugglewuggle on September 26, 2013

Hi Richard,

I have looked at AVR10008 and that's what I based my code on. I did setup a project with regular TWI master and no FreeRTOS, but it still doesn't work. JTAG only runs on this chip when in RESET state, so that's not a problem. I did isolate the freeze on the non-FreeRTOS to inside the twi.c file in ASF 3.11.0 (don't know if it affects other versions too). It gets stuck in an infinite while loop on line 276... Atmel is looking at it right now and will be trying to reproduce this on the same hardware. We'll see what they say.

Another quick question for you though if that's okay - Is it recommended to have a global freertostwimaster handle that is accessed by all tasks or to create a freertostwimaster object each task? The same goes for the USART and SPI drivers you wrote.

Also - I have a scheduler (not task/kernel sched, just for the purpose of executing a function at a certain time) I wrote in some code I'm porting to FreeRTOS right now... basically it can run any of a number of different functions with parameters (100s of different functions) depending on the information in a queue of structs - this would be treated in a manner similar to *pvParameters when using xTaskCreate(). At any given time there can be as many as 100 queued tasks that are to execute when a timer interrupt occurs. I don't think it is efficient to use the FreeRTOS schedule for this type of functionality due to the overhead of each task and pre-allocating the stack for each task. In the old code memory would be dynamically allocated as necessary. Should I just use the existing code and put it in a FreeRTOS task and vTaskDelay() until the next execution time or is there another recommendation you might have that might work better? Still getting used to FreeRTOS.


Atmel SAM4S-EK2 FreeRTOS TWI Master API

Posted by richardbarry on September 27, 2013

Is it recommended to have a global freertostwimaster handle that is accessed by all tasks or to create a freertostwimaster object each task

If each task is using the same TWI port then I think the only way to do it is to have one TWI object. You might have several variables that all reference the same TWI object - but the init function that returns the object should only be called once.

Should I just use the existing code and put it in a FreeRTOS task

If the functions being executed are run to completion (rather then infinite loops as per most tasks) then that would sound like the good option.

Regards.


Atmel SAM4S-EK2 FreeRTOS TWI Master API

Posted by pugglewuggle on March 7, 2016

I've run into the problem lately of certain global scope objects causing the system to freeze when accessed from multiple tasks. Is it safe to access global objects like this from multiple tasks or should I have a mutex that protects any access to the object itself?


Atmel SAM4S-EK2 FreeRTOS TWI Master API

Posted by rtel on March 8, 2016

I've only read the post immediately before this one in this thread, so am perhaps replicating previous posts:

The answer depends on what the object is and how it is accessed. The normal thread safety rules apply.

Can you say what the object is and how it is accessed. For example, is it a single variable or a compound type like a structure. Also, if there in one writer and multiple readers, or are there multiple writers?


Atmel SAM4S-EK2 FreeRTOS TWI Master API

Posted by pugglewuggle on March 8, 2016

Structure with members that are pointers to mutexes, specifically. I'm trying to aquire that mutex as *(myStruct->mutex) but it appears that if I do that it is somehow not safe.


Atmel SAM4S-EK2 FreeRTOS TWI Master API

Posted by edwards3 on March 9, 2016

There is no difference referencing a mutex handle sotred in a structure to a mutex handle stored in a separate variable. Your problem must be something else.


Atmel SAM4S-EK2 FreeRTOS TWI Master API

Posted by pugglewuggle on March 10, 2016

Sure enough, I was using pointers to the handle not dereferencing it. Oops


[ 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