topic Re: FreeRTOS tips in LPCXpresso IDE

FreeRTOS tips

lpcware — Wed, 15 Jun 2016 21:53:50 GMT

Content originally posted in LPCWare by Rob65 on Thu Apr 21 09:54:36 MST 2011
I've just started using FreeRTOS on the lpc1343.
FreeRTOS is available from the LPCXpresso support on the NXP website for the 1100, 1300 and 1700 families giving us as very quick start at using an RTOS.

But as always, new software comes with new questions and problems that have to be solved. I've been mostly solving and testing the last two days and I think this is a good moment of sharing some information that may be usefull to others.
If you feel like it, add your own tips & tricks; spreading information spreads happiness

[B]Code halting in the hardfault_handler[/B]

After adding my own task I somehow always ended up with the debugger halting in the hardfault handler. This means that some code is trying to access an address that is not available to the CPU (e.g. reading from or writing to an unknown address).
The cause for this was that my tasks returned.
A tasks may never return to the system. The tasks runs in its own environment with its own stack, returning from the tasks returns to an unknown address. Always include a while(1) loop in your code - normally this is the part of the tasks where you process all the incoming events.

[B]Problems debugging: strange jumps in the source files[/B]With the current versions (< =3.6.2) a problem exists in the linker resulting in wrong debug information in the binary (.axf) file. the --gc-sections option that is used by the linker optimizes code size by removing certain sections but unfortunately this may impact debugging information needed.
Remove the --gc-sections from the linker options (in the C/C++ Build - Settings section of the project properties).

[B]Application does not run, no response from the application[/B]

After creating the tasks with xTaskCreate() and calling vTaskStartScheduler() nothing happens. Placing breakpoints in my tasks code shows that the tasks are never started and when I suspend debugging I return to the line with the vTaskStartScheduler() call.

In my case this was due to heap problems. The FreeRTOSConfig.h file contains a define for the heap size (configTOTAL_HEAP_SIZE). The heap is where all stacks, process information (TCBs), Queues and other stuff is stored.
In xTaskCreate() the stacksize is given in 32-bits words, configTOTAL_HEAP_SIZE is specified in bytes!!!
There are two options in the FreeRTOSConfig.h file that control stack and heap checking. enabling these will make your code bigger but it is a good thing to use (if possible).
You also have to add handlers to your own code to capture the errors. You might use:

#if (configCHECK_FOR_STACK_OVERFLOW > 0)
void vApplicationStackOverflowHook( xTaskHandle *pxTask, signed char *pcTaskName )
{
    volatile signed char *name;
    volatile xTaskHandle *pxT;

    name = pcTaskName;
    pxT  = pxTask;
    while(1);
}
#endif

#if (configUSE_MALLOC_FAILED_HOOK > 0)
void vApplicationMallocFailedHook(void)
{
    while(1);
}
#endif

Set both config.... defines above to 1 to enable checking.
If you want to know if you are still OK on heap space, suspend your debug session and check the variable xFreeBytesRemaining in heap_2.c (part of FreeRTOS_Library/portable, on line 103 in the FreeRTOS 6.1.0 sample code).

If you suspend debugging and end up in one of the hooks in the code above you either ran out of stack or heap.

[B]Using printf() to check where your code is going.[/B]

The book "Using the FreeRTOS Real Time Kernel NXP lpc17xx edition" (of which a sneak preview is available here at the NXP website) mentions printf-stdarg.c. This optimized version is not in the sample code on the NXP website but is is available in the complete download at freertos.org (in the 7.0.0 version it is in FreeRTOS/Demo/CORTEX_LPC1768_GCC_RedSuite/src).
If you want to print out multiple lines of information it might be usefull to use a mutex to guard printing, just to make sure that the text stays readable.

Please note that semi hosting console output is slow, very slow, and that may (will) impact your code. do not use semi hosting but a real UART (I am using the I2C to Uart controller on the base board from Embedded Artists for this).

That's all for now - more to follow.

Rob

Re: FreeRTOS tips

lpcware — Wed, 15 Jun 2016 21:53:51 GMT

Content originally posted in LPCWare by rmteo on Thu Apr 21 10:01:39 MST 2011
What size footprint (FLASH & RAM) are you seeing for typical apps?

Re: FreeRTOS tips

lpcware — Wed, 15 Jun 2016 21:53:52 GMT

Content originally posted in LPCWare by jharwood on Thu Apr 21 10:31:25 MST 2011

Quote: rmteo
What size footprint (FLASH & RAM) are you seeing for typical apps?

My 1769 is currently running lwIP and a telnet server with a limit of 4 active sessions. SNMP is included along with a private MIB. There's also DNS, Syslog and SNTP.

Flash is around 90k (release build).

Ethernet MAC buffers are in the upper 16k AHB RAM bank
FreeRTOS heap is located in the lower 16k AHB RAM bank

SRAM is at about 28k by tweaking the lwIP config. Main stack uses 768 bytes, so there's about 3.5k left for the C run time heap.

Re: FreeRTOS tips

lpcware — Wed, 15 Jun 2016 21:53:52 GMT

Content originally posted in LPCWare by rmteo on Thu Apr 21 11:46:23 MST 2011
Thanks for the info. I would also be interested in size info for the more typical multi-tasking control type applications - and the minimum footprint required by FreeRTOS.

Re: FreeRTOS tips

lpcware — Wed, 15 Jun 2016 21:53:53 GMT

Content originally posted in LPCWare by martinho on Thu Apr 21 23:02:39 MST 2011
In My application (LPC1752) the FreeRTOS library is using this space:

make --no-print-directory post-build
Performing post-build steps
arm-none-eabi-size libFreeRTOS_Library.a ; # arm-none-eabi-objdump -h -S libFreeRTOS_Library.a >libFreeRTOS_Library.lss
   text    data     bss     dec     hex filename
    156       0       0     156      9c list.o (ex libFreeRTOS_Library.a)
   1436       0       0    1436     59cqueue.o (ex libFreeRTOS_Library.a)
   2852       8     280    3140    c44tasks.o (ex libFreeRTOS_Library.a)
      0       0       0       0      0timers.o (ex libFreeRTOS_Library.a)
    292       4    8216    8512    2140 heap_2.o (ex libFreeRTOS_Library.a)
    340       4       0     344     158 port.o (ex libFreeRTOS_Library.a)

I'm using most of the kernel functions so probably You can reduce size further if You do not use all of them. The bss of heap_2.o is the memory pool used by the kernel / tasks (size depends on your memory need)

P.S. I'm using the latest version (V7.0.0) for this reason you see the timers.o file that was added in this version.

Martin

Re: FreeRTOS tips

lpcware — Wed, 15 Jun 2016 21:53:54 GMT

Content originally posted in LPCWare by Rob65 on Fri Apr 22 00:02:21 MST 2011
[B]How to know (and study) the memory footprint[/B]

This is not FreeRTOS specific but there is some info on footprint at the beginning and the end with FreeRTOS specific info.

Code size is important,an lpc1343 has 'only' 23kBytes of Flash that can be used to store your program. Data size may be even more important since there is only 8 kByte of RAM available.
But how to know the amount of memory used?

The easy way is to check the output of the build.
The standard SimpleDemo application (all on the lpc1343) will show the following output in the console window:

Building target: SimpleDemo.axf
Invoking: MCU Linker
arm-none-eabi-gcc -nostdlib -L"C:\Users\Rob\Documents\lpcxpresso_3.6\workspace\FreeRTOS_Library\Debug" -L"C:\Users\Rob\Documents\lpcxpresso_3.6\workspace\CMSISv1p30_LPC13xx\Debug" -Xlinker -Map=SimpleDemo.map -Xlinker --gc-sections -mcpu=cortex-m3 -mthumb -T "SimpleDemo_Debug.ld" -o"SimpleDemo.axf"  ./cr_startup_lpc13.o ./main.o   -lFreeRTOS_Library -lCMSISv1p30_LPC13xx
Finished building target: SimpleDemo.axf
 
make --no-print-directory post-build
Performing post-build steps
arm-none-eabi-size SimpleDemo.axf; # arm-none-eabi-objcopy -O ihex SimpleDemo.axf SimpleDemo.hex ;
   text       data        bss        dec        hex    filename
   7808        532       2344      10684       29bc    SimpleDemo.axf

This shows us a successful build. Text + data means program code (Flash), so that is 8340 bytes, and data + bss tells you how much RAM is needed.
Data is pre initialized data (this data has a value at program start), bss is the so called 'blanked storage space' and this is un-initialized data (the cr_startup_lpc13.c startup code will clear this part of memory).

If you use too much RAM you might see something like this:

Building target: SimpleDemo.axf
Invoking: MCU Linker
arm-none-eabi-gcc -nostdlib -L"C:\Users\Rob\Documents\lpcxpresso_3.6\workspace\FreeRTOS_Library\Debug" -L"C:\Users\Rob\Documents\lpcxpresso_3.6\workspace\CMSISv1p30_LPC13xx\Debug" -Xlinker -Map=SimpleDemo.map -Xlinker --gc-sections -mcpu=cortex-m3 -mthumb -T "SimpleDemo_Debug.ld" -o"SimpleDemo.axf"  ./cr_startup_lpc13.o ./main.o   -lFreeRTOS_Library -lCMSISv1p30_LPC13xx
c:/nxp/lpcxpresso_3.6/tools/bin/../lib/gcc/arm-none-eabi/4.3.3/../../../../arm-none-eabi/bin/ld.exe: SimpleDemo.axf section .bss will not fit in region RamLoc8
c:/nxp/lpcxpresso_3.6/tools/bin/../lib/gcc/arm-none-eabi/4.3.3/../../../../arm-none-eabi/bin/ld.exe: region RamLoc8 overflowed by 832 bytes
collect2: ld returned 1 exit status
make: *** [SimpleDemo.axf] Error 1

Scroll a bit to the right and you see that there is too much data to fin in the RAM (region RamLoc8 is the 8 kB RAM) . 832 bytes too big.

To determine what part of the code/data is taking up which amount of memory you have to look at the MAP file. It's in your workspace/SimpleDemo/Debug directory and is called SimpleDemo.map.

You have to scroll through the file a bit to find the pieces of text you need. Scrolling through the file you will see that suddenly there are 32-bit hex numbers with some text that you might recognize as file or function names. This continues until there are a lot of lines starting with ".debug_".
Here is, part of, such a section:

.text          0x00000344      0x4e8 C:\Users\Rob\Documents\lpcxpresso_3.6\workspace\FreeRTOS_Library\Debug\libFreeRTOS_Library.a(queue.o)
                0x0000060c                xQueueGenericSendFromISR
                0x000007a0                xQueueCreate
                0x00000364                vQueueDelete
                0x00000668                xQueueGenericSend
                0x000003b4                xQueueReceiveFromISR
                0x00000814                xQueueCreateCountingSemaphore
                0x00000354                xQueueIsQueueFullFromISR
                0x00000378                uxQueueMessagesWaiting
                0x00000488                xQueueGenericReceive
                0x00000344                uxQueueMessagesWaitingFromISR
                0x00000348                xQueueIsQueueEmptyFromISR
                0x00000754                xQueueCreateMutex
 .text          0x0000082c      0xc64 C:\Users\Rob\Documents\lpcxpresso_3.6\workspace\FreeRTOS_Library\Debug\libFreeRTOS_Library.a(tasks.o)

[LIST]
[*].text 0x00000344 0x4e8 C:\Users\Rob\.....
Shows the start of a text segment (program code) with a length of 0x4e8 bytes (1.2 kB) and the filename.
[*]0x00000348 xQueueIsQueueEmptyFromISR
tells us that the function xQueueIsQueueEmptyFromISR starts at address 0x0348
[*].text 0x0000082c 0xc64 C:\....
is where the next section (in this case the next file) starts.
[/LIST]
You can import the projects and compile the example yourself to see the complete file. Please do so, change some settings in the FreeRTOSConfig.h to see what happens with your code and data size.

The standard application uses:

[LIST]
[*]472 bytes of startup code
[*]364 bytes for main.o (the program with the two tasks)
[*]5276 bytes for FreeRTOS
[*]1692 bytes for the CMS and other libraries used
[*]8 bytes of read only data (.rodata section)
[/LIST]

The one more thing I like to show is the data section (RAM) where you'll see the memory overflow:

.data           0x10000000      0x214 load address 0x00001e8c
 FILL mask 0xff
                0x10000000                _data = .
 *(vtable)
 *(.data*)
 .data          0x10000000        0x4 ./main.o
 .data          0x10000004        0x4 C:\Users\Rob\Documents\lpcxpresso_3.6\workspace\FreeRTOS_Library\Debug\libFreeRTOS_Library.a(heap_2.o)
 .data          0x10000008        0x4 C:\Users\Rob\Documents\lpcxpresso_3.6\workspace\FreeRTOS_Library\Debug\libFreeRTOS_Library.a(port.o)
 .data          0x1000000c        0x4 C:\Users\Rob\Documents\lpcxpresso_3.6\workspace\CMSISv1p30_LPC13xx\Debug\libCMSISv1p30_LPC13xx.a(system_LPC13xx.o)
                0x1000000c                SystemCoreClock
 .data          0x10000010      0x204 c:/nxp/lpcxpresso_3.6/tools/bin/../lib/gcc/arm-none-eabi/4.3.3/../../../../arm-none-eabi/lib/thumb2\libcr_c.a(ctype.o)
                0x10000010                __ctype
                0x10000214                . = ALIGN (0x4)
                0x10000214                _edata = .

.bss            0x10000218     0x2128 load address 0x000020a0
                0x10000218                _bss = .
 *(.bss*)
 .bss           0x10000218        0x4 ./main.o
 .bss           0x1000021c      0x100 C:\Users\Rob\Documents\lpcxpresso_3.6\workspace\FreeRTOS_Library\Debug\libFreeRTOS_Library.a(tasks.o)
                0x100002bc                pxCurrentTCB
 *fill*         0x1000031c        0x4 00
 .bss           0x10000320     0x2018 C:\Users\Rob\Documents\lpcxpresso_3.6\workspace\FreeRTOS_Library\Debug\libFreeRTOS_Library.a(heap_2.o)
 *(COMMON)
 COMMON         0x10002338        0x8 c:/nxp/lpcxpresso_3.6/tools/bin/../lib/gcc/arm-none-eabi/4.3.3/../../../../arm-none-eabi/lib/thumb2\libcr_c.a(__init_alloc.o)
                0x10002338                __heaps
                0x1000233c                __end_of_heap
                0x10002340                . = ALIGN (0x4)
                0x10002340                _ebss = .
                0x10002340                PROVIDE (end, .)

The first line shows the section of the initialized data; 0x214 bytes (532 decimal) are stored in Flash, these are copied to RAM during startup.
Looking a bit further you'll see that heap_2.o uses 0x2018 bytes of RAM (remember: 8 kBytes is 0x2000 !).

This all gives you some pointers of what to look for when looking at code size.

As a nice 'homework' assignment, let's add a string to the main.c file and see what happens with your flash and ram sizes.
Use both ways to add a string, compile both and compare the .map files:

[LIST=1]
[*]char *str = "This is just a plain string I like to use for printing";
[*]char str[] = "This is just a plain string I like to use for printing";
[/LIST]
Look what happens to the size of your .data section. You will see that the first line (containing the 0x214 load address 0x00001e8c) has an increased size, but have a look at the .data section for main.o. One variant uses more memory than the other...

My current application (still under development) is, I think, a typical embedded application for a small device has the following footprint:

   text       data        bss        dec        hex    filename
  20364        548       5596      26508       678c    SimpleDemo.axf

This is a small board computer with an interface to 3 wireless sensors, 4 PWM controllers, and LCD and some buttons. Software is still simple, most of the code is the framework to handle all the events.

Re: FreeRTOS tips

lpcware — Wed, 15 Jun 2016 21:53:55 GMT

Content originally posted in LPCWare by rmteo on Fri Apr 22 07:50:27 MST 2011
Thank you very much for the size info guys. I am particularly interested in small footprint RTOSes that can run in the smallest ARM Cortex micros such as the LPC1111 which has only 8K Flash and 2K RAM.

The commercial RTOSes I am looking at are Avix-RT, Q-Kernel (not yet for ARM, only PIC32) and emBOS. All 3 are pre-emptive (and claim to be hard real time) and optionally co-operative. The free ones that I looked at are ChibiOS and CooOS but not FreeRTOS which is why I asked for the size info. It appears that they are all fairly similar in their memory requirements for typical applications - starting at about 15-25K Flash and several kBytes of RAM depending upon number of tasks and task stack sizes. The exception to these numbers is emBOS which needs as little as <2K flash for a minimum configuration.

Another interesting option is the Tasking Library that is an integral part of the CrossWorks (supports ARM7, ARM9, XScale and Cortex-M0/3/4) development system for ARM. It is a royalty-free library that provides a multi-priority, pre-emptive, task switching and synchronisation facility. Additionally, the library can also provide timer and interrupt handling support. Its memory requirements are small - similar to that of emBOS.

As for a purely co-operative RTOS, I have pretty much settled on Salvo. Without going into the pros and cons of co-operative vs. pre-emptive, there are situations where I feel one would be more apprpriate over the other. The interesting thing about a co-operative one such as Salvo is that you can do a multitasking app with 5-6 tasks (including things like soft RS232) in 1K Flash and <50 bytes RAM on an 8-bit MCU (obviously more on a 32-bit Cortex, I am seeing <2x).

BTW, all 3 commercial pre-emptive RTOSes are about US$5-6K for a royalty free source code license and Salvo is US$1.5K - CrossWorks is US$1.5K for the development system that includes the tasking library.

Re: FreeRTOS tips

lpcware — Wed, 15 Jun 2016 21:53:55 GMT

Content originally posted in LPCWare by on Fri Apr 22 11:09:48 MST 2011
Hi guys,

I came to this thread a bit late, but will add a few comments of my own, replying to many posts at once, although it looks like the OP pretty much has everything covered anyway.

Quote:
After adding my own task I somehow always ended up with the debugger halting in the hardfault handler. This means that some code is trying to access an address that is not available to the CPU (e.g. reading from or writing to an unknown address).
The cause for this was that my tasks returned.
A tasks may never return to the system

That is correct. Never let a task run off the end of the function that implements it. If you want a task to run once, then simply add a vTaskDelete( NULL ); call to the end of the task, and it will delete itself rather than running off the end of the function.

Better still, if you are using FreeRTOS V7, then instead of using a task at all, use a one shot timer.

Quote:
In my case this was due to heap problems. The FreeRTOSConfig.h file contains a define for the heap size (configTOTAL_HEAP_SIZE). The heap is where all stacks, process information (TCBs), Queues and other stuff is stored.
In xTaskCreate() the stacksize is given in 32-bits words, configTOTAL_HEAP_SIZE is specified in bytes!!!

As is documented.

Quote:
There are two options in the FreeRTOSConfig.h file that control stack and heap checking. enabling these will make your code bigger but it is a good thing to use (if possible).
You also have to add handlers to your own code to capture the errors. You might use:

Absolutely - it is always good practice to use these during debugging, even if you then take them out when everything is stable. The latest FreeRTOS versions also have some configASSERTS() laced through the code to assist even more. configASSERT() has the same functionality as the standard C assert(), but the standard C assert() is not used as not all the many many compilers supported by FreeRTOS include an assert.h implementation.

Quote:
Thanks for the info. I would also be interested in size info for the more typical multi-tasking control type applications - and the minimum footprint required by FreeRTOS.

With respect to FreeRTOS - see here:
http://www.freertos.org/FAQMem.html

Quote:
Thank you very much for the size info guys. I am particularly interested in small footprint RTOSes that can run in the smallest ARM Cortex micros such as the LPC1111 which has only 8K Flash and 2K RAM.

With a pre-emptive system, you really have to consider how much RAM is used by task stacks, not how much is used by the kernel (as the kernel will only use a few bytes, and a stack has to be as big as a stack has to be).

On a device such as the Cortex-M3 the stack handling is pretty much done automatically by the hardware. Interrupt use a separate stack without any intervention from the kernel. This is unlike something like, for example, a MIPS core where the kernel has to manage stack switching to prevent a fully nested worth of interrupt stacks having to be allocated to each task.

2K of RAM is always going to be a small amount for a preemptive kernel, because of the required task stacks. How much stack is required depends on the libraries being used as much as anything else.

Just for the record, FreeRTOS has preemptive, co-operative options, as well as software timers for run to completion and co-routines for ultra tiny co-operative multasking (with a lot of restrictions). The latter two all share a stack between timers and/or co-routines, so require much less RAM.

Thanks for the plug to the LPC17xx version of the FreeRTOS tutorial book - whoever that was ;o)

Regards.

Re: FreeRTOS tips

lpcware — Wed, 15 Jun 2016 21:53:56 GMT

Content originally posted in LPCWare by rmteo on Fri Apr 22 14:42:55 MST 2011
Thanks for the info, Richard.

Re: FreeRTOS tips

lpcware — Wed, 15 Jun 2016 21:53:57 GMT

Content originally posted in LPCWare by Rob65 on Fri Apr 22 23:26:31 MST 2011
A Release build of SimpleDemo with all optimizations set to -O3 and --gc-sections shows:

SimpleDemo.bin ; checksum -p LPC1343 -d SimpleDemo.bin;
   text       data        bss        dec        hex    filename
   5220        532       2340       8092       1f9c    SimpleDemo.axf

On this system the debug version (with optimization -O0 and --gc-sections) I see the following:

SimpleDemo.bin ; checksum -p LPC1343 -d SimpleDemo.bin;
   text       data        bss        dec        hex    filename
   8684        532       2336      11552       2d20    SimpleDemo.axf

Removing the --gc-sections option from the linker (which I needed in order to be able to properly debug my application) results in the following figures:

Release:

SimpleDemo.bin ; checksum -p LPC1343 -d SimpleDemo.bin;
   text       data        bss        dec        hex    filename
   6744        532       2340       9616       2590    SimpleDemo.axf

Debug:

SimpleDemo.bin ; checksum -p LPC1343 -d SimpleDemo.bin;
   text       data        bss        dec        hex    filename
  11428        532       2336      14296       37d8    SimpleDemo.axf

This shows that compiler and linker options are important when comparing code size.
Looking at FreeRTOS this still does not tel you enough. One needs to provide the exact config settings during compilation of library and application. I expect FreeRTOS to be customizable the same way I am used from uC-OS II meaning that there is a lot to tweak in the library and your application. (I know I will have to do a lot of tweaking to get everything to fit in a 1343 ...

Re: FreeRTOS tips

lpcware — Wed, 15 Jun 2016 21:53:57 GMT

Content originally posted in LPCWare by Rob65 on Fri Apr 22 23:59:26 MST 2011
[B]Timing your programs[/B]

FreeRTOS uses the systick block to generate its tick interrupt.
The systick block is a simple timer that runs at the CPU's clock frequency and counts down at every clock pulse, when it reaches zero an interrupt is generated and the timer reloads a value from the reload value register.
The interrupt is handled by FreeRTOS to keep track of the number of ticks.

We can use this timer combined with the FreeRTOS TickCount to do some timing of our own programs. If you include the following code in your code:

            uint32_t old_tickcount, old_subtick, new_tickcount, new_subtick, reload;

            old_tickcount = xTaskGetTickCount();
            old_subtick = *((volatile unsigned long *) 0xe000e018);
            .
            . some code
            .
            new_tickcount = xTaskGetTickCount();
            new_subtick = *((volatile unsigned long *) 0xe000e018);
            reload = *((volatile unsigned long *) 0xe000e014);

you can quickly measure how much time was spent in that code.
I placed the first lines of code just before an xQueueSend() and the second part just after the xQueueReceive to measure how long it takes before the message is processed. This time will depend of the tasks priorities and other things running in your system.

In my case the tickcounts are both the same, new_subtick is 54392, old_subtick is 57272 and reload is 71999.
FreeRTOS is configured with a 1000 Hz tick interrupt and the CPU clock frequency is 72 MHz (this is all configurable). The reload values 71999 makes sure the systick counts 72000 clock pulses between two interrupts so this matches perfectly.

Note that the new tickcount is lower than the old one: the timer counts down to 0.
Between two times loading the value the program spent 57272 - 54392 = 2880 clock pulses / (reload+1) = 0.040 (milli seconds since we run at 1000 Hz tick).

I just placed a breakpoint after the code, you could also calculate the time and store it (or store the max measured).

Re: FreeRTOS tips

lpcware — Wed, 15 Jun 2016 21:53:58 GMT

Content originally posted in LPCWare by apighin on Wed Jan 04 09:45:48 MST 2012
If code and data memory footprint is paramount in your design, you may want to look at this RTOS: http://www.code-time.com/products.html

It is fully scalable and preemptive, and the base size for the Cortex-M3 is about 800 bytes (ROM). Even the maximum configuration is stated as less than 3KB (ROM), and that includes things like round-robin, etc. I am sure you'd best the embOS numbers by quite a bit.

Re: FreeRTOS tips

lpcware — Wed, 15 Jun 2016 21:53:59 GMT

Content originally posted in LPCWare by toddatm on Thu Jan 05 12:54:01 MST 2012

Quote: Rob65
[B]Timing your programs[/B]
...
Note that the new tickcount is lower than the old one: the timer counts down to 0.
Between two times loading the value the program spent 57272 - 54392 = 2880 clock pulses / (reload+1) = 0.040 (milli seconds since we run at 1000 Hz tick).

Isn't there some probability you will grab a first value just before it reloads and a second value after it reloads? In that case the second value will be larger than the first?

Re: FreeRTOS tips

lpcware — Wed, 15 Jun 2016 21:53:59 GMT

Content originally posted in LPCWare by Rob65 on Thu Jan 05 13:17:28 MST 2012

Quote: toddatm
Isn't there some probability you will grab a first value just before it reloads and a second value after it reloads? In that case the second value will be larger than the first?

Yes there is.
If the section of the code you time takes more than 1 msec then you need to check the tickcount also.
And there is always a chance the tick interrupt fired just in between reading the Tickcounter's value register and reading FreeRTOSes tickcount.

If you want this to be real safe, combinethe instructions in one function and disable interrupt while in there.
Still, this most of the times just works.

Rob

Re: FreeRTOS tips

lpcware — Wed, 15 Jun 2016 21:54:00 GMT

Content originally posted in LPCWare by csuttner on Mon Dec 17 11:11:31 MST 2012

Quote: jharwood
My 1769 is currently running lwIP and a telnet server with a limit of 4 active sessions. SNMP is included along with a private MIB. There's also DNS, Syslog and SNTP.

Hello jharwood,
I'm having trouble setting up a telnet server on the lpc1769. I use the EasyWeb TCP/IP Stack but the functions it contains are on a very low level. Since you have already got it working I would appreciate it if you coul post your solution.

Best Regards
Chris

Re: FreeRTOS tips

lpcware — Wed, 15 Jun 2016 21:54:01 GMT

Content originally posted in LPCWare by csuttner on Mon Dec 17 11:15:09 MST 2012

Quote: jharwood
My 1769 is currently running lwIP and a telnet server with a limit of 4 active sessions. SNMP is included along with a private MIB. There's also DNS, Syslog and SNTP.

Flash is around 90k (release build).

Ethernet MAC buffers are in the upper 16k AHB RAM bank
FreeRTOS heap is located in the lower 16k AHB RAM bank

SRAM is at about 28k by tweaking the lwIP config. Main stack uses 768 bytes, so there's about 3.5k left for the C run time heap.

Quote: jharwood
My 1769 is currently running lwIP and a telnet server with a limit of 4 active sessions. SNMP is included along with a private MIB. There's also DNS, Syslog and SNTP.

Re: FreeRTOS tips

lpcware — Wed, 15 Jun 2016 21:54:01 GMT

Content originally posted in LPCWare by Rob65 on Mon Dec 17 11:49:24 MST 2012

Quote: csuttner
Hello jharwood,
I'm having trouble setting up a telnet server on the lpc1769.

this topic is about FreeRTOS tips, the lwIP program was just uzed as an example to demonstrate FreeRTOS.
Please open a new topic to address your telnet problems and keep this thread clean, otherwise things are very hard to follow.

Rob

Re: FreeRTOS tips

lpcware — Wed, 15 Jun 2016 21:54:02 GMT

Content originally posted in LPCWare by Giri Sparrow on Tue Feb 03 05:02:59 MST 2015
i need to clarify following things.

We are going to interface a GPS and a GSM module to lpc82x controller.And we need to Get the GPS data from the GPS module and send it to our server using GSM modem. Will 32KB Flash memory and 8KB RAM will be sufficient for this purpose ?

Or Should I have to go for Any other controllers with higher memory configuration ?

Regards, R.Giritharan