fastest approach?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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



Re: fastest approach?

Quoted text here. Click to load it


How critical?  How much time do you have?

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: fastest approach?
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?
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?

Little Horse!

Quoted text here. Click to load it



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



Re: fastest approach?
Quoted text here. Click to load it

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
Quoted text here. Click to load it

Right. RTAI does exactly this.

-Michael

Re: fastest approach?

Quoted text here. Click to load it

HOW FAST?

Quoted text here. Click to load it

HOW FAST DOES IT NEED TO BE?

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: fastest approach?



Quoted text here. Click to load it

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?

Quoted text here. Click to load it

I suppose the standard UART driver can handle this easily on any decent CPU.

Quoted text here. Click to load it

This is no realtime requirement at all. A FiFo will eliminate all timing
constrains.

-Michael

Re: fastest approach?
Quoted text here. Click to load it

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

Quoted text here. Click to load it

Why?  Don't LCD controller have frame buffers?

--
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?



Quoted text here. Click to load it
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.

Quoted text here. Click to load it
  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.








Quoted text here. Click to load it

Site Timeline