Have you tested also the Unity framwork?
in VC++ and some other embedded compiler?

I have problems with the macro’s in the unity_fixture.h

The problem is the macro construction that generates a function declaration followed by the call to it, see code snippet below, strangely it compiles in GCC

TEST_GROUP_RUNNER(LedDriver)
{
// RUN_TEST_CASE(LedDriver, LedsOffAfterCreate);
void TEST_LedDriver_LedsOffAfterCreate_run();
TEST_LedDriver_LedsOffAfterCreate_run();

// RUN_TEST_CASE(LedDriver, TurnOnLedOne);
void TEST_LedDriver_TurnOnLedOne_run(); // this is row 30 that the compiler reports an error for
TEST_LedDriver_TurnOnLedOne_run();
}

—-—– compile error in VC++ 2008 express –—-
code/unity/LedDriver/LedDriverTestRunner.c(30) : error C2143: syntax error : missing ’;’ before ‘type’
-—-—-—-—-—-—-—-—-—-—-—-

I want an automatic tool that could convert a nested code such kind of:

(C / C++)

if (q1 && q2 || ….)
{
do_1();
if (q3 …)
{
do_3();
if (q4 …)
{
do_4();
…
}
else
{
do_e4();
…
}
else
{
do_e3();
…
}
}

To the type of linear code:

if (q1 && q2 || ….)
do_1();

if ((q1 && q2 || ….) && q3)
do_3();

if ((q1 && q2 || ….) && q3 && q4)
do_4();

if ((q1 && q2 || ….) && q3 && !q4)
do_e4();

if ((q1 && q2 || ….) && !q3)
do_e3();

Do you know of such a tool?

Thank you

Uri.

just a side-note: Locking interrupts on ColdFire is very costly: The lock/unlock pair needs up to 15cycle (including preserving the old state).

Cheers,
42Bastian

My point is that you can use a variety of approaches to handle all 3 cases cleanly. The two obvious choices are:
- You have a “launcher” running at task level.
- You do via handlers as we have been discussing.

A launcher looks like:
void Launcher(void) {
while (top_ready.function) // a task is ready to run, so run it
top_ready.function(); // run to completion. When done see if more to run
return; // pop back to SVC instruction (LR points to SVC when PendSV created frame)
}

This handles back to back, nested back to back, and so on. When nested stack finishes and no other high pri task, it returns to allow “frame” to be popped by task underneath. You *could* do this by manually popping yourself from return link code instead of SVC.
If nothing to run, then you can use SLEEP_ON_EXIT. If you do not want to do that, you can have launcher never leave if lowest:
void Launcher(void) {
while (top_ready.function // a task is ready to run, so run it
|| nothing_stacked)
if (top_ready.function)
top_ready.function(); // run to completion.
else // no nested tasks, so run idle task
idle_task(); // sleeps or whatever you do
return; // pop back to SVC instruction (LR points to SVC when PendSV created frame)
}


void QK_schedule_(void) { /* entered with interrupts locked!!! */
....uint8_t pin = QK_currPrio_; /* the initial QK-nano priority */
....uint8_t p; /* highest-priority ready to run */

........QF_INT_LOCK(); /* lock interrupts for next loop or exit */
....}
....QK_currPrio_ = pin; /* restore the initial priority */
} /* scheduler entered with interrupts locked!!! */

My main point is that launching a task is just a simple function call and *no* additional registers need to be saved above and beyond what the C compiler already does. Quite specifically, I really don’t need to save the registers clobbered by the APCS (r0-r3,r12,lr) to launch a task. The only time I care for these registers is when an exception preempts a task, but Cortex-M does this automatically for me. So, by the time I’m inside PendSV, I already sit on top of the exception stack frame that preserves the APCS-clobbered registers for the preempted task. Any additional saving of these APCS-clobbered registers would be saving them *twice*, which is harmless, but incurs cost both in CPU time and stack space. I hope you agree that it would be nice to avoid this unnecessary overhead.

So, do other processors handle this better than Cortex-M? I think so. Looking only at CPUs that can prioritize interrupts, Coldfire or M16C require just one assembly instruction to drop the IPL (interrupt priority level) to the task. Here is an example ISR for M16C:


#pragma INTERRUPT ta0_isr (vect = 21) /* system clock tick ISR */
void ta0_isr(void) {
....++QK_intNest_; /* inform QK about entering in ISR */
...._asm("FSET I"); /* unlock the interrupts */

...._asm("LDC #0,FLG"); /* lock interrupts and set IPL to 0 */
....--QK_intNest_;
....if (QK_intNest_ == (uint8_t)0) { /* last nested interrupt? */
........QK_schedule_(); /* handle the preemptions */
....}
}

I’d like to achieve similar performance on Cortex-M. Is it possible?

Now, I want to be clear that I do not agree with your comment about other processors. If you need to create a new task stacked over an old task, you have to have saved enough registers of the original task to ensure it can return safely. This means that you manually did what the Cortex-M core is doing for you – either the ISRs do it in their prologue or you do it in code or they go into some sort of shadow regs. If you want nested interrupts, all of those end up having to deal with that to. But, no matter method is used, if you are creating a new task, enough regs have to be preserved of the current task – you cannot escape that. For many processors you pay for pop and then repush to do this. For Cortex-M, you get the savings on average and certainly for this case (old task’s regs are on the frame for you, which is why you create a new one).
Creating a new frame for the new task is not really a waste – you always had to set the new PC and a return link of some sort. The fact that you do not pass any args means it is just stack math of 32 bytes but not pushing. The popping does happen and could be considered a waste, but this still averages out as a win over all; yes you can cheat this (ACT bit), but do you really need to? It is like people who refuse to use an RTOS because they can save a few cycles here and there. The point is that the new frame is really about preserving the old frame for the current task – invert it and think of it as saving the context of the old task and it seems OK.
So, you can save the SVC trick if your tasks are all supervisor and you really want to. Just pop the context back from the save frame vs. using the machinery of return link. Again, you can cheat this (by setting ACT bit and returning to do the pop), but does it really buy you enough?
If you really need more of the methods of other processors, there is another way. Your PendSV does not change the frame at all. Instead it puts the original frame PC (current task) in a variable (e.g. current_task_PC) and replaces with a “new_task_create” function which is like your schedule function. It immediately pushes R0-R3, R12, LR, current_task_PC, and xPSR – basically just what the hardware does on exception. Then, it calls the new task. When it returns, the new_task_create function 1st checks if another higher pri task to run above the stacked one and if not, just pops those regs and so returns into the old task. That is how you did it on other processors. Not sure you save much in time since the extra instructions are used. But, if this would make you happier you can do it.
My point about using the scheme I said is that it is cheap and easy and supports user tasks if you want them. The overhead is there (an extra push set (SVC) and partly an extra pop (from PendSV return to new task) for a new task) but it is relatively small and no extra cost if another higher pri task waiting. Also, no cost if task runs to completion and a new task is started (since SVC frame is new tasks frame). That is, this only overhead is when a task pre-empts another.
OK?

I guess, I now better understand your suggestions for re-designing my current implementation of the RTC kernel for Cortex-M. I also recognize some of your suggestions in the code contributed by @42Bastian.

It seems to me that to implement your recommendations I would need to re-partition the kernel completely for the Cortex-M core, so any portability to other processors would be essentially lost. Luckily, an RTC kernel is by nature so small, that the scheduler could be written entirely in assembly, if need be. In the process of creating a CM-specific RTC kernel I can also make use of bit-banding and other goodies available only in CM.

But before I move on, I’d like to make sure that this is really the best we can do for an RTC kernel on Cortex-M (?) From the aesthetic point of view I find the RTC kernel design (both mine or any of the proposed ones) rather unpleasing. I mean, the tail-chaining to PendSV is brilliant. But once inside the PendSV, the stack is already perfectly set up to either launch a higher-level tasks or return to the preempted task. This is so, because an RTC kernel works with the machine’s *natural* stack protocol. So, all one needs to do is to tell the NVIC to drop to the task level (this is what I mean by a generically understood EOI command) and after this, to exception-return to the preempted task. On most processors this takes only a few machine instructions and *no* stack manipulation.

Unfortunately, on Cortex-M this “telling it to the NVIC” takes pushing and popping two exception stack frames (which also wastes 32-bytes of stack) as well as several assembly instructions. I find it aesthetically unpleasing, because all this stack manipulations accomplish exactly nothing. They must accomplish nothing, because the stack *is* already set-up correctly before all the pushing and popping exception stack frames.

I’d greatly appreciate any comments. My ultimate goal is to come up with the simplest possible RTC kernel implementation on Cortex-M. I just don’t want to sweat the little details (like bit-banding) while losing many more clock cycles and stack space on pushing and popping exception stack frames.

Finally, before moving on to re-implementing RTC kernel for Cortex-M, I’d really like to understand the failure mode illustrated in the trace discussed in my original blog. Please correct me if I misrepresent your diagnosis, but you essentially suggested that the Hard Fault at the end of the trace is due to normal preemption of the PendSV by a higher-level interrupt, which has set the PENDSVSET bit. I tested this scenario several times (with different settings of the kernel’s ready-set and the current priority ceiling) in a debugger. My tests were done as follows. I’ve set a breakpoint on the first instruction of PendSV. As soon as the breakpoint was hit, I’ve removed it and placed it on the very next instruction. I’ve also triggered an specifically instrumented interrupt (by manually writing to the PEND bit in the debugger). I than hit “go” in the debugger and watched the preemptions. The point is that while I could reproduce every instruction in the original trace, I could *not* reproduce the Hard Fault. The code handled the preemption (including setting the PENDSVSET bit) in the PendSV handler itself correctly every time.

Maybe, as you say, the provided hardware trace is insufficient to provide an accurate diagnosis. However, it seems to me that the one thing I could’n test in a single-step debugger is the dynamic condition of the late-arrival scenario. So, I’m left to believe that something is different with late-arrival. I speculate further that my use of SVCall is also implicated. Other kernels simply don’t do this. Using a single PendSV exception with global variables for directing the flow of control would most likely mask the problem. Again, I would appreciate any comments or suggestions what else can be done to get to the bottom of this.

By the way, I agree that bit-band can be used to get around some critical sections. I wrote a small kernel back in 2005 on CM3 (on FPGA – no Si) that used bitband for sleep and ready “lists” and used CLZ to find the highest pri task in one instruction. I had ISRs write to a bitbanded “wake list” and used PendSV after (so no race possible). It did mean each task had a separate priority (no round robin) and if you wanted more than 32 tasks, it used a simple two level version of this (bit banding for the directory and then page) but was really designed for 32 or less.
I used LDREX/STREX to handle non-blocking and non-locking queues to send data between ISRs and Tasks so no critical data issues there either. Purpose was to show that you could build a powerful kernel which had no critical sections at all.