Task priority for UI task handling menus and other controls

Steve Watt wrote:

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

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.

Robert Adsett wrote:
> In article <IoFSj.14398$2g1.4646@nlpi068.nbdc.sbc.com>, Vladimir 
> Vassilevsky says...
> 
>>
>>Simon Wright wrote:
>>
>>>Vladimir Vassilevsky <antispam_bogus@hotmail.com> writes:
>>>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.
> 
> 
> I would think if you were operating a torpedo control system ducking out 
> for a cup of coffee would be frowned upon.

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

-jg

ssubbarayan wrote:

> On Apr 29, 9:51 am, Tim Wescott <t...@seemywebsite.com> wrote:
>>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?
> Hi,
> I realise that in this situation.What about situations like flight
> control systems,industrial automation ?

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

Vladimir Vassilevsky wrote:
> 
> 
> 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.

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~

Jim Granville wrote:
> 
> 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!)

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 wrote:
> Jim Granville wrote:

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

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 wrote:
> Dave wrote:
>> Jim Granville wrote:
> 
>>> 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!)
>>
>> 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.
> 
> 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~

Dave wrote:

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

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 wrote:
> Dave wrote:
> 
>> 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.
> 
> 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,

<http://blog.modernmechanix.com/mags/qf/c/PopularMechanics/12-1950/xlg_chariot.jpg>

Robert Adsett <sub2@aeolusdevelopment.com> writes:
> Vladimir Vassilevsky says...
> > Simon Wright wrote:
> > > Vladimir Vassilevsky <antispam_bogus@hotmail.com> writes:
> > > 
> > >>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.
> > > 
> > > 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.
> 
> I would think if you were operating a torpedo control system ducking out 
> for a cup of coffee would be frowned upon.

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