[Xenomai-core] [forge] irqbench removal

[Xenomai-core] [forge] irqbench removal

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

Philippe,

irqbench does not inherently depend on a third I-pipe domain. It is a
useful testcase, the only in our portfolio that targets a peripheral
device use case. In fact, it was only of the first test cases for Native
RTDM IIRC.

Please revert the removal and then cut out only the few parts that
actually instantiate an additional domain (i.e. mode 3.

Thanks,
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: [Xenomai-core] [forge] irqbench removal

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Philippe,
> 
> irqbench does not inherently depend on a third I-pipe domain.

Yes, but it inherently depends on x86 too.

-- 
                                                                Gilles.

Re: [Xenomai-core] [forge] irqbench removal

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

Am 09.10.2010 15:29, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Philippe,
>>
>> irqbench does not inherently depend on a third I-pipe domain.
> 
> Yes, but it inherently depends on x86 too.

Not by design, just by missing contributions to add a few more I/O bindings.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: [Xenomai-core] [forge] irqbench removal

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Am 09.10.2010 15:29, Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Philippe,
>>>
>>> irqbench does not inherently depend on a third I-pipe domain.
>> Yes, but it inherently depends on x86 too.
> 
> Not by design, just by missing contributions to add a few more I/O bindings.

Currently it does not compile on anything else than x86. Denx has a
"gpioirqbench":
http://git.denx.de/?p=gpioirqbench.git;a=summary

Maybe it is time to find some common ground and have atlast a bench
which can run an all architectures ?

-- 
                                                                Gilles.

Re: [Xenomai-core] [forge] irqbench removal

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

Am 09.10.2010 15:35, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Am 09.10.2010 15:29, Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Philippe,
>>>>
>>>> irqbench does not inherently depend on a third I-pipe domain.
>>> Yes, but it inherently depends on x86 too.
>>
>> Not by design, just by missing contributions to add a few more I/O bindings.
> 
> Currently it does not compile on anything else than x86. Denx has a
> "gpioirqbench":
> http://git.denx.de/?p=gpioirqbench.git;a=summary
> 
> Maybe it is time to find some common ground and have atlast a bench
> which can run an all architectures ?
> 

No concerns.

Wolfgang, do you see a reasonable way to make the hardware interface
between host and target more compatible so that we could also use the
existing x86 measurement tool with your targets? That was my original
idea (to avoid the need for multiple embedded boards). Having a gpio
option also for the measurement host is nevertheless worthwhile.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: [Xenomai-core] [forge] irqbench removal

[Philippe Gerum]

On Sat, 2010-10-09 at 15:23 +0200, Jan Kiszka wrote:
> Philippe,
> 
> irqbench does not inherently depend on a third I-pipe domain. It is a
> useful testcase, the only in our portfolio that targets a peripheral
> device use case. In fact, it was only of the first test cases for Native
> RTDM IIRC.
> 
> Please revert the removal and then cut out only the few parts that
> actually instantiate an additional domain (i.e. mode 3.

So, what do we do with this? Any chance we move to arch-neutral code for
this test?

> 
> Thanks,
> Jan
> 

-- 
Philippe.

Re: [Xenomai-core] [forge] irqbench removal

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

Am 14.10.2010 17:42, Philippe Gerum wrote:
> On Sat, 2010-10-09 at 15:23 +0200, Jan Kiszka wrote:
>> Philippe,
>>
>> irqbench does not inherently depend on a third I-pipe domain. It is a
>> useful testcase, the only in our portfolio that targets a peripheral
>> device use case. In fact, it was only of the first test cases for Native
>> RTDM IIRC.
>>
>> Please revert the removal and then cut out only the few parts that
>> actually instantiate an additional domain (i.e. mode 3.
> 
> So, what do we do with this? Any chance we move to arch-neutral code for
> this test?

Arch-neutral is impossible due to the inherent hardware dependency. But
I'm waiting on some comments by Wolfgang on their work as that's
probably the best requirements source for multi-arch support.

For now the existing test should not cause any harm if cleaned up from
the domain stuff and not built on non-x86 archs (which is already
properly guarded for user space, the kernel driver may deserve an
additional dependency).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: [Xenomai-core] [forge] irqbench removal

[Philippe Gerum]

On Thu, 2010-10-14 at 18:10 +0200, Jan Kiszka wrote:
> Am 14.10.2010 17:42, Philippe Gerum wrote:
> > On Sat, 2010-10-09 at 15:23 +0200, Jan Kiszka wrote:
> >> Philippe,
> >>
> >> irqbench does not inherently depend on a third I-pipe domain. It is a
> >> useful testcase, the only in our portfolio that targets a peripheral
> >> device use case. In fact, it was only of the first test cases for Native
> >> RTDM IIRC.
> >>
> >> Please revert the removal and then cut out only the few parts that
> >> actually instantiate an additional domain (i.e. mode 3.
> > 
> > So, what do we do with this? Any chance we move to arch-neutral code for
> > this test?
> 
> Arch-neutral is impossible due to the inherent hardware dependency. But
> I'm waiting on some comments by Wolfgang on their work as that's
> probably the best requirements source for multi-arch support.

I mean that the bulk of the code could be made arch-neutral, with only
callouts to solve the arch-dependent/uart issues. Typically, 16550's are
not uncommon on powerpc, but we obviously don't program them via
ioports. A second level of indirection could provide the entire chip
handling, to fit other uarts, maybe?

> 
> For now the existing test should not cause any harm if cleaned up from
> the domain stuff and not built on non-x86 archs (which is already
> properly guarded for user space, the kernel driver may deserve an
> additional dependency).
> 
> Jan
> 

-- 
Philippe.

Re: [Xenomai-core] [forge] irqbench removal

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]

Am 14.10.2010 18:16, Philippe Gerum wrote:
> On Thu, 2010-10-14 at 18:10 +0200, Jan Kiszka wrote:
>> Am 14.10.2010 17:42, Philippe Gerum wrote:
>>> On Sat, 2010-10-09 at 15:23 +0200, Jan Kiszka wrote:
>>>> Philippe,
>>>>
>>>> irqbench does not inherently depend on a third I-pipe domain. It is a
>>>> useful testcase, the only in our portfolio that targets a peripheral
>>>> device use case. In fact, it was only of the first test cases for Native
>>>> RTDM IIRC.
>>>>
>>>> Please revert the removal and then cut out only the few parts that
>>>> actually instantiate an additional domain (i.e. mode 3.
>>>
>>> So, what do we do with this? Any chance we move to arch-neutral code for
>>> this test?
>>
>> Arch-neutral is impossible due to the inherent hardware dependency. But
>> I'm waiting on some comments by Wolfgang on their work as that's
>> probably the best requirements source for multi-arch support.
> 
> I mean that the bulk of the code could be made arch-neutral, with only
> callouts to solve the arch-dependent/uart issues. Typically, 16550's are
> not uncommon on powerpc, but we obviously don't program them via
> ioports. A second level of indirection could provide the entire chip
> handling, to fit other uarts, maybe?

If there are suitable UARTs around, refactoring the code accordingly and
maybe adding support for one of them as reference would be a good next
step. But first I would like to understand (or recall - I think Wolfgang
once explained it) the motivations for not going this path with the
gpiobench test and learn its requirements to avoid doing refactorings
twice or more.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: [Xenomai-core] [forge] irqbench removal

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3153 bytes --]

Am 14.10.2010 20:13, Wolfgang Grandegger wrote:
> Hi Jan,
> 
> On 10/14/2010 07:55 PM, Jan Kiszka wrote:
>> Am 14.10.2010 18:16, Philippe Gerum wrote:
>>> On Thu, 2010-10-14 at 18:10 +0200, Jan Kiszka wrote:
>>>> Am 14.10.2010 17:42, Philippe Gerum wrote:
>>>>> On Sat, 2010-10-09 at 15:23 +0200, Jan Kiszka wrote:
>>>>>> Philippe,
>>>>>>
>>>>>> irqbench does not inherently depend on a third I-pipe domain. It is a
>>>>>> useful testcase, the only in our portfolio that targets a peripheral
>>>>>> device use case. In fact, it was only of the first test cases for Native
>>>>>> RTDM IIRC.
>>>>>>
>>>>>> Please revert the removal and then cut out only the few parts that
>>>>>> actually instantiate an additional domain (i.e. mode 3.
>>>>>
>>>>> So, what do we do with this? Any chance we move to arch-neutral code for
>>>>> this test?
>>>>
>>>> Arch-neutral is impossible due to the inherent hardware dependency. But
>>>> I'm waiting on some comments by Wolfgang on their work as that's
>>>> probably the best requirements source for multi-arch support.
>>>
>>> I mean that the bulk of the code could be made arch-neutral, with only
>>> callouts to solve the arch-dependent/uart issues. Typically, 16550's are
>>> not uncommon on powerpc, but we obviously don't program them via
>>> ioports. A second level of indirection could provide the entire chip
>>> handling, to fit other uarts, maybe?
>>
>> If there are suitable UARTs around, refactoring the code accordingly and
>> maybe adding support for one of them as reference would be a good next
>> step. But first I would like to understand (or recall - I think Wolfgang
>> once explained it) the motivations for not going this path with the
>> gpiobench test and learn its requirements to avoid doing refactorings
>> twice or more.
> 
> Well, it's a long time ago that I wrote gpioirqbench, which is derived
> from Jan's irqbench. Obviously, it uses GPIO pins to signal events
> instead of signals from the parallel port or serial line. I never
> supported the serial line for embedded boards.

What was the reason? That it is too often blocked by a terminal?

> You can get the code with:
> 
>   $ git clone git://git.denx.de/gpioirqbench
> 
> It uses a simple hw abstruction layer defined in target/gpioirq-hw.h:
> 
> http://git.denx.de/?p=gpioirqbench.git;a=blob;f=target/gpioirq-hw.h;h=76849da0964c7dbb6831fe02374922dcf89b3bb1;hb=HEAD

Is this abstracting the target side, right?

> 
> Don't know if it's generic enough to support the parallel and serial
> port interface as well. Anyway, with working generic GPIO lib support,
> it's quite simple to support new hardware, e.g. i.MX31 boards.
> 
> The host side to measure precisely the latency is even more tricky.

Depends. If you can map the GPIO output on something RS232 or parallel
port compatible, you are done. Usually, there is always some x86 box
around with one of those ports, even in 2010. Would it make sense to
specify the electrical interface between host and target accordingly?
That would allow to concentrate on the target, the more interesting part.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: [Xenomai-core] [forge] irqbench removal

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 4394 bytes --]

Am 14.10.2010 21:26, Wolfgang Grandegger wrote:
> On 10/14/2010 09:03 PM, Jan Kiszka wrote:
>> Am 14.10.2010 20:13, Wolfgang Grandegger wrote:
>>> Hi Jan,
>>>
>>> On 10/14/2010 07:55 PM, Jan Kiszka wrote:
>>>> Am 14.10.2010 18:16, Philippe Gerum wrote:
>>>>> On Thu, 2010-10-14 at 18:10 +0200, Jan Kiszka wrote:
>>>>>> Am 14.10.2010 17:42, Philippe Gerum wrote:
>>>>>>> On Sat, 2010-10-09 at 15:23 +0200, Jan Kiszka wrote:
>>>>>>>> Philippe,
>>>>>>>>
>>>>>>>> irqbench does not inherently depend on a third I-pipe domain. It is a
>>>>>>>> useful testcase, the only in our portfolio that targets a peripheral
>>>>>>>> device use case. In fact, it was only of the first test cases for Native
>>>>>>>> RTDM IIRC.
>>>>>>>>
>>>>>>>> Please revert the removal and then cut out only the few parts that
>>>>>>>> actually instantiate an additional domain (i.e. mode 3.
>>>>>>>
>>>>>>> So, what do we do with this? Any chance we move to arch-neutral code for
>>>>>>> this test?
>>>>>>
>>>>>> Arch-neutral is impossible due to the inherent hardware dependency. But
>>>>>> I'm waiting on some comments by Wolfgang on their work as that's
>>>>>> probably the best requirements source for multi-arch support.
>>>>>
>>>>> I mean that the bulk of the code could be made arch-neutral, with only
>>>>> callouts to solve the arch-dependent/uart issues. Typically, 16550's are
>>>>> not uncommon on powerpc, but we obviously don't program them via
>>>>> ioports. A second level of indirection could provide the entire chip
>>>>> handling, to fit other uarts, maybe?
>>>>
>>>> If there are suitable UARTs around, refactoring the code accordingly and
>>>> maybe adding support for one of them as reference would be a good next
>>>> step. But first I would like to understand (or recall - I think Wolfgang
>>>> once explained it) the motivations for not going this path with the
>>>> gpiobench test and learn its requirements to avoid doing refactorings
>>>> twice or more.
>>>
>>> Well, it's a long time ago that I wrote gpioirqbench, which is derived
>>> from Jan's irqbench. Obviously, it uses GPIO pins to signal events
>>> instead of signals from the parallel port or serial line. I never
>>> supported the serial line for embedded boards.
>>
>> What was the reason? That it is too often blocked by a terminal?
> 
> Mainly because there is no RTserial driver for the serial interface on
> the embedded boards, e.g. for the PSC, SCC. Furthermore, they are
> usually handled by firmware with ring buffers, dma, etc. which would
> introduce additional delays. They might be negligible, though.
> 
>>> You can get the code with:
>>>
>>>   $ git clone git://git.denx.de/gpioirqbench
>>>
>>> It uses a simple hw abstruction layer defined in target/gpioirq-hw.h:
>>>
>>> http://git.denx.de/?p=gpioirqbench.git;a=blob;f=target/gpioirq-hw.h;h=76849da0964c7dbb6831fe02374922dcf89b3bb1;hb=HEAD
>>
>> Is this abstracting the target side, right?
> 
> Yep.
> 
>>> Don't know if it's generic enough to support the parallel and serial
>>> port interface as well. Anyway, with working generic GPIO lib support,
>>> it's quite simple to support new hardware, e.g. i.MX31 boards.
>>>
>>> The host side to measure precisely the latency is even more tricky.
>>
>> Depends. If you can map the GPIO output on something RS232 or parallel
>> port compatible, you are done. Usually, there is always some x86 box
> 
> THe GPIO lines of most embedded boards don't like 5V. The are specified
> for 3.3V plus something less than 5V. I was thinking about that already
> but finally didn't want to damage the board. A 3.3V serial interface on
> the PC would be fine, though.

Sounds like we just need a voltage divider for RS232 -> GPIO. The other
way should be fine as everything above 3 V is considered High, and I
think to remember that even the invalid range of +/-3 V is reported as
Low by typical (PC-)UARTs.

But even if it takes more, maybe some optic couplers, I think it's worth
developing some reference adapter and focusing on RS232 for the host
side for the next steps.

Jan

> 
>> around with one of those ports, even in 2010. Would it make sense to
>> specify the electrical interface between host and target accordingly?
>> That would allow to concentrate on the target, the more interesting part.
> 
> See above.
> 
> Wolfgang.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: [Xenomai-core] [forge] irqbench removal

[Wolfgang Grandegger]

On 10/15/2010 08:39 AM, Jan Kiszka wrote:
> Am 14.10.2010 21:26, Wolfgang Grandegger wrote:
>> On 10/14/2010 09:03 PM, Jan Kiszka wrote:
>>> Am 14.10.2010 20:13, Wolfgang Grandegger wrote:
>>>> Hi Jan,
>>>>
>>>> On 10/14/2010 07:55 PM, Jan Kiszka wrote:
>>>>> Am 14.10.2010 18:16, Philippe Gerum wrote:
>>>>>> On Thu, 2010-10-14 at 18:10 +0200, Jan Kiszka wrote:
>>>>>>> Am 14.10.2010 17:42, Philippe Gerum wrote:
>>>>>>>> On Sat, 2010-10-09 at 15:23 +0200, Jan Kiszka wrote:
>>>>>>>>> Philippe,
>>>>>>>>>
>>>>>>>>> irqbench does not inherently depend on a third I-pipe domain. It is a
>>>>>>>>> useful testcase, the only in our portfolio that targets a peripheral
>>>>>>>>> device use case. In fact, it was only of the first test cases for Native
>>>>>>>>> RTDM IIRC.
>>>>>>>>>
>>>>>>>>> Please revert the removal and then cut out only the few parts that
>>>>>>>>> actually instantiate an additional domain (i.e. mode 3.
>>>>>>>>
>>>>>>>> So, what do we do with this? Any chance we move to arch-neutral code for
>>>>>>>> this test?
>>>>>>>
>>>>>>> Arch-neutral is impossible due to the inherent hardware dependency. But
>>>>>>> I'm waiting on some comments by Wolfgang on their work as that's
>>>>>>> probably the best requirements source for multi-arch support.
>>>>>>
>>>>>> I mean that the bulk of the code could be made arch-neutral, with only
>>>>>> callouts to solve the arch-dependent/uart issues. Typically, 16550's are
>>>>>> not uncommon on powerpc, but we obviously don't program them via
>>>>>> ioports. A second level of indirection could provide the entire chip
>>>>>> handling, to fit other uarts, maybe?
>>>>>
>>>>> If there are suitable UARTs around, refactoring the code accordingly and
>>>>> maybe adding support for one of them as reference would be a good next
>>>>> step. But first I would like to understand (or recall - I think Wolfgang
>>>>> once explained it) the motivations for not going this path with the
>>>>> gpiobench test and learn its requirements to avoid doing refactorings
>>>>> twice or more.
>>>>
>>>> Well, it's a long time ago that I wrote gpioirqbench, which is derived
>>>> from Jan's irqbench. Obviously, it uses GPIO pins to signal events
>>>> instead of signals from the parallel port or serial line. I never
>>>> supported the serial line for embedded boards.
>>>
>>> What was the reason? That it is too often blocked by a terminal?
>>
>> Mainly because there is no RTserial driver for the serial interface on
>> the embedded boards, e.g. for the PSC, SCC. Furthermore, they are
>> usually handled by firmware with ring buffers, dma, etc. which would
>> introduce additional delays. They might be negligible, though.
>>
>>>> You can get the code with:
>>>>
>>>>   $ git clone git://git.denx.de/gpioirqbench
>>>>
>>>> It uses a simple hw abstruction layer defined in target/gpioirq-hw.h:
>>>>
>>>> http://git.denx.de/?p=gpioirqbench.git;a=blob;f=target/gpioirq-hw.h;h=76849da0964c7dbb6831fe02374922dcf89b3bb1;hb=HEAD
>>>
>>> Is this abstracting the target side, right?
>>
>> Yep.
>>
>>>> Don't know if it's generic enough to support the parallel and serial
>>>> port interface as well. Anyway, with working generic GPIO lib support,
>>>> it's quite simple to support new hardware, e.g. i.MX31 boards.
>>>>
>>>> The host side to measure precisely the latency is even more tricky.
>>>
>>> Depends. If you can map the GPIO output on something RS232 or parallel
>>> port compatible, you are done. Usually, there is always some x86 box
>>
>> THe GPIO lines of most embedded boards don't like 5V. The are specified
>> for 3.3V plus something less than 5V. I was thinking about that already
>> but finally didn't want to damage the board. A 3.3V serial interface on
>> the PC would be fine, though.
> 
> Sounds like we just need a voltage divider for RS232 -> GPIO. The other
> way should be fine as everything above 3 V is considered High, and I
> think to remember that even the invalid range of +/-3 V is reported as
> Low by typical (PC-)UARTs.

I just googled around a bit and found:

  http://www.rs232-converters.com/rs232-to_ttl3.3_converters.htm

That should allow to overcome the hardware limitation.

> But even if it takes more, maybe some optic couplers, I think it's worth
> developing some reference adapter and focusing on RS232 for the host
> side for the next steps.

I agree.

Wolfgang.

Re: [Xenomai-core] [forge] irqbench removal

[Wolfgang Grandegger]

On 10/15/2010 01:07 PM, Wolfgang Grandegger wrote:
> On 10/15/2010 08:39 AM, Jan Kiszka wrote:
>> Am 14.10.2010 21:26, Wolfgang Grandegger wrote:
>>> On 10/14/2010 09:03 PM, Jan Kiszka wrote:
>>>> Am 14.10.2010 20:13, Wolfgang Grandegger wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On 10/14/2010 07:55 PM, Jan Kiszka wrote:
>>>>>> Am 14.10.2010 18:16, Philippe Gerum wrote:
>>>>>>> On Thu, 2010-10-14 at 18:10 +0200, Jan Kiszka wrote:
>>>>>>>> Am 14.10.2010 17:42, Philippe Gerum wrote:
>>>>>>>>> On Sat, 2010-10-09 at 15:23 +0200, Jan Kiszka wrote:
>>>>>>>>>> Philippe,
>>>>>>>>>>
>>>>>>>>>> irqbench does not inherently depend on a third I-pipe domain. It is a
>>>>>>>>>> useful testcase, the only in our portfolio that targets a peripheral
>>>>>>>>>> device use case. In fact, it was only of the first test cases for Native
>>>>>>>>>> RTDM IIRC.
>>>>>>>>>>
>>>>>>>>>> Please revert the removal and then cut out only the few parts that
>>>>>>>>>> actually instantiate an additional domain (i.e. mode 3.
>>>>>>>>>
>>>>>>>>> So, what do we do with this? Any chance we move to arch-neutral code for
>>>>>>>>> this test?
>>>>>>>>
>>>>>>>> Arch-neutral is impossible due to the inherent hardware dependency. But
>>>>>>>> I'm waiting on some comments by Wolfgang on their work as that's
>>>>>>>> probably the best requirements source for multi-arch support.
>>>>>>>
>>>>>>> I mean that the bulk of the code could be made arch-neutral, with only
>>>>>>> callouts to solve the arch-dependent/uart issues. Typically, 16550's are
>>>>>>> not uncommon on powerpc, but we obviously don't program them via
>>>>>>> ioports. A second level of indirection could provide the entire chip
>>>>>>> handling, to fit other uarts, maybe?
>>>>>>
>>>>>> If there are suitable UARTs around, refactoring the code accordingly and
>>>>>> maybe adding support for one of them as reference would be a good next
>>>>>> step. But first I would like to understand (or recall - I think Wolfgang
>>>>>> once explained it) the motivations for not going this path with the
>>>>>> gpiobench test and learn its requirements to avoid doing refactorings
>>>>>> twice or more.
>>>>>
>>>>> Well, it's a long time ago that I wrote gpioirqbench, which is derived
>>>>> from Jan's irqbench. Obviously, it uses GPIO pins to signal events
>>>>> instead of signals from the parallel port or serial line. I never
>>>>> supported the serial line for embedded boards.
>>>>
>>>> What was the reason? That it is too often blocked by a terminal?
>>>
>>> Mainly because there is no RTserial driver for the serial interface on
>>> the embedded boards, e.g. for the PSC, SCC. Furthermore, they are
>>> usually handled by firmware with ring buffers, dma, etc. which would
>>> introduce additional delays. They might be negligible, though.
>>>
>>>>> You can get the code with:
>>>>>
>>>>>   $ git clone git://git.denx.de/gpioirqbench
>>>>>
>>>>> It uses a simple hw abstruction layer defined in target/gpioirq-hw.h:
>>>>>
>>>>> http://git.denx.de/?p=gpioirqbench.git;a=blob;f=target/gpioirq-hw.h;h=76849da0964c7dbb6831fe02374922dcf89b3bb1;hb=HEAD
>>>>
>>>> Is this abstracting the target side, right?
>>>
>>> Yep.
>>>
>>>>> Don't know if it's generic enough to support the parallel and serial
>>>>> port interface as well. Anyway, with working generic GPIO lib support,
>>>>> it's quite simple to support new hardware, e.g. i.MX31 boards.
>>>>>
>>>>> The host side to measure precisely the latency is even more tricky.
>>>>
>>>> Depends. If you can map the GPIO output on something RS232 or parallel
>>>> port compatible, you are done. Usually, there is always some x86 box
>>>
>>> THe GPIO lines of most embedded boards don't like 5V. The are specified
>>> for 3.3V plus something less than 5V. I was thinking about that already
>>> but finally didn't want to damage the board. A 3.3V serial interface on
>>> the PC would be fine, though.
>>
>> Sounds like we just need a voltage divider for RS232 -> GPIO. The other
>> way should be fine as everything above 3 V is considered High, and I
>> think to remember that even the invalid range of +/-3 V is reported as
>> Low by typical (PC-)UARTs.
> 
> I just googled around a bit and found:
> 
>   http://www.rs232-converters.com/rs232-to_ttl3.3_converters.htm

Or at ebay: http://shop.ebay.at/i.html?_kw=ttl&_kw=converter

Wolfgang.

Re: [Xenomai-core] [forge] irqbench removal

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 4769 bytes --]

Am 15.10.2010 14:47, Wolfgang Grandegger wrote:
> On 10/15/2010 01:07 PM, Wolfgang Grandegger wrote:
>> On 10/15/2010 08:39 AM, Jan Kiszka wrote:
>>> Am 14.10.2010 21:26, Wolfgang Grandegger wrote:
>>>> On 10/14/2010 09:03 PM, Jan Kiszka wrote:
>>>>> Am 14.10.2010 20:13, Wolfgang Grandegger wrote:
>>>>>> Hi Jan,
>>>>>>
>>>>>> On 10/14/2010 07:55 PM, Jan Kiszka wrote:
>>>>>>> Am 14.10.2010 18:16, Philippe Gerum wrote:
>>>>>>>> On Thu, 2010-10-14 at 18:10 +0200, Jan Kiszka wrote:
>>>>>>>>> Am 14.10.2010 17:42, Philippe Gerum wrote:
>>>>>>>>>> On Sat, 2010-10-09 at 15:23 +0200, Jan Kiszka wrote:
>>>>>>>>>>> Philippe,
>>>>>>>>>>>
>>>>>>>>>>> irqbench does not inherently depend on a third I-pipe domain. It is a
>>>>>>>>>>> useful testcase, the only in our portfolio that targets a peripheral
>>>>>>>>>>> device use case. In fact, it was only of the first test cases for Native
>>>>>>>>>>> RTDM IIRC.
>>>>>>>>>>>
>>>>>>>>>>> Please revert the removal and then cut out only the few parts that
>>>>>>>>>>> actually instantiate an additional domain (i.e. mode 3.
>>>>>>>>>>
>>>>>>>>>> So, what do we do with this? Any chance we move to arch-neutral code for
>>>>>>>>>> this test?
>>>>>>>>>
>>>>>>>>> Arch-neutral is impossible due to the inherent hardware dependency. But
>>>>>>>>> I'm waiting on some comments by Wolfgang on their work as that's
>>>>>>>>> probably the best requirements source for multi-arch support.
>>>>>>>>
>>>>>>>> I mean that the bulk of the code could be made arch-neutral, with only
>>>>>>>> callouts to solve the arch-dependent/uart issues. Typically, 16550's are
>>>>>>>> not uncommon on powerpc, but we obviously don't program them via
>>>>>>>> ioports. A second level of indirection could provide the entire chip
>>>>>>>> handling, to fit other uarts, maybe?
>>>>>>>
>>>>>>> If there are suitable UARTs around, refactoring the code accordingly and
>>>>>>> maybe adding support for one of them as reference would be a good next
>>>>>>> step. But first I would like to understand (or recall - I think Wolfgang
>>>>>>> once explained it) the motivations for not going this path with the
>>>>>>> gpiobench test and learn its requirements to avoid doing refactorings
>>>>>>> twice or more.
>>>>>>
>>>>>> Well, it's a long time ago that I wrote gpioirqbench, which is derived
>>>>>> from Jan's irqbench. Obviously, it uses GPIO pins to signal events
>>>>>> instead of signals from the parallel port or serial line. I never
>>>>>> supported the serial line for embedded boards.
>>>>>
>>>>> What was the reason? That it is too often blocked by a terminal?
>>>>
>>>> Mainly because there is no RTserial driver for the serial interface on
>>>> the embedded boards, e.g. for the PSC, SCC. Furthermore, they are
>>>> usually handled by firmware with ring buffers, dma, etc. which would
>>>> introduce additional delays. They might be negligible, though.
>>>>
>>>>>> You can get the code with:
>>>>>>
>>>>>>   $ git clone git://git.denx.de/gpioirqbench
>>>>>>
>>>>>> It uses a simple hw abstruction layer defined in target/gpioirq-hw.h:
>>>>>>
>>>>>> http://git.denx.de/?p=gpioirqbench.git;a=blob;f=target/gpioirq-hw.h;h=76849da0964c7dbb6831fe02374922dcf89b3bb1;hb=HEAD
>>>>>
>>>>> Is this abstracting the target side, right?
>>>>
>>>> Yep.
>>>>
>>>>>> Don't know if it's generic enough to support the parallel and serial
>>>>>> port interface as well. Anyway, with working generic GPIO lib support,
>>>>>> it's quite simple to support new hardware, e.g. i.MX31 boards.
>>>>>>
>>>>>> The host side to measure precisely the latency is even more tricky.
>>>>>
>>>>> Depends. If you can map the GPIO output on something RS232 or parallel
>>>>> port compatible, you are done. Usually, there is always some x86 box
>>>>
>>>> THe GPIO lines of most embedded boards don't like 5V. The are specified
>>>> for 3.3V plus something less than 5V. I was thinking about that already
>>>> but finally didn't want to damage the board. A 3.3V serial interface on
>>>> the PC would be fine, though.
>>>
>>> Sounds like we just need a voltage divider for RS232 -> GPIO. The other
>>> way should be fine as everything above 3 V is considered High, and I
>>> think to remember that even the invalid range of +/-3 V is reported as
>>> Low by typical (PC-)UARTs.
>>
>> I just googled around a bit and found:
>>
>>   http://www.rs232-converters.com/rs232-to_ttl3.3_converters.htm
> 
> Or at ebay: http://shop.ebay.at/i.html?_kw=ttl&_kw=converter
> 

Look perfect on first sight - but not on second: They all convert RX/TX,
but we need status line conversions. So you need at least some re-wiring
via a breakout box a special cable. Still, it's a good base to build upon.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]