Do you have a question? Post it now! No Registration Necessary
Subject
- Posted on
fastest approach?
- 04-12-2005
- Little.Horse
April 12, 2005, 3:16 am

Hello,
We have a requirement to read data from serial port ( ie RS232 ) , then do
some simple calculation and finally write to io port ( ie LCD driver ).
Since time is critical or very limited, we are wondering there have any good
approach for this. As such, I need you input about what I thought:
(1) Change the Serial Port Driver a little bit
(2) When message received, then do some calculation and write to IO port.
Is above approach faster than write a program in user mode to read RS232 and
then write to IO port?
Any idea? Thanks in Advance,
Derek
We have a requirement to read data from serial port ( ie RS232 ) , then do
some simple calculation and finally write to io port ( ie LCD driver ).
Since time is critical or very limited, we are wondering there have any good
approach for this. As such, I need you input about what I thought:
(1) Change the Serial Port Driver a little bit
(2) When message received, then do some calculation and write to IO port.
Is above approach faster than write a program in user mode to read RS232 and
then write to IO port?
Any idea? Thanks in Advance,
Derek

Re: fastest approach?

How critical? How much time do you have?

I assume you propose to do (2) in the serial driver?

Possibly. It's also far more difficult to develop --
particularly if you have to do floating point.
I would suggest implimenting it the easy way first: use a
user-mode program. Remember to enable the low_latency option
on the serial port. You might also want to have a look at
POSIX real-time scheduling options. You might also want to
disable the rx FIFO to reduce latency.
--
Grant Edwards grante Yow! What's the MATTER
at Sid?... Is your BEVERAGE
Grant Edwards grante Yow! What's the MATTER
at Sid?... Is your BEVERAGE
We've slightly trimmed the long signature. Click to see the full one.

Re: fastest approach?
user mode, a lot of context switching or library accessing may not be
efficient. As such, I am wondering if I build this kind of application logic
in driver ( and in Kernel mode ) for better performance....
Any idea? Will this be faster?
Little Horse!


Re: fastest approach?
: Yes, but since time is pretty critical, we need to do it fast. I mean if in
: user mode, a lot of context switching or library accessing may not be
: efficient. As such, I am wondering if I build this kind of application logic
: in driver ( and in Kernel mode ) for better performance....
: Any idea? Will this be faster?
maybe I misunderstand but after the calculation to are writing this to
an LCD? To be read by a human, and something is here is so time critical
that human reaction/perception time doesn't swamp?
: Little Horse!
: > The traditional and proved Linux way is do the drivers as small and easy
: > as possible for just a single hardware device, and do calculations and
: > transport from one driver to another in a user mode program.
: >
: > -Michael
: user mode, a lot of context switching or library accessing may not be
: efficient. As such, I am wondering if I build this kind of application logic
: in driver ( and in Kernel mode ) for better performance....
: Any idea? Will this be faster?
maybe I misunderstand but after the calculation to are writing this to
an LCD? To be read by a human, and something is here is so time critical
that human reaction/perception time doesn't swamp?
: Little Horse!
: > The traditional and proved Linux way is do the drivers as small and easy
: > as possible for just a single hardware device, and do calculations and
: > transport from one driver to another in a user mode program.
: >
: > -Michael

Re: fastest approach?

Ah, you were speaking of run time (latency). I thought you were talking
about your limited working time and I suggested the least critical
alternative :-) .
Please pay attention that Linux is by no means a realtime system. Of
course in the Kernel (driver) you will have less _average_ latency than
in a user program, but even in the Kernel there is absolutely no
guarantee that any completion time is hit. Now and again, your event
can be delayed by other Kernel operations that block the scheduling for
a very long time.
If you really need to be "fast" I suggest taking a look at RTAI. Here
you can do programs (not really just drivers) that do work in a realtime
(predictable) way. Nonetheless the RTAI programs can communicate with
the Linux installed on top of RTAI and thus you can make use of all
Linux benefits (in a non-realtime way).
>I mean if in

Right. RTAI does exactly this.
-Michael

Re: fastest approach?

HOW FAST?

HOW FAST DOES IT NEED TO BE?

Yes, it will be faster. It will also be much harder to develop
and test.
--
Grant Edwards grante Yow! Somewhere in Tenafly,
at New Jersey, a chiropractor
Grant Edwards grante Yow! Somewhere in Tenafly,
at New Jersey, a chiropractor
We've slightly trimmed the long signature. Click to see the full one.

Re: fastest approach?

1.
IIRC, a serial port chip usu. transmits/receives at up to 115200 bits
per second (~10 Kbytes per second -> one byte in 100 microseconds).
Best RS485 chips -- at 1M Byte per second (1 byte in one microsecond).
2.
Writing _a pixel_ to convensional LCDs will take several microseconds.
;-)

Re: fastest approach?

Which is completely immaterial if the baud rate is required to be
9600 baud.

Why? Don't LCD controller have frame buffers?
--
Grant Edwards grante Yow! Are you guys lined up
at for the METHADONE PROGRAM
Grant Edwards grante Yow! Are you guys lined up
at for the METHADONE PROGRAM
We've slightly trimmed the long signature. Click to see the full one.

Re: fastest approach?

You know the baud rate required -- I don't.
We have not still been given the explanation of what is assumed by
"time is critical or very limited". So any speculations are pointless.

Yes, it has (usu. two to four ones)
Outputting results, say, to a 320x240 LCD will take ~200msec (5Hz!),
so, our "real-time" system should produce results (simply put,
display output data) at a rate of 5Hz or slower.
But again, everything is dependent on how the hardware has been made,
on the structure of incoming data over the RS-232 interface, on what
to do with the data and how long handling data within a given SBC
will last, e.t.c.
To conclude, the question in the original message was vague -- and,
therefore, hardly deserved close attention.

Site Timeline
- » how to make installer
- — Next thread in » Embedded Linux
-
- » doubt in toolchain for ARM
- — Previous thread in » Embedded Linux
-
- » Crosscompiling for ARM: reloc type R_ARM_ABS32 is not supported for PIC - ...
- — Newest thread in » Embedded Linux
-
- » What is this module?
- — The site's Newest Thread. Posted in » Electronics Design
-