ROS for lpcXpresso

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lukkezeh on Wed Feb 03 16:46:02 MST 2010
Hello all,

I am looking for a real time operating system wich i can run on my lpcXpresso. Does someone know wich one i could use?

thanks,

lpcware · ‎06-15-2016

Content originally posted in LPCWare by on Mon Aug 16 07:15:59 MST 2010
The FreeRTOS LPC11xx ports are not official ports [yet] so not officially supported, but there do seem to be quite a lot of people using them. Your problem might not be related to the port as such, but some other usage issue. You might try your luck on the FreeRTOS support forum where this port has been discussed before: http://sourceforge.net/projects/freertos/forums/forum/382005

There are also a couple of other unofficial ports here http://interactive.freertos.org/forums/104360-nxp , but please do not use this forum for technical support questions.

Regards,
Richard.

http://www.FreeRTOS.org
Designed for microcontrollers.
77,500 Downloads during 2009.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Szaflik on Sun Aug 15 10:07:06 MST 2010
Hello,

I've got lpcxpresso with lpc1114.
Anyone tried to use:

[LIST]
[*]FreeRTOS Example V1.0 (Jul 14, 2010) [IMG]http://ics.nxp.com/images/pd-new.gif[/IMG] ??
[/LIST]
After some time of good working (task switching, queues etc) I've got [B]"HardFault_Handler[/B]" and aplication is stoping.
(HardFault_Handler occur after vTaskStartScheduler() even if there are no task etc.)

I was trying to increase heap memory etc.
On LPC2368 the same code works fine.
Is this FreeRTOS port correct in 100% ?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Stanislaus on Fri May 28 11:13:00 MST 2010
Hi Gerrit,
thanks for the sources. Great. :-)
I tried your port and it work perfectly at the debug mode. But at Release Mode it dont's seams to work. Is yours working? Thanks again. Stan

lpcware · ‎06-15-2016

Content originally posted in LPCWare by brucesegal on Tue Apr 13 17:37:01 MST 2010

Quote: rmteo
Thanks for the info. I tested it the LPC1114/301 port of CoOS but could not locate the following files:

#include "debug.h"
#include "gpio.h"
#include "uart.h"
#include "CoOs.h"

CoOS.h is located in the kernel folder in the Coos download. Make sure to edit the OsConfig.h file in the same folder for the correct CFG_CPU_TYPE

debug.h is my own. Delete that line, line 35 (the __assertion_failed definition) and line 85 (the ASSERT(1==0) ) These are a test for runtime assertions.

gpio.h and uart.h should be in the examples provided with the LPCXpresso ide. I might have modified them a bit from whatever was supplied. I'm sure you can figure out what to do just by looking at the code.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by rmteo on Tue Apr 13 09:44:52 MST 2010
Thanks for the info. I tested it the LPC1114/301 port of CoOS but could not locate the following files:

#include "debug.h"
#include "gpio.h"
#include "uart.h"
#include "CoOs.h"

lpcware · ‎06-15-2016

Content originally posted in LPCWare by brucesegal on Sun Apr 11 20:01:57 MST 2010

Quote: rmteo
Can you give details on how you got it running. Thanks.

I can't really remember the specifics.

From memory I believe that what I did was...
1.Create a new C project, Static library,setting MCU as LPC1114/301.
2.Import the CoOS files into this project.
3. Create another project where your main program will be with settings to include the folders from step 2.

Sorry I can't be more detailed but it just seemed to work.

Here's the main.c test code. It blinks some LEDS on the LPCXpresso Baseboard. I have been playing with it so it may not run any longer, but the structure is the same.

/*
===============================================================================
 Name        : main.c
 Author      : 
 Version     :
 Copyright   : (C) Copyright
 Description : main definition
===============================================================================
*/

#ifdef __USE_CMSIS
#include "LPC11xx.h"
#endif

#include "debug.h"
#include "gpio.h"
#include "uart.h"
#include "CoOs.h"

#define LED_PORT0
#defineLED_BIT7


enum {RED_PORT=1, BLUE_PORT=1, GREEN_PORT=1};
enum {RED_BIT=9, BLUE_BIT=2, GREEN_BIT=10};
enum{PRIORITY_BLINK_TASK0=2, PRIORITY_BLINK_TASK1=3, PRIORITY_RECIEVE=2};    
enum{SIZE_BLINK_TASK0=100, SIZE_BLINK_TASK1=100, SIZE_RECEIVE=100};
 
OS_STK stkBlink0[SIZE_BLINK_TASK0];
OS_STK stkBlink1[SIZE_BLINK_TASK1]; 
OS_STK stkReceive[SIZE_RECEIVE]; 

OS_MutexIDmut_Serial;//mutex for access to serial port

void __assertion_failed(char *_Expr, char *_File, int _Line, const char *_Func) {
//Put a breakpoint here to check for failed assertions, or put a loop and some hardware indicator
}

void taskBlink0(void *param);
void taskBlink1(void *param);
void taskReceiveFromUart(void* param);

int main(void)
{

/* Enable GPIO block clock */
//SYSCON_AHBPeriphClockCmd(SYSCON_AHBPeriph_GPIO, ENABLE);
UARTInit(115200);
UARTSend((uint8_t *)"Starting\r\n",10);

GPIOInit();
LPC_IOCON->JTAG_nTRST_PIO1_2&= ~0x07;
LPC_IOCON->JTAG_nTRST_PIO1_2|= 0x01;

GPIOSetDir(RED_PORT,RED_BIT,1);
GPIOSetDir(BLUE_PORT,BLUE_BIT,1);
GPIOSetDir(GREEN_PORT,GREEN_BIT,1);
GPIOSetValue(RED_PORT,RED_BIT,0);
GPIOSetValue(BLUE_PORT,BLUE_BIT,0);
GPIOSetValue(GREEN_PORT,GREEN_BIT ,0);
CoInitOS();

mut_Serial = CoCreateMutex();

/* Create Blink Task 0 */
CoCreateTask( taskBlink0,
  (void *)0,
  PRIORITY_BLINK_TASK0,
      &stkBlink0[SIZE_BLINK_TASK0-1],
      SIZE_BLINK_TASK0 );

/* Create Blink Task 1 */
CoCreateTask( taskBlink1,
  (void *)0,
  PRIORITY_BLINK_TASK1,
      &stkBlink1[SIZE_BLINK_TASK1-1],
      SIZE_BLINK_TASK1 );

/* Create Recieve Task 1 */
CoCreateTask( taskReceiveFromUart,
  (void *)0,
  PRIORITY_RECIEVE,
      &stkReceive[SIZE_RECEIVE-1],
      SIZE_RECEIVE );

ASSERT(1==0);
CoStartOS();

while(1);
}

void taskReceiveFromUart( void *param ) {

for(;; ) {
CoEnterMutexSection(mut_Serial);
UARTSend((uint8_t *)"In recieve routine\r\n",20);
CoLeaveMutexSection(mut_Serial);
CoTickDelay(20);/* Delay 200ms */
}

}

void taskBlink0(void *param)
{
/* Set PIO7 as output. */
GPIOSetDir( LED_PORT, LED_BIT, 1 );

for(;;) {
/* Turn On Led */
GPIOSetValue(LED_PORT, LED_BIT,0 );
CoTickDelay(20);/* Delay 200ms */

CoEnterMutexSection(mut_Serial);
UARTSend((uint8_t *)"In 0\r\n",6);
CoLeaveMutexSection(mut_Serial);

/* Turn Off Led */
GPIOSetValue( LED_PORT, LED_BIT,1 );
CoTickDelay(20);/* Delay 200ms */
}
}

void taskBlink1(void *param)
{
/* Set PIO2_1 as output. */

uint32_t state = 0;

GPIOSetDir( RED_PORT, RED_BIT, 1 );
GPIOSetDir( BLUE_PORT, BLUE_BIT, 1 );
GPIOSetDir( GREEN_PORT, GREEN_BIT, 1 );

for(;;) {
/* Turn On Led */
switch( state ) {
case 0: 
GPIOSetValue( RED_PORT, RED_BIT,1 );
break;
case 1:
GPIOSetValue( BLUE_PORT, BLUE_BIT ,1 );
break;
case 2:
GPIOSetValue( GREEN_PORT, GREEN_BIT,1 );
break;
}
CoTickDelay(40);/* Delay 400ms */

CoEnterMutexSection(mut_Serial);
UARTSend((uint8_t *)"In 1\r\n",6);
CoLeaveMutexSection(mut_Serial);

/* Turn Off Led */
switch( state ) {
case 0: 
GPIOSetValue( RED_PORT, RED_BIT,0 );
state++;
break;
case 1:
GPIOSetValue( BLUE_PORT, BLUE_BIT,0 );
state++;
break;
case 2:
GPIOSetValue( GREEN_PORT, GREEN_BIT,0 );
state=0;
break;
}
CoTickDelay(40);/* Delay 400ms */
}
}

lpcware · ‎06-15-2016

Content originally posted in LPCWare by rmteo on Sun Apr 11 17:42:21 MST 2010

Quote: brucesegal
I've tried CoOS from CooCox on the 1114. Very easy to get running.

Can you give details on how you got it running. Thanks.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by brucesegal on Sat Mar 20 08:34:38 MST 2010
Yes, and since source is available its possible to really look inside and see what is going on.

Quote: Mark_O
Oh, I certainly agree that it's only 1 consideration. And not even the most important one. Also, it's not necessarily the case that faster is better, if some corners have been cut.

[FONT=Courier New][SIZE=2]RTOS Latencies - Semaphore Test (Normalized)     [/SIZE][/FONT]
[FONT=Courier New][SIZE=2](ARM MCU's; times in uS @1 MHz, i.e., t = # / clockMHz)[/SIZE][/FONT]
 
[FONT=Courier New][SIZE=2][B]OS      ARM7 Time    C-M3 Time[/B][/SIZE][/FONT]
[FONT=Courier New][SIZE=2]Chibi   221  =1.0    159  =1.0[/SIZE][/FONT]
[FONT=Courier New][SIZE=2]CTL     545  =2.5    390  =2.5[/SIZE][/FONT]
[FONT=Courier New][SIZE=2]embOS   773  =3.5    628  =3.9[/SIZE][/FONT]
[FONT=Courier New][SIZE=2]NutOS   900  =4.1    --[/SIZE][/FONT]
[FONT=Courier New][SIZE=2]TNKern  498  =2.3    390  =2.5[/SIZE][/FONT]

Obviously Chibi is the fastest (~3x faster than the average of the rest), while all the rest tend to cluster, +/-30%. That would make me wonder if it's the fastest due to clever coding, or some limitations (which may not be documented). I.e., I'd want to know more details about Chibi, as a result of seeing those stats.

- Mark

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Mark_O on Fri Mar 19 23:32:19 MST 2010

Quote: brucesegal
IAlthough as is mentioned in the article the raw speed is only one of many factors in choosing an RTOS.

Oh, I certainly agree that it's only 1 consideration. And not even the most important one. Also, it's not necessarily the case that faster is better, if some corners have been cut.

[FONT=Courier New][SIZE=2]RTOS Latencies - Semaphore Test (Normalized)     [/SIZE][/FONT]
[FONT=Courier New][SIZE=2](ARM MCU's; times in uS @1 MHz, i.e., t = # / clockMHz)[/SIZE][/FONT]
 
[FONT=Courier New][SIZE=2][B]OS      ARM7 Time    C-M3 Time[/B][/SIZE][/FONT]
[FONT=Courier New][SIZE=2]Chibi   221  =1.0    159  =1.0[/SIZE][/FONT]
[FONT=Courier New][SIZE=2]CTL     545  =2.5    390  =2.5[/SIZE][/FONT]
[FONT=Courier New][SIZE=2]embOS   773  =3.5    628  =3.9[/SIZE][/FONT]
[FONT=Courier New][SIZE=2]NutOS   900  =4.1    --[/SIZE][/FONT]
[FONT=Courier New][SIZE=2]TNKern  498  =2.3    390  =2.5[/SIZE][/FONT]

Obviously Chibi is the fastest (~3x faster than the average of the rest), while all the rest tend to cluster, +/-30%. That would make me wonder if it's the fastest due to clever coding, or some limitations (which may not be documented). I.e., I'd want to know more details about Chibi, as a result of seeing those stats.

- Mark

lpcware · ‎06-15-2016

Content originally posted in LPCWare by brucesegal on Fri Mar 19 08:48:30 MST 2010
I had planned something like that once I finish the little project I'm working on. Although as is mentioned in the article the raw speed is only one of many factors in choosing an RTOS.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Mark_O on Fri Mar 19 07:56:51 MST 2010

Quote: brucesegal
Mark,

The only one I saw recently was the review at Yagarto

http://www.yagarto.de/projects/rtoscomp/index.html

In the article it is mentioned that UC/OS and FreeRTOS did not wish to be part of the comparison and so are not included.

Bruce, thanks for the link.

It's too bad the others chose not to let him include their stats. I can understand their not wanting to be evaluated on a single performance parameter, but knowing some of the core stats can still be helpful. I'd actually like to see more information... not less.

Do you have the ability to run his benchmark for CoOS, scmRTOS, and FreeRTOS?

- Mark

lpcware · ‎06-15-2016

Content originally posted in LPCWare by brucesegal on Thu Mar 18 08:50:57 MST 2010

Quote: Mark_O
Bruce,

do you know of anyone who has examined (compared) overheads from task-switching (context save/restore) and scheduling amongst the many RTOS options? I'd find that information interesting, and potentially useful.

- Mark

Mark,

The only one I saw recently was the review at Yagarto

http://www.yagarto.de/projects/rtoscomp/index.html

In the article it is mentioned that UC/OS and FreeRTOS did not wish to be part of the comparison and so are not included.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Mark_O on Wed Mar 17 21:50:56 MST 2010

Quote: brucesegal
I've tried CoOS from CooCox on the 1114. Very easy to get running. I've ported SCMRtos to the 1114 and tried that as well.

ChibiOS seem to be very complete and quite quick according to a context switch test done over at Yagarto. I'm probably going to look at that one next...

Also: FreeRtos, TNkernel, Nut/OS.

Bruce,

do you know of anyone who has examined (compared) overheads from task-switching (context save/restore) and scheduling amongst the many RTOS options? I'd find that information interesting, and potentially useful.

- Mark

lpcware · ‎06-15-2016

Content originally posted in LPCWare by SnEAky on Wed Mar 17 12:47:06 MST 2010
Alright, problem is that I don't have knowledge in porting and how to do this. I did managed to get FreeRTOS running on the LPC1343 but I don't think it's 100% reliable because of some syntax warnings in queue.c :

Description Resource Path Location Type
(near initialization for 'xQueueRegistry[0]') queue.c /LPC13xx_FreeRTOS/FreeRTOS_src line 165 C/C++ Problem

+ if i try to enable IDLE_HOOK and TICK_HOOK it will give me warnings aswel.

That's why I am looking for a precompiled RTOS for the LPCXpresso 1343.

I've also tried to look how to PWM(50Hz) using a RTOS, but so far no luck. Can someone push me in the right direction?

Thanks in advance

lpcware · ‎06-15-2016

Content originally posted in LPCWare by brucesegal on Wed Mar 17 08:38:28 MST 2010
I've tried CoOS from CooCox on the 1114. Very easy to get running.

I've ported SCMRtos to the 1114 and tried that as well.

ChibiOS seem to be very complete and quite quick according to a context switch test done over at Yagarto. I'm probably going to look at that one next. It is pure GPL for the unstable releases then goes to an GPL with linking exception for the stable releases. This makes it suitable for many projects as you can keep your application private as you only link to the OS.

Also

FreeRtos
TNkernel
Nut/OS

Lots to chose from.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by igorsk on Wed Mar 17 07:13:48 MST 2010
Any major RTOS should be portable. Maybe try FreeRTOS. I'm not aware of any ready-made examples specifically for LPC13xx.
Here's a book about FreeRTOS for LPC17xx which is also a Cortex-M3:
http://ics.nxp.com/literature/books/microcontrollers/pdf/using.freertos.lpc17xx.summary.pdf

lpcware · ‎06-15-2016

Content originally posted in LPCWare by SnEAky on Wed Mar 17 05:39:16 MST 2010
Is there a scmRTOS(or another) for the LPC1343 that can be imported in the software that comes with the LPCXpresso?

- SnEAky

lpcware · ‎06-15-2016

Content originally posted in LPCWare by igorsk on Thu Feb 18 08:01:17 MST 2010
The M0 TRM says that SysTick is optional. Also,
"Other ARM architectures support the concept of privileged or unprivileged software execution. This processor does not support different privilege levels. Software execution is always privileged, meaning software can access all the features of the processor."
However, it does mention PSP and MSP.
M1 TRM mentions OS Extensions as a configurable option.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by rkiryanov on Thu Feb 18 03:12:56 MST 2010
"ARMv6-M Architecture Reference Manual" says following:

ARMv6-M supports the privileged application/OS software model < STROKE> when the OS Extension option is implemented. The architecture variant names for implementations with and without the OS Extension are as follows:
• where the OS extension is not present, ARMv6-M
• where the OS extension is present, ARMv6S-M.< /STROKE>

Is far as I understand, variant ARMv6-M does not exist and Cortex-M0 is always ARMv6S-M, with SysTick, PendSV and MSP/PSP. Is it correct?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by rkiryanov on Thu Feb 18 02:01:32 MST 2010

Quote: Gerrit
port for the LPC1000 families

This is the reason for OS development :) to get OS for dedicated core and with good interface and features. If you have port for M3, try build it for M0. Very little part should be ported from M3 to M0.