On 2024-01-31 20:13, Don Y wrote:
> On 1/31/2024 10:56 AM, Carlos E.R. wrote:
>>>> To read the input while printing output the programmer has to output
>>>> a letter, then listen, in a loop. It can be done, but it is more code.
>>>
>>> But, you can decompose it into multiple threads and have LESS
>>> total code.
>>>
>>> Did no one wonder "what if the device becomes un-paired?
>>> DURING a call?  While sitting idle?
>>>
>>> Or (for vehicles), that the car AND DRIVER may want to do two or
>>> more things simultaneously?  (Can I turn on the windshield wipers
>>> AND move the driver's seat simultaneously?)
>>
>> In my car, that's a different processor than the "infotainment"
>> display :-)
>
> Then there is a switch that allows THAT processor to have access to the
> display
> that is normally used by the infotainment/navigation system (because you
> NORMALLY aren't using the BACKUP camera!)  That "switch" can't rely on the
> software in the infotainment system being operational -- unless someone
> bastardized the implementation to put:

No, that processor (in my car) uses a different display and different
buttons.

>
>     video_input := other_processor;
>
> EARLY in the startup code.
>
>> Responds instantly.
>>
>>>>> SWMBO's vehicle has a backup camera that comes on when the car is
>>>>> placed
>>>>> in reverse.  But, the software is dog slow... all of the controls are
>>>>> ignored for a good 30 seconds after turning on the ignition!  So, how
>>>>> can it "notice" the transmission being place in reverse and adjusting
>>>>> the main display to route live video to it?  ANS:  I suspect there
>>>>> is a physical switch that directly connects the video feed to the
>>>>> display so the view is available regardless of whether or not the
>>>>> processor has managed to initialize itself!
>>>>
>>>> I doubt there is a hardware switch. It is far easier and cheaper a
>>>> software
>>>
>>> The "right" solution is to process the video *in* software as you
>>> have to be able to handle the different camera modes, superimposed
>>> parking guides, etc.
>>>
>>> But, if you can't get enough code up and running to see that I am
>>> pressing the "show me the information display instead of the
>>> navigation map", how much hope do you have for processing video?
>>
>> Same as a TV set with different inputs. It can even have a different
>> processor.
>
> You still have to be able to recognize the user's (or environment's) desire
> to switch to a particular "input".

Yes, but can be handled by different processors, switching the display
to one or the other, similarly as does a TV with different inputs.

>
>>>> switch. Mine responds faster than 30", and it is just a humble Opel.
>>>> Display and firmware made by LG. It draws lines superimposed on the
>>>> camera display that move as I move the steering wheel, so there is
>>>> CPU time involved.
>>>>
>>>>> Was there a specification ANYWHERE as to how quickly the system
>>>>> should be responsive?  Or, did someone "discover" this problem
>>>>> later and cobble together a hardware fix (as changing "crt0.s"
>>>>> would likely be a major heartache!)
>>>>
>>>> It was considered acceptable. You have to let the engine warm up
>>>> before attempting to move the car, anyway :-p
>>>
>>> Even if you just SHUT OFF the engine from a previous trip?  :>
>>
>> Mine starts up instantly in that situation. It takes maybe minutes
>> before it actually powers off. I know because of the times I wanted to
>> "reboot" it because of problems, I had to wait or it would open on the
>> same menu.
>
> Hers always starts up with the same splash screen (why would a
> subcontractor
> want to advertise their lousy implementation?  hope other clients are
> equally naive??), legal disclaimer, etc.  There is no way to effectively
> expedite the boot sequence.
>
>>> Likely no one ever deliberately thought about the time involved
>>> BEFORE the design was complete.  And, at that point, it would
>>> be too hard to change.  So, you RATIONALIZE that it isn't
>>> a problem...
>>
>> I assume that the engineers designing it knew there was a time to boot.
>
> Can you tell me how long it will take you for every subsystem
> and object to initialize in a system that didn't EXPLICITLY
> prioritize a fast startup?  This harkens back to application
> startup code that expedites throwing a splash screen up so
> folks don't wonder why the "program" hasn't started, yet
> (it HAS... but, it is busy doing stuff that doesn't make
> marks on the screen!)
>
> If you want something to boot quickly, you have to make deliberate
> efforts in the design to ensure that you at least give the
> appearance of doing so (more than just a quick splash screen).

Of course.

> In my current project, I save an image of the executing system
> when I power a node down.  So, I can bring the node back to that
> state "immediately" when I need to power it back up (just
> wait for the delays to transfer the image over the network).
>
> Depending on how much memory an infotainment system requires
> (to store the current state), it could be battery backed
> (if low enough power and short enough time) and a simple
> hash recomputed on restart to determine the integrity of
> the image -- just RESUME instead of RESTART.
>
>>> Assumptions are what leads to bad designs.  Like assuming that Driver #2
1>>> will want to listen to whatever music source Driver #1 had selected
when
>>> they finished their most recent "trip".
>>>
>>> Our stove has a "big knob" UI; one big knob to select from options
>>> and values, press for ENTER.  Great if there is only one task that
>>> the stove can perform at a time.
>>>
>>> But, what if you've got the first oven BAKING at 375F with 0:43 left
>>> on its timer, the second BROILING on HIGH with 0:12 left on its
>>> timer AND you want to set a general purpose timer for 3:00 but
>>> the BROIL timer expires while you are setting that?  Suddenly,
>>> your general-purpose-timer-setting-activity has been preempted by
>>> "tell the user the BROILER is done".  What happened to the
>>> value I was in the process of setting for that general purpose timer?
>>> How long before I can get BACK to doing that?  How much of that 3:00
>>> will have elapsed before I've even managed to tell the stove
>>> to start timing???
>>>
>>> How should the user think of the stove's actions?  Obviously, the
>>> DESIGNER didn't think the stove could walk and chew gum...
>>
>> I think the designer did think of it, but the beans counter decided to
>> simplify number of knobs.
>
> Then there should be some explanation (to the user) of what
> is expected of the user WHEN (not if) that situation occurs.
>
> Past experience (with other products/designs) leads me to
> believe they just ignored this use case.  E.g., when you
> demo the implementation to "management", do you pose
> all of these hypothetical cases to see how they like
> your solution?  Or, do you just focus on ONE user task
> at a time:
>
>    "See, we use the big knob to select from BAKE, CONVECTION,
>    DEHYDRATE, BROIL, etc.  Then, once we have selected a MODE,
>    we can use that same big knob to specify a TEMPERATURE.
>    And, once that is set, we can AGAIN use the big knob to
>    specify an optional cook time.  And, again, what to do at
>    the expiration of that cook time (leave oven on, shut it
>    off, etc.)"
>
>    "Now, if we happen to be in the middle of specifying
>    the temperature and the timer for the OTHER oven expires,
>    we..."
>
> If you think about how YOU would "solve" the UI problem,
> you'd discover that the big knob is the problem.  A legacy
> oven would have different controls ALL PERPETUALLY ACCESSIBLE
> that would avoid this issue.  The big knob give you no way
> of setting the FOCUS for the user's actions!

Of course.

> There are induction cooktops that are only capable of powering
> two heating elements at a time.  How do you convey that to the
> user?  Do you LET him use 4 "burners" but time-division multiplex
> the "heat" applied?  Will he get different perfomance in this
> case than when only using *two* burners?

The limitation can be a power limit.
Some cooktops instead configure a total watts limit.

My induction cooktop has only two burners, and one of them broke down
recently. Repairing it would be 250€; there are ranges cheaper than that.

--
Cheers, Carlos.