Re: Design pattern: refresh-based or event-based?

From	Dimiter_Popoff <dp@tgi-sci.com>
Newsgroups	comp.arch.embedded
Subject	Re: Design pattern: refresh-based or event-based?
Date	2015-07-23 10:29 +0300
Organization	TGI
Message-ID	<moq528$ufg$1@dont-email.me> (permalink)
References	(2 earlier) <mol1jo$har$1@dont-email.me> <momh9l$f1v$1@dont-email.me> <15fuqalk3j3fiq0pa3ff7elcq4genjg64q@4ax.com> <moohem$1du$1@dont-email.me> <moq3ij$pt4$2@dont-email.me>

Show all headers | View raw

On 23.7.2015 г. 10:04, pozz wrote:
> Il 22/07/2015 18:48, Dimiter_Popoff ha scritto:
>> On 22.7.2015 г. 10:02, upsidedown@downunder.com wrote:
>>> On Wed, 22 Jul 2015 01:34:02 +0300, Dimiter_Popoff <dp@tgi-sci.com>
>>> wrote:
>>>
>>>> On 21.7.2015 ?. 12:00, pozz wrote:
>>>>> Il 21/07/2015 10:37, upsidedown@downunder.com ha scritto:
>>>>>> On Tue, 21 Jul 2015 10:02:49 +0200, pozz <pozzugno@gmail.com> wrote:
>>>>>>
>>>>>>> Even this design patter have some drawbacks.
>>>>>>> IMHO it is dangerous and error-prone, because you could ignore a
>>>>>>> certain
>>>>>>> sequence of events that brings to a wrong state (you will have a
>>>>>>> wrong
>>>>>>> value displayed on the dashboard).
>>>>>>> The startup must be designed with great care. Should a "virtual
>>>>>>> startup
>>>>>>> event" be triggered during initialization for each value, so the
>>>>>>> current/init value is correctly displayed?
>>>>>>> How to distinguish a "virtual startup event" from a "normal
>>>>>>> event"? It's
>>>>>>> important, if I have to make soma actions only if a "normal event"
>>>>>>> occurs.
>>>>>>
>>>>>> In addition to startup, you should have a method of refreshing the
>>>>>> whole screen on request (e.g. refresh button) in case of the actual
>>>>>> display and the background information are out of synch, eg. due to
>>>>>> EMC issues  with some garbage on screen.
>>>>>
>>>>> The refresh-based design pattern solves automatically this problem,
>>>>> because it continuously redraws the full screen.
>>>>>
>>>>
>>>> You do not have to pick either this or that. You can do both.
>>>> The way I do it is refresh based on an event - at a reasonable
>>>> rate, say no more than 30 times a second
>>>
>>> How exactly should this be implemented ? Assume there are more than
>>> one event in 1/30 seconds, you should do the full refresh after the
>>> _last_ event, not after the first event.
>>
>> For example in the nuvi package (the spectrometry app under DPS running
>> on our products) each object (spectrum, setup window, oscilloscope
>> display etc.) keeps track of when it was last modified (in system
>> timebase ticks IIRC). That is when some object - say, an acquisition
>> module - modifies the data object it is connected to it sets "last"
>> moment of change (action being called, well, "setlast" :-) ).
>> The displaying loop checks all of the objects ("getlast", I may move
>> this to the more universal getxpar/setxpar, it predates these)
>> some of them has been modified since its last refresh, it gets
>> refreshed. One can set the refresh rate on a per "display" (i.e.
>> window) basis, meaning once a refresh is done no other will be
>> attempted for that period of time. Whoever missed the train - no
>> matter by how little - will have to wait for the next one.
>
> It seems to me this is a variant of my "refresh-based" approach. When a
> new value is received, no message is asyncronously emitted (or event
> triggered). You only save the time when the last value arrived to the
> controller.
>
> In the refresh function, you check the last update time only to
> understand if the value must be updated on the display too.
>
>

No, it is the best of both worlds. You will always have some time
between event and refresh no matter what; wanting it below a few
mS is not practical simply because no human can see that.
So with this approach you get the display refreshed within a certain
time after an event - with DPS you can get that time down even
into microseconds range were it needed - and you do not do any
refresh when it is not needed, as it would be with your
suggested "refresh-based" approach.

Basically it is a simple enough issue, does not take a lot
to get to the optimum choice nor is there much to do to improve
on it.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

Thread

Design pattern: refresh-based or event-based? pozz <pozzugno@gmail.com> - 2015-07-21 10:02 +0200
  Re: Design pattern: refresh-based or event-based? upsidedown@downunder.com - 2015-07-21 11:37 +0300
    Re: Design pattern: refresh-based or event-based? pozz <pozzugno@gmail.com> - 2015-07-21 11:00 +0200
      Re: Design pattern: refresh-based or event-based? Dimiter_Popoff <dp@tgi-sci.com> - 2015-07-22 01:34 +0300
        Re: Design pattern: refresh-based or event-based? pozz <pozzugno@gmail.com> - 2015-07-22 06:57 +0200
          Re: Design pattern: refresh-based or event-based? Paul Rubin <no.email@nospam.invalid> - 2015-07-21 23:02 -0700
            Re: Design pattern: refresh-based or event-based? pozz <pozzugno@gmail.com> - 2015-07-22 09:17 +0200
              Re: Design pattern: refresh-based or event-based? Paul Rubin <no.email@nospam.invalid> - 2015-07-22 00:23 -0700
        Re: Design pattern: refresh-based or event-based? upsidedown@downunder.com - 2015-07-22 10:02 +0300
          Re: Design pattern: refresh-based or event-based? Dimiter_Popoff <dp@tgi-sci.com> - 2015-07-22 19:48 +0300
            Re: Design pattern: refresh-based or event-based? pozz <pozzugno@gmail.com> - 2015-07-23 09:04 +0200
              Re: Design pattern: refresh-based or event-based? Dimiter_Popoff <dp@tgi-sci.com> - 2015-07-23 10:29 +0300
                Re: Design pattern: refresh-based or event-based? raimond.dragomir@gmail.com - 2015-07-31 02:34 -0700
  Re: Design pattern: refresh-based or event-based? Don Y <this@is.not.me.com> - 2015-07-21 03:16 -0700
  Re: Design pattern: refresh-based or event-based? Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2015-07-21 14:40 +0200
    Re: Design pattern: refresh-based or event-based? pozz <pozzugno@gmail.com> - 2015-07-22 07:01 +0200
      Re: Design pattern: refresh-based or event-based? Stefan Reuther <stefan.news@arcor.de> - 2015-07-22 18:30 +0200
        Re: Design pattern: refresh-based or event-based? Paul Rubin <no.email@nospam.invalid> - 2015-07-22 10:55 -0700
  Re: Design pattern: refresh-based or event-based? Paul Rubin <no.email@nospam.invalid> - 2015-07-21 08:26 -0700
    Re: Design pattern: refresh-based or event-based? pozz <pozzugno@gmail.com> - 2015-07-22 07:04 +0200
      Re: Design pattern: refresh-based or event-based? Paul Rubin <no.email@nospam.invalid> - 2015-07-21 23:13 -0700
        Re: Design pattern: refresh-based or event-based? pozz <pozzugno@gmail.com> - 2015-07-22 09:24 +0200
          Re: Design pattern: refresh-based or event-based? Paul Rubin <no.email@nospam.invalid> - 2015-07-22 08:26 -0700
            Re: Design pattern: refresh-based or event-based? pozz <pozzugno@gmail.com> - 2015-07-23 09:00 +0200
  Re: Design pattern: refresh-based or event-based? hamilton <hamilton@nothere.com> - 2015-07-21 14:07 -0600
    Re: Design pattern: refresh-based or event-based? Don Y <this@is.not.me.com> - 2015-07-21 13:12 -0700
  Re: Design pattern: refresh-based or event-based? Andrew Smallshaw <andrews@sdf.lonestar.org> - 2015-07-22 00:19 +0000
    Re: Design pattern: refresh-based or event-based? Paul Rubin <no.email@nospam.invalid> - 2015-07-21 18:09 -0700
      Re: Design pattern: refresh-based or event-based? Andrew Smallshaw <andrews@sdf.lonestar.org> - 2015-07-22 21:18 +0000
        Re: Design pattern: refresh-based or event-based? Paul Rubin <no.email@nospam.invalid> - 2015-07-22 23:17 -0700
    Re: Design pattern: refresh-based or event-based? pozz <pozzugno@gmail.com> - 2015-07-22 07:20 +0200
    Re: Design pattern: refresh-based or event-based? upsidedown@downunder.com - 2015-07-22 10:53 +0300
  Re: Design pattern: refresh-based or event-based? pozz <pozzugno@gmail.com> - 2015-07-22 07:32 +0200

csiph-web