1. Home
  2. Embedded Linux
  3. fastest approach?

fastest approach?

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

Reply to
Little.Horse
Loading thread data ...

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
                               visi.com            unsatisfactory?
Reply to
Grant Edwards

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

Reply to
Michael Schnell

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!

"Michael Schnell" ??? news: snipped-for-privacy@viruswall.lumino.de ???...

Reply to
Little.Horse

Little.Horse wrote: : 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!

: "Michael Schnell" ??? : news: snipped-for-privacy@viruswall.lumino.de ???... : > 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

Reply to
J Jackson

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

Right. RTAI does exactly this.

-Michael

Reply to
Michael Schnell

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
                               visi.com            is viewing "Leave it to
                                                   Beaver"!
Reply to
Grant Edwards

  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. ;-)
Reply to
VictorVS

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

Reply to
Michael Schnell

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
                               visi.com            or FOOD STAMPS??
Reply to
Grant Edwards

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.

>
Reply to
VictorVS

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.