<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: CoOS Real Time Kernel (CooCox.org) – Part 2</title>
	<atom:link href="http://polisoftdesign.com/2010/04/23/coos-real-time-kernel-coocox-org-%e2%80%93-part-2/feed/" rel="self" type="application/rss+xml" />
	<link>http://polisoftdesign.com/2010/04/23/coos-real-time-kernel-coocox-org-%e2%80%93-part-2/</link>
	<description>Embedded Systems for Energy Efficient Lighting</description>
	<lastBuildDate>Fri, 10 Sep 2010 18:07:21 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: admin</title>
		<link>http://polisoftdesign.com/2010/04/23/coos-real-time-kernel-coocox-org-%e2%80%93-part-2/comment-page-1/#comment-105</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Wed, 26 May 2010 19:50:32 +0000</pubDate>
		<guid isPermaLink="false">http://polisoftdesign.com/?p=292#comment-105</guid>
		<description>I&#039;m really busy building a serious application around CoOS. This is the main reason I stopped writing articles and began to write a lot of code. I intend to share some of that code (the parts that are independent of my project) in about few weeks from now together with a series of postings about CoOS. As for the naming conventions and portable data types I agree -- is would be beneficial to adhere to some standard and write code that is portable. Unfortunately, the lack of standards until recently, the lax nature of the ANSI C standard, the &quot;community standards and styles&quot; created this mess that we are in. I&#039;m guilty as any other developer of not following ISO-C / UNIX / MISRA-C:2004 guidelines for years and many serious software houses are even guiltier for not promoting the standards themselves when providing the tools. This is the reason we keep reinventing the wheel trying to bring a bit of order. 

However, I&#039;ve noticed that  became more mainstream today, many tool chains providing portable data types as you mentioned. It would be nice for the compilers to adhere to C99 standard as well with all the benefits but, unfortunately, it may take a bit more for some... Look how inconsistent the 64-bit integer type is defined: is it long long or __int64? Silly, isn&#039;t it?

I will also dedicate postings on style and standards one day. What I need is time... just time :-)</description>
		<content:encoded><![CDATA[<p>I&#8217;m really busy building a serious application around CoOS. This is the main reason I stopped writing articles and began to write a lot of code. I intend to share some of that code (the parts that are independent of my project) in about few weeks from now together with a series of postings about CoOS. As for the naming conventions and portable data types I agree &#8212; is would be beneficial to adhere to some standard and write code that is portable. Unfortunately, the lack of standards until recently, the lax nature of the ANSI C standard, the &#8220;community standards and styles&#8221; created this mess that we are in. I&#8217;m guilty as any other developer of not following ISO-C / UNIX / MISRA-C:2004 guidelines for years and many serious software houses are even guiltier for not promoting the standards themselves when providing the tools. This is the reason we keep reinventing the wheel trying to bring a bit of order. </p>
<p>However, I&#8217;ve noticed that  became more mainstream today, many tool chains providing portable data types as you mentioned. It would be nice for the compilers to adhere to C99 standard as well with all the benefits but, unfortunately, it may take a bit more for some&#8230; Look how inconsistent the 64-bit integer type is defined: is it long long or __int64? Silly, isn&#8217;t it?</p>
<p>I will also dedicate postings on style and standards one day. What I need is time&#8230; just time <img src='http://polisoftdesign.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: LeQ</title>
		<link>http://polisoftdesign.com/2010/04/23/coos-real-time-kernel-coocox-org-%e2%80%93-part-2/comment-page-1/#comment-99</link>
		<dc:creator>LeQ</dc:creator>
		<pubDate>Wed, 26 May 2010 07:07:59 +0000</pubDate>
		<guid isPermaLink="false">http://polisoftdesign.com/?p=292#comment-99</guid>
		<description>At first, I&#039;m really looking forward to read your next article about this OS. I checked out the Webpage of CooCox, and it seems to be interesting. I&#039;m using FreeRTOS and µC/OS at most. This seems to be a nice alternative. I just wonder &quot;What&#039;s the catch?&quot;. With the BSD License of the OS you avoid this silly FreeRTOS thing, where you need to print the FreeRTOS logo in your product documentation. But whatever I will check out the OS myself within the next month.

One thing to the data type naming conventions. I personally don&#039;t understand why people always use go on there own... I personally like to use the ISO-C / UNIX / MISRA-C:2004 Data type conventions like uint32_t. Yap It is long and maybe unhandy, but it&#039;s regarding to a common standard and especially with gcc and a good toolchain you have the stdint.h anyways, with correct data types for you anyways.

Well thanks for this articles, looking for more! :)</description>
		<content:encoded><![CDATA[<p>At first, I&#8217;m really looking forward to read your next article about this OS. I checked out the Webpage of CooCox, and it seems to be interesting. I&#8217;m using FreeRTOS and µC/OS at most. This seems to be a nice alternative. I just wonder &#8220;What&#8217;s the catch?&#8221;. With the BSD License of the OS you avoid this silly FreeRTOS thing, where you need to print the FreeRTOS logo in your product documentation. But whatever I will check out the OS myself within the next month.</p>
<p>One thing to the data type naming conventions. I personally don&#8217;t understand why people always use go on there own&#8230; I personally like to use the ISO-C / UNIX / MISRA-C:2004 Data type conventions like uint32_t. Yap It is long and maybe unhandy, but it&#8217;s regarding to a common standard and especially with gcc and a good toolchain you have the stdint.h anyways, with correct data types for you anyways.</p>
<p>Well thanks for this articles, looking for more! <img src='http://polisoftdesign.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: admin</title>
		<link>http://polisoftdesign.com/2010/04/23/coos-real-time-kernel-coocox-org-%e2%80%93-part-2/comment-page-1/#comment-15</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Thu, 06 May 2010 05:00:51 +0000</pubDate>
		<guid isPermaLink="false">http://polisoftdesign.com/?p=292#comment-15</guid>
		<description>Here is the reality: if you need all the available features, then the size can be ~10 KB. If you keep everything minimal the size reduces to ~2.5 KB but you will be limited to multitasking without inter-task communication and synchronization. If you add semaphores (more realistic) the code size will be ~4 KB and ~500 B of data (depending of number of tasks, semaphores, etc.) Expect about 20...30% code size reduction if you enable full optimization in the compiler. Still not 1 KB!
But I agree that FreeRTOS may require a bit more code space without so many features that CoOS offers. There are other options for really small RTOS preemptive kernels but don&#039;t expect miracles. 

In the list below you will find each module and its size (IAR EWARM 5.30, no optimization, CPU is Cortex M3):

&lt;code&gt;
&lt;strong&gt;Module..........Code........Data........Const&lt;/strong&gt;
arch............222.........12..........0
core............418.........3...........0
event...........718.........164.........0
flag............1538........20..........0
hook............4...........0...........0
kernelHeap......716.........212.........0
mbox............480.........0...........0
mm..............548.........36..........0
mutex...........674.........81..........0
portForM3.......120.........0...........0
queue...........762.........36..........0
sem.............452.........0...........0
serviceReq......308.........71..........0
task............1640........520.........0
time............676.........4...........0
timer...........1220........56..........0
utility.........158.........0...........0
&lt;strong&gt;Total...........10654.......1215........0&lt;/strong&gt;
&lt;/code&gt;

It is possible that the code can be ported on ARM7 but this requires a bit of work and my time is limited for the moment. However, CoOS authors may have this in plan anyway. Keep an eye on this site or coocox.org for news.

Good luck!</description>
		<content:encoded><![CDATA[<p>Here is the reality: if you need all the available features, then the size can be ~10 KB. If you keep everything minimal the size reduces to ~2.5 KB but you will be limited to multitasking without inter-task communication and synchronization. If you add semaphores (more realistic) the code size will be ~4 KB and ~500 B of data (depending of number of tasks, semaphores, etc.) Expect about 20&#8230;30% code size reduction if you enable full optimization in the compiler. Still not 1 KB!<br />
But I agree that FreeRTOS may require a bit more code space without so many features that CoOS offers. There are other options for really small RTOS preemptive kernels but don&#8217;t expect miracles. </p>
<p>In the list below you will find each module and its size (IAR EWARM 5.30, no optimization, CPU is Cortex M3):</p>
<p><code><br />
<strong>Module..........Code........Data........Const</strong><br />
arch............222.........12..........0<br />
core............418.........3...........0<br />
event...........718.........164.........0<br />
flag............1538........20..........0<br />
hook............4...........0...........0<br />
kernelHeap......716.........212.........0<br />
mbox............480.........0...........0<br />
mm..............548.........36..........0<br />
mutex...........674.........81..........0<br />
portForM3.......120.........0...........0<br />
queue...........762.........36..........0<br />
sem.............452.........0...........0<br />
serviceReq......308.........71..........0<br />
task............1640........520.........0<br />
time............676.........4...........0<br />
timer...........1220........56..........0<br />
utility.........158.........0...........0<br />
<strong>Total...........10654.......1215........0</strong><br />
</code></p>
<p>It is possible that the code can be ported on ARM7 but this requires a bit of work and my time is limited for the moment. However, CoOS authors may have this in plan anyway. Keep an eye on this site or coocox.org for news.</p>
<p>Good luck!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Adriano Prado</title>
		<link>http://polisoftdesign.com/2010/04/23/coos-real-time-kernel-coocox-org-%e2%80%93-part-2/comment-page-1/#comment-14</link>
		<dc:creator>Adriano Prado</dc:creator>
		<pubDate>Tue, 04 May 2010 16:36:54 +0000</pubDate>
		<guid isPermaLink="false">http://polisoftdesign.com/?p=292#comment-14</guid>
		<description>According to the CooCox CoOS page, it will take less than 1K for the Kernel code, and about 200K of RAM!
With such small footprint I think it beats FreeRTOS for devices with low memory space, like the LPC210x.
Now I&#039;m just wondering if the support will be as good as in FreeRTOS, but I think it&#039;s worth to check. I hope you post your findings about it soon (specially if you port it to ARM7).

Regards.</description>
		<content:encoded><![CDATA[<p>According to the CooCox CoOS page, it will take less than 1K for the Kernel code, and about 200K of RAM!<br />
With such small footprint I think it beats FreeRTOS for devices with low memory space, like the LPC210x.<br />
Now I&#8217;m just wondering if the support will be as good as in FreeRTOS, but I think it&#8217;s worth to check. I hope you post your findings about it soon (specially if you port it to ARM7).</p>
<p>Regards.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

