FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [September 2006 Threads] AVR_ATmega2560_WinAVR port workingPosted by Johan R on September 16, 2006 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
RE: AVR_ATmega2560_WinAVR port workingPosted by Nobody/Anonymous on September 17, 2006 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
RE: AVR_ATmega2560_WinAVR port workingPosted by Nobody/Anonymous on September 17, 2006 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).
RE: AVR_ATmega2560_WinAVR port workingPosted by Nobody/Anonymous on January 25, 2007 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
RE: AVR_ATmega2560_WinAVR port workingPosted by Nobody/Anonymous on January 25, 2007 What does the warning mean? Punned?
RE: AVR_ATmega2560_WinAVR port workingPosted by Nobody/Anonymous on February 8, 2007 Hi Johan, I suppose you started from the avr323 port. Could you post the changes you made ?
RE: AVR_ATmega2560_WinAVR port workingPosted by Nobody/Anonymous on February 14, 2007 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
RE: AVR_ATmega2560_WinAVR port workingPosted by Johan R on February 25, 2007 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:\projects\freertos\Source\portable\GCC>type port.patch --- ATMega323\port.c Sun Nov 26 16:31:10 2006 +++ ATMega2560\port.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.
RE: AVR_ATmega2560_WinAVR port workingPosted by CHIAN JIUNN SEAH on February 26, 2007 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.
RE: AVR_ATmega2560_WinAVR port workingPosted by Nobody/Anonymous on March 12, 2007 Where is a diffrent timer intialization on atmega323 at90SCAN128 and other Mega family chips
RE: AVR_ATmega2560_WinAVR port workingPosted by Jesper Matthiesen on May 15, 2008 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 :-)
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|