fastest approach? - Embedded

This is a discussion on fastest approach? - Embedded ; 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 ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: fastest approach?

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



  2. Re: fastest approach?

    On 2005-04-12, Little.Horse wrote:

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


    How critical? How much time do you have?

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


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

    > Is above approach faster than write a program in user mode to
    > read RS232 and then write to IO port?


    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?

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

  4. 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!

    "Michael Schnell" ???
    news3asi2-qv4.ln1@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




  5. Re: fastest approach?

    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" ???
    : news3asi2-qv4.ln1@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



  6. Re: fastest approach?

    > Yes, but since time is pretty critical, we need to do it fast.

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


    Right. RTAI does exactly this.

    -Michael

  7. Re: fastest approach?

    On 2005-04-12, Little.Horse wrote:

    > Yes, but since time is pretty critical, we need to do it fast.


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


    HOW FAST DOES IT NEED TO BE?

    > Any idea? Will this be faster?


    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"!

  8. Re: fastest approach?



    Grant Edwards wrote:

    > On 2005-04-12, Little.Horse wrote:
    >
    >
    >>Yes, but since time is pretty critical, we need to do it fast.

    >
    >
    > HOW FAST?


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

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


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

    >
    > 2.
    > Writing _a pixel_ to convensional LCDs will take several microseconds.
    > ;-)


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

    -Michael

  10. Re: fastest approach?

    On 2005-04-14, VictorVS wrote:
    >> On 2005-04-12, Little.Horse wrote:
    >>
    >>>Yes, but since time is pretty critical, we need to do it fast.

    >>
    >> HOW FAST?

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


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

    > 2. Writing _a pixel_ to convensional LCDs will take several
    > microseconds.


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

  11. Re: fastest approach?



    Grant Edwards wrote:

    > On 2005-04-14, VictorVS wrote:
    >
    >>>On 2005-04-12, Little.Horse wrote:
    >>>
    >>>
    >>>>Yes, but since time is pretty critical, we need to do it fast.
    >>>
    >>>HOW FAST?

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

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

    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.

    >
    >
    >>2. Writing _a pixel_ to convensional LCDs will take several
    >> microseconds.

    >
    >
    > Why? Don't LCD controller have frame buffers?

    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 Thread