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.

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

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!

: 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

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

HOW FAST?



HOW FAST DOES IT NEED TO BE?



Yes, it will be faster.  It will also be much harder to develop
and test.

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.
;-)

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



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

-Michael

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



Why?  Don't LCD controller have frame buffers?

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.