Task priority for UI task handling menus and other controls

Think about it.

You'd notice video that had even the occasional two-frame (66ms) dropout. An extra 66ms to respond to a button press probably wouldn't be noticed at all, and it's certainly no disaster if the UI freezes for a quarter of a second.

So which needs to be served by the higher priority task?

--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

lication

to

e

ed text -

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

Regards, s.subbarayan

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 KD6GGD  PP-ASEL-IA          ICBM: 121W 56' 57.5" / 37N 20' 15.3"
 Internet: steve @ Watt.COM                      Whois: SW32-ARIN
   Free time?  There's no such thing.  It just comes in varying prices...

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

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

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

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

I would think if you were operating a torpedo control system ducking out for a cup of coffee would be frowned upon.

Robert

** Posted from **

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.

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.

Quite!! ( and lucky I was not drinking coffee when I read that! )

-jg

You need to define the Input/output. Chirping to a button press is less important than maintaining critical IO control, and in many embedded systems, there ARE many critical IO controls.

One indicator of this, is CARs and the CAN bus.

This was first promoted as one-bus, address anything, run-around-the-whole-car stuff.

BUT newest Microcontroller have MANY CAN BUS ports ?

Why ? - because they found some tasks are more important than others, and a good way to protect that importance, is to give them their own bus. (and priority level in the core) You also gain physical failure isolation protection as well - don't want a wire fault in your wing mirror, to take down your ignition system !

Another trend is multiple chips. You do NOT see a modern car trying to run everything from one chip (even tho Bill Gates might try that!)

-jg

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~

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~

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.

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~

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.

Or perhaps that,

No self-respecting Navy guy is going to be caught without his coffee, so why would he need to duck out for more?