[LOG] RT 4.0 and NIL 2.0

[Giovanni]

News:

- Added new hooks for IRQ-enter, IRQ-leave and trace events.
- Stronger checks on the chconf.h file.

Giovanni

[Giovanni]

News:

- Removed I/O Queues and Streams Interface from RT 4.0 to avoid duplication with HAL equivalents (which are improved).

Giovanni

[Giovanni]

News:

- Added Guarded Memory Pools to both RT and NIL. This objects is a memory pool guarded by a semaphore, the allocation operation waits until there is an object available or a timeout occurs. It is derived conceptually from that old "mail" module that never got officially included in older RTs.

Guarded memory pools together with mailboxes form a nice mechanism for exchanging large messages/buffers across threads/ISRs.

Giovanni

[alex31]

I react to a one month old post on new developments :

- Removed Thread termination API

did you speak of this set of fonctions : chThdTerminate, chThdShouldTerminateX, chThdTerminatedX ?

(i hope no )

Alexandre

[Giovanni]

Yes, that ones, but I ended up keeping them. It is true that you can do the same with a flag or events but it is less elegant.

Giovanni

[electronic_eel]

Will you be able to use the commandline shell with NIL 2.0 now that the streams are in HAL?

Last time I wanted to use it, I had to switch from NIL to RT.

[Giovanni]

Will you be able to use the commandline shell with NIL 2.0 now that the streams are in HAL?

Last time I wanted to use it, I had to switch from NIL to RT.

It should work except that the shell calls chThdExit(), I have to make a change to disable the "exit" command. It will be possible to create static shells.

Giovanni

[Giovanni]

News:

- Introducing the new testing methodology.

NIL and NASA-OSAL are already tested using this new methodology, RT test suite is being reworked/rewritten, HAL high level is next.

The test system consists:
1) An high level test specification written in XML (using SPC5Studio configuration editor, see screenshot below).
2) A set of source code templates -generated- from the XML specification: test_root.c/h, test_sequence_xxx.c/h.
3) A test specification document is obtained from the generated source templates (no implementation yet, just spec) by running Doxygen.
4) Code snippets added to the XML configuration in order to implement the test steps.
5) Final test code generated from the XML, ready to be compiled and executed.

For those of you into the quality stuff, we are in the descending side of the V model (test specification then test implementation).

The test suite is composed of:
1) A Global Section: global descriptions and global code.
2) Test Sequences are composed by descriptions and one or more Test Cases.
3) Test Cases are composed by descriptions and one or more Test Steps.
4) Test Steps are composed by a description and a code snippet.

The advantages of the new system are:
- Stricter adherence to the V model.
- Most code is generated not written.
- Not RT-specific, it can (and will) be used for everything.
- Test specification documents obtained for free.
- Test code snippets can be re-used in any kind of source templates should the test environment change. Test code is reusable.

The system is implemented using SPC5Studio 4.0 from ST (it is free), I just created components for this, the tool is very flexible and can be used for lot of things involving XML editing and code generation. I plan to use it a lot.

The whole thing is available to all ChibiOS users needing to create test suites for their modules/subsystems. The test runtime functionally depends only on HAL (for I/O).

Giovanni

[crispus]

News:
- New threading API added.

Code: Select all

...
  thread_t *chThdCreateSuspended(const thread_descriptor_t *tdp);
...


I created multiple suspended threads, and when I try to start them using chThdStart. The problem I ran into is that if the current thread has a lower priority than any of the suspended threads I will get a priority order violation

The workaround was:

Code: Select all

    tprio_t currentPrio = chThdGetPriorityX();
    chThdSetPriority(HIGHPRIO);

    for(uint32_t i = 0; i < gThreadCount; i++)
    {
        /* start/resume the thread */
        chThdStart(gThreads[i]);
    }

    /* restore the old priority */
    chThdSetPriority(currentPrio);


Is this by design?

Thanks

[Giovanni]

Hi,

It is a bug triggered by the priority change, thanks for finding, I will fix it tomorrow. A call to chSchRescheduleS() is required in that function.

In the meanwhile you can replace it with:

Code: Select all

chSysLock();
for(...) {
  chThdStartI(...);
}
chSchRescheduleS();
chSysUnlock();


Threads start is guaranteed to be atomic regardless of priority of current thread. It should be also a bit more efficient.

Giovanni