FreeRTOS 7.0.0 vs current FreeRTOS 7.4.2

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does any one have experience with using the current FreeRTOS on a AVR32 processor?

I would be starting from the demo code and upgrading.

The example code in ASF is based on FreeRTOS 7.0.0. It also is not exactly the same as the FreeRTOS 7.0.0 version available from FreeRTOS. There are three changes in xTaskResumeFromISR.

There are more significant differences in the UC3 portability implementation between the Atmel variation and the FreeRTOS supported one.

Another data point, the portability library in FreeRTOS for the UC3 is the same between 7.0.0 and 7.4.2. (Thanks Beyond Compare).

So which is going to be the most stable?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

we use the ASF version running 9 tasks, with 6 different priorities. I'd say that it mostly depends on the complexity and design of your project but our system runs very stable accessing a lot of hardware (USB, 4x USART, SPI, TWI, EBI, ...) e.g. for inter processor and iPhone communication.

-sb

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

... follow up from https://www.avrfreaks.net/index.p...

tomclary683 wrote:

You actually nailed what my problem seems to be. The default stack for the LEDx task from the Atmel demo was not big enough. I think it was sometimes catching interrupts and blowing the stack. This was corrupting TCB's and the failures were intermittent based on the over run.

I guess screwed up is screwed up but I was not thrilled to learn the TCB's are allocated adjacent to the stacks in FreeRTOS.


you may define configCHECK_FOR_STACK_OVERFLOW and a vApplicationStackOverflowHook() callback during development.

some more tips:

-make sure that all interrupts use the same level (e.g. AVR32_INTC_INT1),
since FreeRTOS does not support nested interrupts

-use the ISR_FREERTOS macro for interrupt service routines

-in case you use dynamic memory allocation, better make sure to protect pvPortMalloc and vPortFree by disabling interrupts there:

void *pvPortMalloc( size_t xWantedSize )
{
void *pvReturn;

	irqflags_t flags = cpu_irq_save();

	vTaskSuspendAll();

	{
		pvReturn = malloc( xWantedSize );
	}
	xTaskResumeAll();

	cpu_irq_restore(flags);

	#if( configUSE_MALLOC_FAILED_HOOK == 1 )
	{
		if( pvReturn == NULL )
		{
			extern void vApplicationMallocFailedHook( void );
			vApplicationMallocFailedHook();
		}
	}
	#endif

	return pvReturn;
}
/*-----------------------------------------------------------*/

void vPortFree( void *pv )
{
	if( pv )
	{
		irqflags_t flags = cpu_irq_save();
		vTaskSuspendAll();
		{
			free( pv );
		}
		xTaskResumeAll();
		cpu_irq_restore(flags);
	}
}

-sb

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Great suggestion about turning on the stack overflow detection. Turns out another example task I had added was blowing by the stack bounds.

It was udpecho from the LWIP contrib library. It allocated a 4K buffer to optionally print out the message. This own would have been more subtle because the buffer was not always used and the corruption more erratic.