The system requests servicing implemented in CoOS is a bit more complex: most of the time the requests are serviced immediately at the exit of the ISR. However, if the kernel is in the middle of scheduling tasks then the request servicing is delayed until the next SysTick. This delay may vary between almost 0 and the system timer time interval. This delay can be a problem in situations like you suggested – very fast peripherals. This is one of the reasons I suggested that you should try to reduce the interrupt rate significantly by using what the hardware provides: FIFO or DMA. Or avoid using system services completely in your ISRs.

Otherwise, CoOS is responsive and reliable. Other RTOS kernels are subject of similar issues despite of different implementations and different internal architecture.

Personally, I don’t think that servicing system requests in the SysTick handler is good idea.
With high-speed peripherals like Ethernet/CAN/SPI you can’t be sure that queue will not become full.

Regards.

However, I’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’t it?

I will also dedicate postings on style and standards one day. What I need is time… just time

One thing to the data type naming conventions. I personally don’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’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!

In the list below you will find each module and its size (IAR EWARM 5.30, no optimization, CPU is Cortex M3):


Module..........Code........Data........Const
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
Total...........10654.......1215........0


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!

Regards.

“Aside form programming skills the embedded developer has to think of solving problems in a different mindset than the average PC programmer.”

Good point..

You are right: there is no check if the FIFO is empty (in ComGetChar) or full (in Com_ISR). This was one of the answers.

You are right again: the rx_count is also a shared variable and needs protection (or atomic access) but this won’t lead to a disaster as rx_count is not used directly to access the FIFO (it was intended for only checking the amount of data in the FIFO). However, its value may be inconsistent as you mentioned.

The major problem (as I can see it) is the access to the buffer itself — here is where the mutual exclusion problem really occurs. And this is what I will try to cover in my next post(s).

Your assumption that there is no other concurrency than the main thread vs. interrupt is valid in many cases where there is no RTOS involved. However, even in this simple situation the mutual exclusion problem exists and you need protection. I suggest you analyze the code generated by the compiler for Com_ReadRxByte() and see what an interrupt occurring randomly between machine instructions could do when the function executes. The exercise is always recommended when you have doubts regarding the effects of interrupt preemption.

Regarding the flaws you ask: One minor problem with the Com_BufReadRxByte() is that it doesn’t check whether the FIFO is empty so you can call it only when the FIFO is non-empty and thus you make the programmer responsible for checking that. The major problem though is the rx_count variable. This variable is modified in both functions Com_ReadRxByte() and Com_WriteRxBuf(), and due to the fact that Com_WriteRxBuf() is called from an ISR which can interrupt the Com_ReadRxByte(), the rx_count can become inconsistent.

My view is following, in case you have 2 threads and one thread modifies only one half of the FIFO (one part of members of the FIFO, e.g. the write part), and potentially only reads the other half, and the other thread modifies only the other half of the FIFO (e.g. the read part), then you don’t need any mutual exclusion (of those threads) at all. This is very often the case, you have the main thread and the interrupt thread, one of which is (only) producer, the other one is (only) consumer or vice-versa. I think we should take a benefit of it and construct queues which don’t need mutual exclusion (for this scenario).

With regards,
Jan

There are different lighting communication standards that compete with each other or are incomplete or confusing, difficult to implement consistently, or trying to address only certain devices while ignoring others (especially the new ones). Some of them attempt to satisfy the requirements of the entertainment industry, other to satisfy building lighting and others do not have a clear target. They all target just the pieces of the puzzle and not the whole system. That’s why the interoperability is almost a nightmare.

It seems that lamp manufacturers lack the vision when it comes to building a lighting system rather than lighting components. There is no unity; most companies hope making money with a proprietary system (if they have one); the lighting community does not have a clear picture of how the lighting industry will evolve in the next decade.

One thing is clear: without the ability of controlling light easily in all aspects (intensity, color, timing) the future of the new lighting technologies will depend primarily on cost: this means slow adoption because people think with their wallets. From this point of view, the retrofit lamps that come mainly from China will satisfy the market needs in short term. Unfortunately, quality and lack of features will remain the main issues in order to keep the cost down.

Adding controllability (and, subsequently, new features) on top of the long life, the efficiency and being environmentally friendly but hiding the complexity of the technology in the software embedded in these devices will accelerate the adoption.

Changing or enhancing the technology doesn’t have to become “the obstacle” but the facilitator in this process. In fact, the novelty factor will act as a catalyst in educating the market. Just think of two recent examples: digital cameras and smart phones. It won’t happen over night but, eventually, it will happen: controllability without complexity for the end user is the next big thing in lighting. And, yes, we need a plan (not only vision). That’s why I asked your opinions.

Have I made my self clear this time? I really appreciate the feedback.