Hi, I just managed to make a working port for the ATmega2560 using GCC-AVR411 from Atman Electronics and FreeRTOS 4.1.0. I have not verified all details, but at least the LEDs are flashing as expected. However, I get some warnings during compilation and my gcc knowledge does not yet cover this case: ../../Source/tasks.c: In function ‘vTaskSwitchContext’: ../../Source/tasks.c:1404: warning: dereferencing type-punned pointer will break strict-aliasing rules     listGET_OWNER_OF_NEXT_ENTRY( pxCurrentTCB, &( pxReadyTasksLists[ uxTopReadyPriority ] ) ); Same error in "vListInitialise" and others for     pxList->pxIndex = ( xListItem * ) &( pxList->xListEnd ); This is my very first contact with FreeRTOS and I’d appreciate some clues or reassuring words. Thanks, Johan

hi Johan, I have the same warning on ARM7: ../../Source/tasks.c: In function ‘vTaskSwitchContext’: ../../Source/tasks.c:1404: warning: dereferencing type-punned pointer will break strict-aliasing rules listGET_OWNER_OF_NEXT_ENTRY( pxCurrentTCB, &( pxReadyTasksLists[ uxTopReadyPriority ] ) ); Janusz

This came up a month or two ago.  I think you might find some info on it by searching this forum. Basically the type punning is deliberate and used to lower the RAM requirements of the kernel code.  You can safely remove the warning using a compiler option – or change the compiler options to remove the strict aliasing option (which I think is not default anyway).

Shoudn’t we do something about this warning? I recenly tried latest codesourcery port of gcc and LPC2106 gcc demo. Here is the output (same as previous post): ../../Source/list.c: In function ‘vListInitialise’: ../../Source/list.c:94: warning: dereferencing type-punned pointer will break strict-aliasing rules ../../Source/list.c:102: warning: dereferencing type-punned pointer will break strict-aliasing rules ../../Source/list.c:103: warning: dereferencing type-punned pointer will break strict-aliasing rules ../../Source/list.c: In function ‘vListInsert’: ../../Source/list.c:160: warning: dereferencing type-punned pointer will break strict-aliasing rules I can suppress warnings with -fno-strict-aliasing or use lower levels of code optimization but I don’t think this is "The" solution to be used. BR, Slawc

What does the warning mean?  Punned?

Hi Johan, I suppose you started from the avr323 port. Could you post the changes you made ?

Can you post the changes you made to convert the mega323 proj onto a mega2560? That would be interesting for all the beginners (like me). Thx, BA601VT

Sure. I havn’t examined what could to be done, if something, to break the notorious +128k limit. With the latest WinAVR I suppose it would be worth the effort. - – – E:projectsfreertosSourceportableGCC>type port.patch -– ATMega323port.c    Sun Nov 26 16:31:10 2006 +++ ATMega2560port.c   Sun Feb 25 12:02:48 2007 @@ -1,5 +1,5 @@ /* –       FreeRTOS.org V4.1.3 – Copyright (C) 2003-2006 Richard Barry. +       FreeRTOS.org V4.1.2.1 – Copyright (C) 2003-2006 Richard Barry.         This file is part of the FreeRTOS.org distribution. @@ -32,11 +32,11 @@ /* -Changes from V2.6.0 +Changes from V4.1.2  (ATmega323) + +   Port made for ATmega2560: Register names and initialisations changed. +   Three byte program counter handled. –       + AVR port – Replaced the inb() and outb() functions with direct memory –         access.  This allows the port to be built with the 20050414 build of –         WinAVR. */ #include <stdlib.h> @@ -56,7 +56,7 @@ #define portCLEAR_COUNTER_ON_MATCH             ( ( unsigned portCHAR ) 0x08 ) #define portPRESCALE_64                        ( ( unsigned portCHAR ) 0x03 ) #define portCLOCK_PRESCALER                    ( ( unsigned portLONG ) 64 ) -#define portCOMPARE_MATCH_A_INTERRUPT_ENABLE   ( ( unsigned portCHAR ) 0x10 ) +#define portCOMPARE_MATCH_A_INTERRUPT_ENABLE   ( ( unsigned portCHAR ) 0x02 ) /*———————————————————–*/ @@ -216,6 +216,13 @@         *pxTopOfStack = ( portSTACK_TYPE ) ( usAddress & ( unsigned portSHORT ) 0x00ff );         pxTopOfStack–; +       /* Three byte program counter in ATmega2560. +       Set the top byte to 0 since we don’t yet have access to the upper +       (128k+) program bank. */ +       usAddress >>= 8; +       *pxTopOfStack = ( portSTACK_TYPE ) ( usAddress & ( unsigned portSHORT ) 0x00ff ); +       pxTopOfStack–; +         /* Next simulate the stack as if after a call to portSAVE_CONTEXT().         portSAVE_CONTEXT places the flags on the stack immediately after r0         to ensure the interrupts get disabled as soon as possible, and so ensuring @@ -395,9 +402,9 @@         /* Enable the interrupt – this is okay as interrupt are currently globally         disabled. */ –       ucLowByte = TIMSK; +       ucLowByte = TIMSK1;         ucLowByte |= portCOMPARE_MATCH_A_INTERRUPT_ENABLE; –       TIMSK = ucLowByte; +       TIMSK1 = ucLowByte; } /*———————————————————–*/ Changes in the Demo is trivial and left as an exercise; Change UCSRB to UCSR0B etc.

The 2560 port is working on 2561 too! and for the AVR example, use first/second usart: 1. Change SIG_UART_xxxx TO SIG_USART0_XXXX 2. Change all UART registers to UART0 registers More test need to be done to check reliability.

Where is a diffrent timer intialization on atmega323 at90SCAN128 and other Mega family chips

I have also succeeded in getting FreeRTOS to run on ATMega2560, at least partly.. when running the (modified) ATMega323 demo, the cpu stalls if data is received by the USART.. the problem is related to the following in "serial.c": SIGNAL( SIG_USART0_RECV ) { signed portCHAR cChar; portBASE_TYPE xHigherPriorityTaskWoken = pdFALSE;     /* Get the character and post it on the queue of Rxed characters.     If the post causes a task to wake force a context switch as the woken task     may have a higher priority than the task we have interrupted. */     cChar = UDR0; /*    if the following line is enabled, the cpu stalls when data is received.     xQueueSendFromISR( xRxedChars, &cChar, &xHigherPriorityTaskWoken ); */     if( xHigherPriorityTaskWoken != pdFALSE )     {         taskYIELD();     } } i have, as of now, no idea why this happens, since this is only my second day using FreeRTOS (I guess a "newbie" label is ok :-)