[LOG] RT 4.0 and NIL 2.0
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: [LOG] RT 4.0 and NIL 2.0
acr wrote:why not make osal part of os?
Could you clarify?
Currently OSAL is part of HAL because it interfaces the HAL to an operating system.
Re: [LOG] RT 4.0 and NIL 2.0
why not make os and hal compatible without middle layer?
and do not try to port hal to other rtos, other rtos's have self hal
and do not try to port hal to other rtos, other rtos's have self hal
Re: [LOG] RT 4.0 and NIL 2.0
Not each of them have hal, and this way it is possible to port.
Osal for RT and NIL as far as I understand cost's nothing with code optimization.
Osal for RT and NIL as far as I understand cost's nothing with code optimization.
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: [LOG] RT 4.0 and NIL 2.0
Anubirux wrote:Not each of them have hal, and this way it is possible to port.
Osal for RT and NIL as far as I understand cost's nothing with code optimization.
Exactly, the OSAL API is pretty close to the native RT/NIL API so there is no real overhead when using one of our RTOSes.
The purpose of the OSAL is not much to allow other RTOSes (which is still an option but not exactly on top of my priorities
Giovanni
Re: [LOG] RT 4.0 and NIL 2.0
what you think about split hal in two layer, first low layer (like hal port) not just may be used without os, but even not depend on os, just a try to implement abstraction to core devices
and level two hal that use first level and os interface to implement high level hal
and both level can be usable from application level
currently it not good idea to use hal_ll functions from hal?
and level two hal that use first level and os interface to implement high level hal
and both level can be usable from application level
currently it not good idea to use hal_ll functions from hal?
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: [LOG] RT 4.0 and NIL 2.0
More:
- Improved core and heap allocators, now it is possible to request blocks aligned to arbitrary powers of two.
for Example:
It is not finished yet, I need to add a "realloc" function and complete test coverage, it is buggy right now.
This is in preparation of next steps.
Giovanni
- Improved core and heap allocators, now it is possible to request blocks aligned to arbitrary powers of two.
for Example:
Code: Select all
/* Allocates 256 bytes ensuring that the block is aligned to a 32 bytes
boundary.*/
p = chHeapAllocateAligned(NULL, 256, 32);
It is not finished yet, I need to add a "realloc" function and complete test coverage, it is buggy right now.
This is in preparation of next steps.
Giovanni
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: [LOG] RT 4.0 and NIL 2.0
News:
- Now it is possible to get the size, in bytes, of allocated blocks. This makes possible an implementation of realloc().
- Modified chHeapStatus() to return also the largest available contiguous block, not just the total fragmented memory.
- Removed dynamic API. It is possible to do dynamic threading without explicit support. I plan to add it back as a library module. The kernel is now much more compact, faster and takes less RAM.
- Removed Thread termination API, the same result can be achieved in a variety of ways: events, shared boolean flags etc.
Code looks stable now, the test suite passes on an STM32F7xx.
Giovanni
- Now it is possible to get the size, in bytes, of allocated blocks. This makes possible an implementation of realloc().
Code: Select all
size_t size = chHeapGetSize(p);- Modified chHeapStatus() to return also the largest available contiguous block, not just the total fragmented memory.
Code: Select all
size_t n, total, largest;
n = chHeapStatus(&heap, &total, &largest);
- Removed dynamic API. It is possible to do dynamic threading without explicit support. I plan to add it back as a library module. The kernel is now much more compact, faster and takes less RAM.
- Removed Thread termination API, the same result can be achieved in a variety of ways: events, shared boolean flags etc.
Code looks stable now, the test suite passes on an STM32F7xx.
Giovanni
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: [LOG] RT 4.0 and NIL 2.0
News:
- New threading API added.
Example:
Note that it takes less space because parameters are statically placed as constant and it is much faster because less parameters to load and less registers to stack on entry of the function.
There are several variants:
The good old chThdCreateStatic() is kept for backward compatibility.
Giovanni
- New threading API added.
Example:
Code: Select all
{
static const thread_descriptor_t idle_descriptor = {
"idle",
THD_WORKING_AREA_BASE(ch.idle_thread_wa),
THD_WORKING_AREA_END(ch.idle_thread_wa),
IDLEPRIO,
_idle_thread,
NULL
};
/* This thread has the lowest priority in the system, its role is just to
serve interrupts in its context while keeping the lowest energy saving
mode compatible with the system status.*/
(void) chThdCreate(&idle_descriptor);
}
Note that it takes less space because parameters are statically placed as constant and it is much faster because less parameters to load and less registers to stack on entry of the function.
There are several variants:
Code: Select all
thread_t *chThdCreateSuspendedI(const thread_descriptor_t *tdp);
thread_t *chThdCreateSuspended(const thread_descriptor_t *tdp);
thread_t *chThdCreateI(const thread_descriptor_t *tdp);
thread_t *chThdCreate(const thread_descriptor_t *tdp);
thread_t *chThdCreateStatic(void *wsp, size_t size,
tprio_t prio, tfunc_t pf, void *arg);
The good old chThdCreateStatic() is kept for backward compatibility.
Giovanni
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: [LOG] RT 4.0 and NIL 2.0
News:
- chmboxes, chmemcore, chmempools, chheap are now share modules, both RT and NIL can use them. Functionality is the same.
I am still deciding if remove chqueues or make it a shared module. HAL contains already the very same code and it is pretty much a duplication, duplication is evil.
Giovanni
- chmboxes, chmemcore, chmempools, chheap are now share modules, both RT and NIL can use them. Functionality is the same.
I am still deciding if remove chqueues or make it a shared module. HAL contains already the very same code and it is pretty much a duplication, duplication is evil.
Giovanni