[Xenomai-core] Re: Test, benchmark, demo frameworks

2006-08-16 Thread Jan Kiszka
Jim Cromie wrote: Jan Kiszka wrote: ... So, how to proceed? aside wiki++ / 1 file at a time - I suppose.. I'll start by poaching Hannes' Makefile, bundling it into an examples/ dir with my 3-way version of his timer programs. Id like see the target files appear as 0 len files, (

[Xenomai-core] Time representation in RTDM profiles

2006-08-16 Thread Jan Kiszka
Hi all, the current representation of timeouts and timestamps in RTDM device profiles is inconsistent. In the serial profile we use [u]int64_t directly, the CAN profile defines its own types called nanosecs_{abs|rel}_t (though they just wrap the int64 ones). What is the idea of nanosecs? Having

[Xenomai-core] Re: Time representation in RTDM profiles

2006-08-16 Thread Jan Kiszka
Sebastian Smolorz wrote: Jan Kiszka wrote: the current representation of timeouts and timestamps in RTDM device profiles is inconsistent. I would welcome a consistent time value representation above all RTDM profiles, too. In the serial profile we use [u]int64_t directly, the CAN

[Xenomai-core] Re: Time representation in RTDM profiles

2006-08-16 Thread Sebastian Smolorz
Jan Kiszka wrote: Sebastian Smolorz wrote: The possibility of redefinition was not the main goal here. As you mentioned it would be problematic. No, I introduced nanosecs_abs_t and nanosecs_rel_t because they are more intuitive and more speaking to the programmer. The meaning of a

Re: [Xenomai-core] ksrc/driver refactoring

2006-08-16 Thread Klaas Gadeyne
I just wanted to drop a note that I did some refactoring on the drivers directory (16550A-serial) and the config menus. If anything is broken, shoot me. I don't think this is related, but 2 students of mine got stuck on a linker error this morning trying to compile xenomai-trunk on a i386

[Xenomai-core] Re: Time representation in RTDM profiles

2006-08-16 Thread Jan Kiszka
Sebastian Smolorz wrote: Jan Kiszka wrote: Sebastian Smolorz wrote: The possibility of redefinition was not the main goal here. As you mentioned it would be problematic. No, I introduced nanosecs_abs_t and nanosecs_rel_t because they are more intuitive and more speaking to the programmer.

Re: [Xenomai-core] ksrc/driver refactoring

2006-08-16 Thread Jan Kiszka
Klaas Gadeyne wrote: I just wanted to drop a note that I did some refactoring on the drivers directory (16550A-serial) and the config menus. If anything is broken, shoot me. I don't think this is related, but 2 students of mine got stuck on a linker error this morning trying to compile

Re: [Xenomai-core] [RFC][PATCH 4/4] shorten overrun loops of periodic timers

2006-08-16 Thread Jan Kiszka
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: A simple patch, just like suggested by Gilles, to avoid looping over periodic xntimer handlers in case of overruns. It saves the current TSC on loop entry and uses this

Re: [Xenomai-core] [RFC][PATCH 4/4] shorten overrun loops of periodic timers

2006-08-16 Thread Gilles Chanteperdrix
Jan Kiszka wrote: I am thinking again about this patch: some handlers need to be rewritten, for example the posix timers handler, because the handler relies on the fact that it is called for every timer expiry to compute the overruns count. So maybe this patch should come with the

[Xenomai-core] Re: Time representation in RTDM profiles

2006-08-16 Thread Sebastian Smolorz
Jan Kiszka wrote: Sebastian Smolorz wrote: Jan Kiszka wrote: Sebastian Smolorz wrote: The possibility of redefinition was not the main goal here. As you mentioned it would be problematic. No, I introduced nanosecs_abs_t and nanosecs_rel_t because they are more intuitive and more

Re: [Xenomai-core] Re: Time representation in RTDM profiles

2006-08-16 Thread Jan Kiszka
Sebastian Smolorz wrote: Jan Kiszka wrote: Sebastian Smolorz wrote: Jan Kiszka wrote: Sebastian Smolorz wrote: The possibility of redefinition was not the main goal here. As you mentioned it would be problematic. No, I introduced nanosecs_abs_t and nanosecs_rel_t because they are more