| Author |
Message |
|
|
 Posted: Oct 22, 2008 - 04:21 PM |
|
Joined: Dec 30, 2005
Posts: 2327
Location: Fort Collins, CO USA
|
|
I have had requests from several folks for my version of FreeRTOS for the ATmega2560. I had always intended to take the latest) version of FreeRTOS, apply my changes, and submit it to the FreeRTOS group as another supported AVR processor, but I simply haven't gotten around to it.
Instead, I'm posting the code here, free for anyone's use. Please note that *all* the licenses from FreeRTOS apply to this version. Also, you get the same support, which is you can ask me for help and I may or may not help, depending on the request and my work load.
This code is based on FreeRTOS 4.8.0, although the grand majority of the changes are fairly simple and would be easy to merge with the latest version of FreeRTOS.
I have not included the co-routine stuff, since I do not use it.
There is a new switch, USE_RTC_TIMER which switches the RTOS timer from a dedicated timer (timer 0) to the RTC-crystal driven timer (timer 2). Your tick is a little longer than 2 mS, but you now have a single OS/RTC timer instead of two timers used for the same task of keeping track of time.
I've included the second level heap manager, heap_2.c, since I've added a routine to report memory usage for each task and for the total managed help.
Note that the task list function has had sprintf patched out in favor of itoa() and ltoa(). I did this because I don't like the added overhead of sprintf.
One of the problems with the ATmega2560/1 series is that GCC uses a 16-bit word to keep track of location. Most of the time this is corrected in the loader, but jump tables and function pointers have trouble with the upper half of the flash memory. (Keep in mind that the AVR addresses instructions by a word pointer so you have direct access to 128 Kbytes of flash. That's exactly half of the total 256 KBytes in the ATmega2560/1).
Since I want to be sure that the task stack initialization is simple, I require that all user-defined task routines reside in lower flash memory. I do that by modifying the portTASK_FUNCTION_PROTO macro to put the task function into the .task linker section. The custom script linker_script.x contains the special section .task located before the main code section.
For the same reason, my command handler defines the following macro:
Code:
#define COMMAND_HANDLER __attribute__ ((section (".fptr_target")))
The .fptr_target section, like .task, is set up before the main code section. I use it in the prototypes of my command routines, like:
Code:
CmdError
CmdUnimplementedCommand( CmdPacket* pCmdPkt ) COMMAND_HANDLER;
/*---------------------------------------------------------------------------*\
Usage:
result = CmdUnimplementedCommand( pCmdPkt );
Description:
Default command procedure for unimplemented commands
Arguments:
pCmdPkt - pointer to the command packet for this command
Results:
CMD_ERROR_FUNCTION_NOT_IMPLEMENTED - always returns this!
\*---------------------------------------------------------------------------*/
The final bit of weirdness in linker_script.x is that I have another of these "pre-main code" sections, .isr, for ISRs. I am unconvinced that this is necessary since the JMP command can easily handle jumps to the top of memory, but I put it in a pique of anger once when an ISR wasn't working and I have never taken it out.
Nonetheless, inside of the projdefs.h file you will find:
Code:
/* The following defines the section for ISRs used throughout the code.
* This is added to the current ISR() macro as another called argument.
*/
#define ISR_SECTION __attribute__ ((section (".isr")))
This can be appended to the list of arguments in the ISR macro like this:
Code:
ISR( SIG_2WIRE_SERIAL, ISR_BLOCK ISR_SECTION )
(Yes, there is not a comma between ISR_BLOCK and ISR_SECTION. That's a weirdity of the way the ISR macro is defined.)
That's pretty much it. I currenlty have more than 70,000 lines of code and 9 tasks running on this. I regularly use queues, semaphores and task suspension without problems.
The problems that crop up regularly are:
1 - Insufficient stack space allocated to a task. Look for this if the machine "reboots" when you don't expect it. Use the task list function to get reports on how much stack your tasks are using. Keep in mind that ISRs can fire in any task, so if you have and ISR that uses lots of RAM (bad idea), make sure your minimumSTACK_SIZE is increased to handle it.
2 - Using a non-ISR function in an ISR. This will almost always lock up the machine.
At any rate, I hope this helps folks along. Enjoy!
Stu |
_________________
Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.
Newbie? Be sure to read the thread Newbie? Start here!
|
| |
|
|
|
|
|
|
Posted: Jan 31, 2009 - 09:48 AM |
|
Joined: Dec 22, 2005
Posts: 1275
Location: shiraz , iran
|
|
can you post a complete project with makefile.(making two dummy tasks)
and thanks in advance for posting this |
_________________
I love Digital
and you who involved in it!
|
| |
|
|
|
|
|
|
Posted: Sep 03, 2009 - 07:21 PM |
|
Joined: Sep 03, 2009
Posts: 9
|
|
| Sorry for being silly. Found the sources (was not logged in...) |
|
|
| |
|
|
|
|
|
|
Posted: Jun 14, 2010 - 07:16 PM |
|
Joined: Jun 14, 2010
Posts: 1
|
|
Hello,
I want to use freeRTOS in a Atmega1280 (The chip that is used by Arduino Mega)
What version o the code should i use? The code to 2560 or the Atmega323?
Many thanks |
|
|
| |
|
|
|
|
|
|
Posted: Jun 14, 2010 - 09:51 PM |
|
Joined: Jan 30, 2008
Posts: 168
Location: Wroclaw, Poland
|
|
Atmega 2560 gotchas:
You might be aware also that there was a problem when a C++ constructor
had to be called for a global static object in the region of upper flash (past 128KB).
The result was something strange, and the bug was corrected around late 2009 in gcc.
I am wondering what more problems we can find related to this 16-bit addressing. it hurts that 2560 is the only in line aith more than 128KB so that few users will have chance to witness the bugs before the application gets really big and complicated. |
|
|
| |
|
|
|
|
|
|
Posted: Jan 23, 2011 - 11:09 PM |
|
Joined: Aug 18, 2004
Posts: 64
Location: Mostar
|
|
Hi..
I had decided to work with FreeRTOS. I have found that new version is 6.11.
So I'm little confused: should I start with your now quite old version, or download fresh version from official site.
I have buyed I book "Using the FreeRTOS Real Time Kernel - A Practical Guide wp" to support author.
Could you please review this latest version and give us short description how to start using it, at least with mega2560 as you already do with 4.8.0.
Regards! |
|
|
| |
|
|
|
|
|
|
Posted: Oct 16, 2011 - 07:07 PM |
|
Joined: Aug 11, 2008
Posts: 6
|
|
You don't post AVR studio 5 project files. So how do compile using linker script you provided?  |
|
|
| |
|
|
|
|
|
|
Posted: Jan 15, 2012 - 10:53 PM |
|
Joined: Mar 16, 2010
Posts: 8
|
|
|
|
|
|
|
|
Posted: Jan 17, 2012 - 09:06 AM |
|
Joined: Jun 13, 2003
Posts: 17
|
|
|
|
|
|
|
|
Posted: May 03, 2012 - 09:45 AM |
|
Joined: May 03, 2012
Posts: 6
|
|
Hi,
I tried to compile the port from feilipu's side [url] http://feilipu.posterous.com/ethermega- ... d-freertos
but i always get the error : lib_fatf / cc932.c "This file is not needed in current configuration" line 23
I tried it 4 or 5 times, always the same error ! I followed all the steps on feilipu's tutorial. Can someone tell me where the problem is ?
Regards, Waldemar. |
|
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 09:59 AM |
|
Joined: Jul 18, 2005
Posts: 62922
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
an someone tell me where the problem is ?
Is the error message not telling you EXACTLY what the problem is? cc932.c contains code to support Japanese Long File Names. (Chan is Japanese after all!). When you configure FatFs you edit ffconf.h and change the line:
Code:
/*---------------------------------------------------------------------------/
/ Locale and Namespace Configurations
/----------------------------------------------------------------------------*/
#define _CODE_PAGE 1
/* The _CODE_PAGE specifies the OEM code page to be used on the target system.
/ Incorrect setting of the code page can cause a file open failure.
/
/ 932 - Japanese Shift-JIS (DBCS, OEM, Windows)
/ 936 - Simplified Chinese GBK (DBCS, OEM, Windows)
/ 949 - Korean (DBCS, OEM, Windows)
/ 950 - Traditional Chinese Big5 (DBCS, OEM, Windows)
/ 1250 - Central Europe (Windows)
/ 1251 - Cyrillic (Windows)
/ 1252 - Latin 1 (Windows)
/ 1253 - Greek (Windows)
/ 1254 - Turkish (Windows)
/ 1255 - Hebrew (Windows)
/ 1256 - Arabic (Windows)
/ 1257 - Baltic (Windows)
/ 1258 - Vietnam (OEM, Windows)
/ 437 - U.S. (OEM)
/ 720 - Arabic (OEM)
/ 737 - Greek (OEM)
/ 775 - Baltic (OEM)
/ 850 - Multilingual Latin 1 (OEM)
/ 858 - Multilingual Latin 1 + Euro (OEM)
/ 852 - Latin 2 (OEM)
/ 855 - Cyrillic (OEM)
/ 866 - Russian (OEM)
/ 857 - Turkish (OEM)
/ 862 - Hebrew (OEM)
/ 874 - Thai (OEM, Windows)
/ 1 - ASCII only (Valid for non LFN cfg.)
*/
Like me I bet you have that set to 1 saying you don't need/want foreign symbol support? When you then look in the cc932.c file you find:
Code:
#if !_USE_LFN || _CODE_PAGE != 932
#error This file is not needed in current configuration.
#endif
So it deliberately forces a compile time error if either you have not configured for LFNs or (if you have) if the code page is not set to 932. Well it isn't (see ffconf.h) so what this #error is telling you is "modify the list of files being passed to the compiler/linker to be built because cc932.c is no longer needed". (you'll be pleased to hear that this instantly reduces the size of FatFs by many KB!). |
_________________
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 10:46 AM |
|
Joined: May 03, 2012
Posts: 6
|
|
[quote]"modify the list of files being passed to the compiler/linker to be built because cc932.c is no longer needed"
sorry for beeing stupid, but the only tools i worked with is avr studio 4 and the arduino IDE, so i dont know how to say the linker that the file cc932.c is not needed
i dont even know what a linker is...  |
|
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 10:50 AM |
|
Joined: Jul 18, 2005
Posts: 62922
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
| In Studio there are a list of .c files in the project tree at the left. Just right click the cc932.c one and say "remove from project" (do NOT use the "delete" link - it really will delete the file from the disk!) |
_________________
|
| |
|
|
|
|
|
|
Posted: May 03, 2012 - 09:36 PM |
|
Joined: May 03, 2012
Posts: 6
|
|
1. thanks for your help
2. i tried to get it running with eclipse, but it doesnt work, eclipse gives me always some errors, can someone explain how to get this running with avr studio 4? I'm new to the whole thing, i have written some projects in C but never worked with external files and so on. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 06, 2013 - 12:03 AM |
|
Joined: Mar 05, 2013
Posts: 1
|
|
As Ghost09 I still ahve problems compiling it. I get problems in lib_serial
expected ‘;’, ‘,’ or ‘)’ before ‘uxTxQueueLength’ lib_serial.h /FreeRTOS730/freeRTOS730/include line 172 C/C++ Problem
expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘xSerialGetChar’ lib_serial.h /FreeRTOS730/freeRTOS730/include line 183 C/C++ Problem
expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘xSerialPutChar’ lib_serial.h /FreeRTOS730/freeRTOS730/include line 184 C/C++ Problem
are this problem related to mega2560 or not? |
|
|
| |
|
|
|
|
|
|
Posted: Mar 06, 2013 - 09:57 AM |
|
Joined: Jul 18, 2005
Posts: 62922
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Code:
expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before
9 times out of 10 that error is because you are using a type that the compiler does not know yet. Have a look at the lines mentioned and see if there's a non-standard C type being used. If so find where it is typedef'd and make sure an inclusion of the .h file where it is defined precedes the line where it is used. |
_________________
|
| |
|
|
|
|
|
|
Posted: Mar 09, 2013 - 11:34 AM |
|
Joined: Mar 16, 2010
Posts: 8
|
|
|
|
|
|
|
|
Posted: Mar 09, 2013 - 12:22 PM |
|
Joined: Jul 18, 2005
Posts: 62922
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
ust updated the ChaN FatF code to 0.9b today, for example.
Be warned that there's a bug in it. mmc.c has added a sector erase ioctl but it uses defines not in the header. |
_________________
|
| |
|
|
|
|
|
|
Posted: Mar 11, 2013 - 01:36 AM |
|
Joined: Mar 16, 2010
Posts: 8
|
|
I have been moving #defines around to manage quickly swapping between compiling on the Mega with XRAM and the Uno. To support a prototype for ArduSat XRAMFS.
http://feilipu.me/2013/02/17/ardusat-xramfs-prototyping/
So something might be in broken the example applications. But avrfreeRTOS and the libraries are not broken. In any case, I've just uploaded a new iteration. So let me know.
To the point from clawson, there is no mmc.c file in the code base, so I don't understand specific issue. Details, please?
And, please get a Goldilocks prototype Uno clone with 1284p with 16kByte RAM here:
http://pozible.com/project/18609
And help to grow our avr options for using Arduino Shields. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 11, 2013 - 09:27 AM |
|
Joined: Jul 18, 2005
Posts: 62922
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
To the point from clawson, there is no mmc.c file in the code base, so I don't understand specific issue. Details, please?
I guess you are using ff9b.zip rather than ffsample.zip then? The latter has implementation example files for ata, usb and mmc with mmc.h/mmc.c providing the SD/MMC code. That set of files has a bug. The readme in the former simply says:
Quote:
Low level disk I/O module is not included in this archive because the FatFs
module is only a generic file system layer and not depend on any specific
storage device. You have to provide a low level disk I/O module that written
to control your storage device.
If you just use the generic files then presumably to satisfy diskio.c you have provided your own implementations of MMC_disk_initalize(), MMC_disk_write() and so on? So I guess you won't suffer from the problem of using ChaN's own version of these. (having said that I'm not sure why anyone would not simply use Chan's own files from ffsample.zip?)
EDIT: OK I see it now. In your FreeRTOS730/lib_fatf/diskio.c you have replaced the generic code with your own implementation of read/write functions. The code there actually looks a lot like an old version of mmc.c in fact (but with different function names). Do you not worry that you will miss out on bug fixes (or, as in this case, introduced bugs!) in later issues of ChaN's mmc.c? |
_________________
|
| |
|
|
|
|
|
|
Posted: Mar 15, 2013 - 10:00 AM |
|
Joined: Mar 16, 2010
Posts: 8
|
|
I keep an eye on updated versions and diff each file before I replace it. Also I usually get a lot of alternative sources for functions before I actually build something. That way I can learn how other people with better skills have than me have done it before.
It is interesting to follow freertos line by line as it develops, I think.
Regards.
[edit: Please support: http://pozible.com/goldilocks Thanks] |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
