1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Task priority for UI task handling menus and other controls

Discussion in 'Embedded' started by ssubbarayan, Apr 29, 2008.

  1. ssubbarayan

    ssubbarayan Guest

    Dear experts,
    I am interested in learning from the rtos software application
    architectures you have come across,what would be the priority assigned
    to an UI based system?
    I am currently working for an consumer electronics product where A/V
    tasks and processing tasks take higher priority over UI task.What
    puzzles me would be that,in consumer electronics always the UI should
    be able to respond fast the moment the user needs it.While processing
    of A/V is time consuming should it not be the case where UI should be
    given higher priority?

    What is the level of priority for UI for applications involving flight
    control systems,automotives and industrial automation involving lots
    of controls?

    I have never come across a situation to design these apps and we are
    maintaining apps written by our earlier colleagues.

    I also had a chance to skim through the RTOS Application design book
    called CODARTS by Hassan Gamma ,(fully not completed in initial
    stage).
    From my understanding the author seems to favour CPU intensive tasks
    to have higher priority then Input and Output processing tasks.From
    this understanding,I can see why A/V has higher priority then UI.Is my
    understanding correct?Can experts help me to learn some design aspects
    I should look into when designing UI based applications?

    Looking farward for all your thoughts and advanced thanks for the
    same,

    Regards,
    s.subbarayan
     
    ssubbarayan, Apr 29, 2008
    #1
    1. Advertisements

  2. ssubbarayan

    ssubbarayan Guest

    Hi,
    I realise that in this situation.What about situations like flight
    control systems,industrial automation ?

    Regards,
    s.subbarayan
     
    ssubbarayan, Apr 30, 2008
    #2
    1. Advertisements

  3. ssubbarayan

    Steve Watt Guest

    The UI is still lower priority than flight dynamics, making certain the
    bucket of molten steel stops reasonably close to the right place, etc.

    In a hard realtime environment where life safety is an issue, you do
    complete scheduling analysis that proves (in the mathematical sense)
    that no deadline that affects safety can be missed. The user interface
    is assigned deadlines for responsiveness during that process, but it's
    still the case that a 200 mS delay in UI handling won't be a problem,
    given that human reflexes are in the same time scale.

    Humans basically[0] aren't real-time when it comes to control inputs.
    Video that one expects to be smooth needs to be updated at a given
    frame rate, but in an industrial or aviation system, it's simply
    not as important to show the user what's going on within microseconds
    as it is to adjust the flight control surfaces.

    In systems that I'm familiar with, UI output is about the lowest
    priority task. Input is near as low, but might get bumped a little
    depending on system properties.

    [0] OK, a continuous 200 ms lag of response in my joystick would make
    landing on a carrier somewhat harder. On the other hand, if it was
    always there, it could be trained around and compensated for.
     
    Steve Watt, May 2, 2008
    #3
  4. Steve Watt wrote:

    The occasional delay in the reaction of the user interface is VERY
    ANNOYING. Remember how do you feel when the mouse cursor sticks in
    Windows. If a LED is switched on later then 50ms after a button is
    pressed, the customers will call your system "dull", "sluggush" and
    "heavy", no matter how well it performs the main functionality.


    Vladimir Vassilevsky
    DSP and Mixed Signal Design Consultant
    http://www.abvolt.com
     
    Vladimir Vassilevsky, May 2, 2008
    #4
  5. ssubbarayan

    Simon Wright Guest

    I encountered a team who thought they had done well to reduce the
    response time from 50 seconds to 15 (seconds). In a wire-guided
    torpedo control system .. OK, things happen slowly underwater and
    submariners learn patience, but ..
     
    Simon Wright, May 2, 2008
    #5
  6. Actually it could have made the perception even worse: the 50 seconds is
    enough time to be distracted to something else (get a cup of coffee,
    etc.), but for 15 seconds a person only can stare at the control panel.


    Vladimir Vassilevsky
    DSP and Mixed Signal Design Consultant
    http://www.abvolt.com
     
    Vladimir Vassilevsky, May 2, 2008
    #6
  7. ssubbarayan

    Ed Prochak Guest

    Two points

    one, Vlad and Steve have it right: an important factor in user
    interface is consistency of response time. A system that always
    responds in 1second will be perceived as better than one that usually
    responds in 200ms but occasionally takes 5seconds.

    two, priority must be chosen specific to the system requirements.
    having a 1second delay in responding to a key press on a DVD player
    is vastly different than pressing a button on an industrial control
    panel. The DVD player might use a low priority polling task, while the
    controller would use an interrupt driven event sent to a high priority
    task (possibly the one to stop the equipment in an emergency
    situation).

    So there is no one priority level for all UI tasks in all
    applications.

    Ed
     
    Ed Prochak, May 2, 2008
    #7
  8. But then, it would be a continuous 200ms lag. It would be a 20ms
    reaction almost always, with the occasional 200ms spike in reaction time.

    As to landing on carriers, a friend claims that military flight
    simulators have a 1 millisecond(!) maximum force-feedback delay for
    their joysticks. Pilots did complain if they took longer.
     
    Hans-Bernhard Bröker, May 2, 2008
    #8
  9. But it would hardly be a continuous 200ms lag, would it? It would be a
    20ms reaction almost always, with the occasional 200ms spike in reaction
    time.

    As to landing on carriers, a friend claims that military flight
    simulators have a 1 millisecond(!) maximum force-feedback delay for
    their joysticks. Pilots did complain if they took longer.
     
    Hans-Bernhard Bröker, May 2, 2008
    #9
  10. ssubbarayan

    Dave Guest

    Doing some work for a large auto maker on their first electronic
    throttle control models years ago, they were very concerned about some
    testing of the ignition and fuel system cutoff that we had to run when
    the driver turned off the engine. One engine was noted by drivers for
    its' fast start and the company was very concerned that if the driver
    turned off the engine then turned it back on immediately, our test time
    shouldn't be noticed by the driver and "the sluggish start" be commented
    on. The test took 62.5 ms (we were waiting for a hardware timeout) but
    wasn't noticed by drivers.



    ~Dave T~
     
    Dave, May 3, 2008
    #10
  11. ssubbarayan

    Dave Guest

    Actually, you do. The fewer chips the less cost (lower PCB area, fewer
    chip interconnects and solder joints, faster assembly, etc.). For the
    last 10-15 years, the trend for the engine control module (ECM) has been
    to move more and more off-chip functionality into the microprocessor.
    Flash memory, EEPROM functionality, A/D conversion, multiple CAN busses,
    other comm busses, and engine position decoding just to name some.


    ~Dave T~
     
    Dave, May 3, 2008
    #11
  12. You have a different view of "everything" than Jim. Jim was talking
    about the dozens of separate microcontrollers spread over any remotely
    modern car, not about the microntroller taking over more of its support
    circuitry's job.

    The number of individual micros per car is far from tending towards one.
    If anything, it's going to continue growing for a while.
     
    Hans-Bernhard Bröker, May 3, 2008
    #12
  13. ssubbarayan

    Dave Guest

    I will plead guilty to being ECM-centric. ;-) In my defense, I did
    work on them for a decade and, when you reduce a car to its' purpose of
    providing transportation, the fact that there are 20 micros (slight
    exaggeration) in my seat to provide comfort to my butt seems somewhat
    overkill.


    ~Dave T~
     
    Dave, May 3, 2008
    #13
  14. Well, if you actually go head and reduce a car to its purpose of
    providing transportation, you'd end up with a motorbike. ;-) Or a bus,
    maybe.
     
    Hans-Bernhard Bröker, May 3, 2008
    #14
  15. ssubbarayan

    Lanarcam Guest

    Lanarcam, May 3, 2008
    #15
  16. Well, we don't know what exactly you saw, do we?

    But yes, all but the most trivial ECUs in cars and trucks are
    diagnosable to at least some extent, these days. Automobile companies
    usually have a blanket requirement stating something like "every ECU has
    to diagnose all its inputs and outputs, and report its internal status
    in sufficient detail to know if these match each other".

    Electronics repairs of current cars consist of little more than:

    acquire tester for this make&model
    find diagnostic test socket
    plug in tester
    ask for error read-out
    wait a bit
    peruse output
    (optionally have customer OK the costs)
    exchange culprit part
    lather, rinse, repeat from step 4
     
    Hans-Bernhard Bröker, May 5, 2008
    #16
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.