rt application question with rs232 communication

rt application question with rs232 communication

[Cliff Brake]

Hello,

I have an application where I do the following:

- PXA270 CPU
- communicating over serial ports on 40ms intervals
- communication scheme is very simple in that the linux system sends a
packet every 40ms and expects a response back within the 40ms window
- currently using 2.6.27 with CONFIG_PREEMPT

If I set the application comm thread to real time priority, the
sending works very well.  There is very little jitter in the 40ms send
timing.  However, it seems that the system has trouble receiving the
response in a timely fashion.  I often observe that it takes at least
10ms for the application to receive the response data after the data
has appeared on the rs232 bus.  Is the RT patch something that would
help speed up the serial receive response time, or is there something
else going on that I am missing?  The system is fairly busy with
graphical processing, but the sending is always right on schedule.

It seems that interrupts may be involved with this problem as when
sending, the send data is smaller than the FIFO size, and is probably
put into the fifo during the write, where with the read, an interrupt
needs to fire, etc.  Does all the kernel code that handles the serial
data automatically run at the calling application's RT priority, or is
there additional work required to make everything that touches the
data RT?

I'm also trying to figure out how well RT will work for CAN
communications.  Once again we have the same problem -- a RT user
space application needs to send and receive data with strict timing.
Which, I can make a RT thread in user space run well (toggle a gpio
with very little jitter), how does this translate to all the kernel
components involved in the socketcan stack (networking, etc) that need
to touch the data?

Thanks,
Cliff

-- 
=======================
Cliff Brake
http://bec-systems.com

Re: rt application question with rs232 communication

[Cliff Brake]

Clarification, I don't have the RT patch applied, just CONFIG_PREEMPT
from Linus's kernel.  Reviewing my notes from several years ago, I ran
into a similar issue and the RT patch fixed it, so now to figure out
the best way to get a recent RT patched ARM kernel ...

Cliff

On Mon, Mar 9, 2009 at 5:34 PM, Cliff Brake <cliff.brake@gmail.com> wrote:
> Hello,
>
> I have an application where I do the following:
>
> - PXA270 CPU
> - communicating over serial ports on 40ms intervals
> - communication scheme is very simple in that the linux system sends a
> packet every 40ms and expects a response back within the 40ms window
> - currently using 2.6.27 with CONFIG_PREEMPT
>
> If I set the application comm thread to real time priority, the
> sending works very well.  There is very little jitter in the 40ms send
> timing.  However, it seems that the system has trouble receiving the
> response in a timely fashion.  I often observe that it takes at least
> 10ms for the application to receive the response data after the data
> has appeared on the rs232 bus.  Is the RT patch something that would
> help speed up the serial receive response time, or is there something
> else going on that I am missing?  The system is fairly busy with
> graphical processing, but the sending is always right on schedule.
>
> It seems that interrupts may be involved with this problem as when
> sending, the send data is smaller than the FIFO size, and is probably
> put into the fifo during the write, where with the read, an interrupt
> needs to fire, etc.  Does all the kernel code that handles the serial
> data automatically run at the calling application's RT priority, or is
> there additional work required to make everything that touches the
> data RT?
>
> I'm also trying to figure out how well RT will work for CAN
> communications.  Once again we have the same problem -- a RT user
> space application needs to send and receive data with strict timing.
> Which, I can make a RT thread in user space run well (toggle a gpio
> with very little jitter), how does this translate to all the kernel
> components involved in the socketcan stack (networking, etc) that need
> to touch the data?
>
> Thanks,
> Cliff
>
> --
> =======================
> Cliff Brake
> http://bec-systems.com
>



-- 
=======================
Cliff Brake
http://bec-systems.com
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rt application question with rs232 communication

[Leon Woestenberg]

Hello Cliff,

On Tue, Mar 10, 2009 at 1:44 PM, Cliff Brake <cliff.brake@gmail.com> wrote:
> Clarification, I don't have the RT patch applied, just CONFIG_PREEMPT
> from Linus's kernel.  Reviewing my notes from several years ago, I ran
> into a similar issue and the RT patch fixed it, so now to figure out
> the best way to get a recent RT patched ARM kernel ...
>
>> timing.  However, it seems that the system has trouble receiving the
>> response in a timely fashion.  I often observe that it takes at least
>> 10ms for the application to receive the response data after the data
>> has appeared on the rs232 bus.  Is the RT patch something that would

We are running a real-time RS-485 protocol where the time window is 1
ms and only under heavy load we got deadline misses > 1 ms.
Unfortunately I didn't measure the max latency then, but 10 ms sounds
like excessive latency to me.

Under 2.6.24.7-rt24 (or whatever -rtxy in that series) we have never
missed the 1 ms deadline.

That's on XScale IXP4xx @533 MHz,

Regards,
-- 
Leon
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rt application question with rs232 communication

[Cliff Brake]

On Sat, Mar 14, 2009 at 10:07 PM, Leon Woestenberg
<leon.woestenberg@gmail.com> wrote:
> Hello Cliff,
>
> On Tue, Mar 10, 2009 at 1:44 PM, Cliff Brake <cliff.brake@gmail.com> wrote:
>> Clarification, I don't have the RT patch applied, just CONFIG_PREEMPT
>> from Linus's kernel.  Reviewing my notes from several years ago, I ran
>> into a similar issue and the RT patch fixed it, so now to figure out
>> the best way to get a recent RT patched ARM kernel ...
>>
>>> timing.  However, it seems that the system has trouble receiving the
>>> response in a timely fashion.  I often observe that it takes at least
>>> 10ms for the application to receive the response data after the data
>>> has appeared on the rs232 bus.  Is the RT patch something that would
>
> We are running a real-time RS-485 protocol where the time window is 1
> ms and only under heavy load we got deadline misses > 1 ms.
> Unfortunately I didn't measure the max latency then, but 10 ms sounds
> like excessive latency to me.
>
> Under 2.6.24.7-rt24 (or whatever -rtxy in that series) we have never
> missed the 1 ms deadline.

Thanks Leon.  I guess its pretty obvious at this point I need the RT
patch.  Still trying to figure out the best way to get this with
2.6.27 or later -- I really don't want to go back to 2.6.26.

Thanks,
Cliff

-- 
=======================
Cliff Brake
http://bec-systems.com
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html