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

Submission format for graphics and documentation upgrades =?

Posted by e-christenson on August 9, 2015

Dear freeRTOS As part of my project, I am starting to draw some pictures to help understand how freeRTOS uses memory and stack -- because I need to prove, on my limited-resource dsPIC CPU, that my relatively simple (5 task) project isn't going to blow (run out of space on ) the stack or the heap. Simply running the project without observing a failure isn't really acceptable.

I can't believe that mine is the only project that requires such diligence.

At the moment, these are messy pen-and-ink drawings that I intend to re-draw on the computer for digital reproduction as part of the project documentation. What is the best format for such files if I plan on submitting some of them for publication to the project?


Submission format for graphics and documentation upgrades =?

Posted by heinbali01 on August 9, 2015

Hi Christenson,

I can't believe that mine is the only project that requires such diligence.

Sure, every embedded programmer faces this complex problem :-)

On the side of FreeRTOS things are relatively simple: the kernel and API's have a low and predictable usage of stack and heap. We programmers decide how much of the heap will be allocated by the API's.

Things get more complex if you use things like TCP/IP, or if you have 'users' giving variable input and commands.

To simplify things, use a fixed (or at least a predictable) number of tasks.

To save stack space, look if several tasks can be combined. Often this requires the use of so-called status machines, each one handling a sub-task.

Some people say: observe the maximum needs of an application and multiply it by two (if you have that available). I'm sure you have found these functions:

size_t xPortGetFreeHeapSize( void );
size_t xPortGetMinimumEverFreeHeapSize( void );
UBaseType_t uxTaskGetStackHighWaterMark( TaskHandle_t xTask ) PRIVILEGED_FUNCTION;

or this one:

UBaseType_t uxTaskGetSystemState(
    TaskStatus_t * const pxTaskStatusArray,
	const UBaseType_t uxArraySize,
	uint32_t * const pulTotalRunTime );

What is the best format for such files

Whatever is comfortable for you: BMP, PNG, JPEG, or even a document is OK. You can put them here as an attachment.

Regards.


Submission format for graphics and documentation upgrades =?

Posted by e-christenson on August 9, 2015

Am I supposed to report typographic-level problems I catch -- for example: freeRTOS 8.2.1 tasks.c has a number of comments that don't quite make sense...such as the following fragment

if ( INCLUDE_uxTaskPriorityGet == 1 )
UBaseType_t uxTaskPriorityGet( TaskHandle_t xTask )
{
TCB_t *pxTCB;
UBaseType_t uxReturn;

	taskENTER_CRITICAL();
	{
		/* If null is passed in here then we are changing the
		priority of the calling function. */
		pxTCB = prvGetTCBFromHandle( xTask );
		uxReturn = pxTCB->uxPriority;
	}
	taskEXIT_CRITICAL();

	return uxReturn;
}
endif /* INCLUDE_uxTaskPriorityGet */

Clearly, the comment at the beginning of the critical section is copy/pasted in from uxTaskPrioritySet.....and someone forgot to change the wording.

P.S. My question was NOT "what to do about the problem itself?"(I am in the middle of working that out, and have noted those functions), it was "how do I best help others with the problem?".

I have MPLAB real ICE, so for my situation, the emulator/debugger can also be used to get answers.


Submission format for graphics and documentation upgrades =?

Posted by rtel on August 9, 2015

Thanks for taking the time to point out the error in the comments - it is appreciated and nice and quick and easy to fix. If you find any more then please post them here too.

Regards.


Submission format for graphics and documentation upgrades =?

Posted by e-christenson on August 9, 2015

It looks like there's a fair number of typos hanging around. I hope you don't mind me trying to stomp on them. Please understand that these aren't at all on any kind of urgent priority level for me, I just think I'm a good spotter because I am reading and auditing stuff for my project. The typo monster bites me, too! Lol

So here's another:

https://sourceforge.net/p/freertos/wiki/Home/

(from the second paragraph of the body text)

FreeRTOS is professionally developed, strictly quality controlled, robust, supported, and free to use even in commercial applications, with no requirement to expose propitiatory (proprietary) source code.


Submission format for graphics and documentation upgrades =?

Posted by rtel on August 9, 2015

Don't mind at all, in fact quite the opposite, it would be nice if more people took the time. I will fix any you highlight. Regards.


Submission format for graphics and documentation upgrades =?

Posted by rtel on August 10, 2015

Both typos have been fixed. The source code comment edit won't be visible until the next release.


Submission format for graphics and documentation upgrades =?

Posted by e-christenson on August 11, 2015

When is the next release?


Submission format for graphics and documentation upgrades =?

Posted by rtel on August 11, 2015

The version number has aleady been up-issued in the public SVN repository (in SourceForge) but the .zip file has not been uploaded yet. We are hanging back slightly to allow additional FreeRTOS+Trace testing (by Percepio) and it might be that, following the other thread, some PIC32/dsPIC changes will be made too. The .zip file will have to be uploaded asap though is it might be that the code doesn't change from that already in SVN.


Submission format for graphics and documentation upgrades =?

Posted by e-christenson on August 12, 2015

A different problem (commissioning a rather large DC drive with some new design features and an 8051 core) is now in my lap, and I am still working on hardware checkout on my 30F5013 board. In addition, I've already patched my copy of freeRTOS with my preferred solution, so I'm in good shape as far as freeRTOS goes. A little cybersecurity form my boss dropped in my lap also helped today.

Finally, I caught this one not because it happened to me, but because I read thee errata, had to fix my own code, and thought it a good idea to audit freeRTOS to see if it had the same problem.


[ 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