Hi,
I opened a branch for experimental work regarding RT 4.0 and NIL 2.0: /branches/rt4_dev
Those are supposed to be the next gen ChibiOS kernels, I will log here the changes.
So far:
- Moved startup files from /os/common/ports to /os/common/startup.
- Moved /os/rt/ports to /os/common/ports, the idea is to have unified ports for RT and NIL in order to not duplicate code and maintenance.
- Moved /os/ext to /os/common/ext. It is common code.
- (RT) The thread_t structure has been moved at the end of the working area instead of beginning. It is a safer place in case of a stack overflow, it will also allow to put guard pages at beginning of WAs for strong stack overflow checking using MPU (deny access pages).
- (NIL) Files renamed to ch.h, chconf.h and ch.c in order to have a better source level compatibility.
- (NIL) All identifiers in configuration files have been renamed to be equal to those in RT.
- Configuration files now define _CHIBIOS_NIL_CONF_ or _CHIBIOS_RT_CONF_ and the macro definition is checked by the OS.
Currently both RTOSes compile correctly using the same port files. Everything is not frozen and could be reverted.
Giovanni
[LOG] RT 4.0 and NIL 2.0
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [LOG] RT 4.0 and NIL 2.0
Update:
- Implemented stack overflow checking using MPU on the ARMCMx port.
There is a moderate impact on context switching because also an MPU region must be reprogrammed during context switch.
The check is implemented as a 32 bytes non-accessible guard page at base of each stack. The page is not accessible so in case of overflow an exception is triggered but without the corruption usually caused by the overflow, the system state is clean for inspection. Of course it is much safer than the software stack overflow check method.
Giovanni
- Implemented stack overflow checking using MPU on the ARMCMx port.
There is a moderate impact on context switching because also an MPU region must be reprogrammed during context switch.
Code: Select all
*** ChibiOS/RT test suite
***
*** Kernel: 4.0.0
*** Compiled: Jan 12 2016 - 16:16:51
*** Compiler: GCC 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 227977]
*** Architecture: ARMv7E-M
*** Core Variant: Cortex-M7 (MPU)
*** Port Info: Advanced kernel mode
*** Platform: STM32F746 Very High Performance with DSP and FPU
*** Test Board: STMicroelectronics STM32F746G-Discovery
----------------------------------------------------------------------------
--- Test Case 1.1 (System, critical zones)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 1.2 (System, interrupts handling)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 1.3 (System, integrity)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 2.1 (Threads, enqueuing test #1)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 2.2 (Threads, enqueuing test #2)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 2.3 (Threads, priority change)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 2.4 (Threads, delays)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 3.1 (Semaphores, enqueuing)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 3.2 (Semaphores, timeout)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 3.3 (Semaphores, atomic signal-wait)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 3.4 (Binary Semaphores, functionality)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 4.1 (Mutexes, priority enqueuing test)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 4.2 (Mutexes, priority return)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 4.3 (Mutexes, status)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 4.4 (CondVar, signal test)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 4.5 (CondVar, broadcast test)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 4.6 (CondVar, boost test)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 5.1 (Messages, loop)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 6.1 (Mailboxes, queuing and timeouts)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 7.1 (Events, registration and dispatch)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 7.2 (Events, wait and broadcast)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 7.3 (Events, timeouts)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 8.1 (Heap, allocation and fragmentation test)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 9.1 (Memory Pools, queue/dequeue)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 10.1 (Dynamic APIs, threads creation from heap)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 10.2 (Dynamic APIs, threads creation from memory pool)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 10.3 (Dynamic APIs, registry and references)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.1 (Queues, input queues)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 11.2 (Queues, output queues)
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 12.1 (Benchmark, messages #1)
--- Score : 932032 msgs/S, 1864064 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 12.2 (Benchmark, messages #2)
--- Score : 825209 msgs/S, 1650418 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 12.3 (Benchmark, messages #3)
--- Score : 825209 msgs/S, 1650418 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 12.4 (Benchmark, context switch)
--- Score : 3348816 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 12.5 (Benchmark, threads, full cycle)
--- Score : 656529 threads/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 12.6 (Benchmark, threads, create only)
--- Score : 977369 threads/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 12.7 (Benchmark, mass reschedule, 5 threads)
--- Score : 304224 reschedules/S, 1825344 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 12.8 (Benchmark, round robin context switching)
--- Score : 2354200 ctxswc/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 12.9 (Benchmark, I/O Queues throughput)
--- Score : 2522620 bytes/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 12.10 (Benchmark, virtual timers set/reset)
--- Score : 1990948 timers/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 12.11 (Benchmark, semaphores wait/signal)
--- Score : 3034232 wait+signal/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 12.12 (Benchmark, mutexes lock/unlock)
--- Score : 2482752 lock+unlock/S
--- Result: SUCCESS
----------------------------------------------------------------------------
--- Test Case 12.13 (Benchmark, RAM footprint)
--- System: 384 bytes
--- Thread: 68 bytes
--- Timer : 20 bytes
--- Semaph: 12 bytes
--- EventS: 4 bytes
--- EventL: 20 bytes
--- Mutex : 16 bytes
--- CondV.: 8 bytes
--- Queue : 36 bytes
--- MailB.: 40 bytes
--- Result: SUCCESS
----------------------------------------------------------------------------
Final result: SUCCESS
The check is implemented as a 32 bytes non-accessible guard page at base of each stack. The page is not accessible so in case of overflow an exception is triggered but without the corruption usually caused by the overflow, the system state is clean for inspection. Of course it is much safer than the software stack overflow check method.
Giovanni
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [LOG] RT 4.0 and NIL 2.0
Update:
- Implemented enhanced trace buffer in RT. Supporting multiple events and dual time stamp (system time, RT counter).
Now it can log several kind of events:
- Thread switch (previous only mode).
- ISR enter.
- IRS leave.
- Halt.
- Possibly others (ideas?).
This allows to see also ISRs preempting each other thanks to sequences like: ISR1-enter, ISR2-enter, ISR2-leave, ISR1-leave. Useful for tracing nasty bugs.
Practical use will require an update of the Eclipse plugin, it would be nice to put events in a graphical form, something like a digital analyzer view with all threads and ISRs like signals. I am not that good at Java however at very least I will update the current table view.
Giovanni
- Implemented enhanced trace buffer in RT. Supporting multiple events and dual time stamp (system time, RT counter).
Now it can log several kind of events:
- Thread switch (previous only mode).
- ISR enter.
- IRS leave.
- Halt.
- Possibly others (ideas?).
This allows to see also ISRs preempting each other thanks to sequences like: ISR1-enter, ISR2-enter, ISR2-leave, ISR1-leave. Useful for tracing nasty bugs.
Practical use will require an update of the Eclipse plugin, it would be nice to put events in a graphical form, something like a digital analyzer view with all threads and ISRs like signals. I am not that good at Java however at very least I will update the current table view.
Giovanni
Re: [LOG] RT 4.0 and NIL 2.0
Giovanni wrote:- Possibly others (ideas?).
A means of adding non-Chibi events to the log would be very useful, as would options to selectively disable Chibi-generated events.
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [LOG] RT 4.0 and NIL 2.0
Great idea, I'll add it. Selecting what to trace is already there.
Giovanni
Giovanni
Re: [LOG] RT 4.0 and NIL 2.0
Possibly taking things a bit too far, but it could also be useful to have the ability to enable and disable tracing from code, and even to modify the mask of events which are traced dynamically. (Maybe that's in Chibi5?)
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [LOG] RT 4.0 and NIL 2.0
Update:
- NIL received the state checker and function parameters checker functionalities.
@steved, considering it.
Giovanni
- NIL received the state checker and function parameters checker functionalities.
@steved, considering it.
Giovanni
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [LOG] RT 4.0 and NIL 2.0
Update:
Debug plugin for RT4 ready:
The last two lines are caused by the following code placed into main():
Now I wish to put it in graphical form but this will have to wait, I have to understand how to do that in Eclipse.
Giovanni
Debug plugin for RT4 ready:
The last two lines are caused by the following code placed into main():
Code: Select all
chThdSleepMilliseconds(500);
chDbgWriteTrace((void *)0x55555555, (void *)0xAAAAAAAA);
chSysHalt("shit happened");
Now I wish to put it in graphical form but this will have to wait, I have to understand how to do that in Eclipse.
Giovanni
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [LOG] RT 4.0 and NIL 2.0
Update:
- Added API to suspend/resume tracing of single trace event types.
Giovanni
- Added API to suspend/resume tracing of single trace event types.
Giovanni
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 62 guests