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

From	pozz <pozzugno@gmail.com>
Newsgroups	comp.arch.embedded
Subject	Re: Design pattern: refresh-based or event-based?
Date	2015-07-23 09:04 +0200
Organization	A noiseless patient Spider
Message-ID	<moq3ij$pt4$2@dont-email.me> (permalink)
References	(1 earlier) <kl0sqa1dtneouv3k3b3dgkfftvt7ns9djc@4ax.com> <mol1jo$har$1@dont-email.me> <momh9l$f1v$1@dont-email.me> <15fuqalk3j3fiq0pa3ff7elcq4genjg64q@4ax.com> <moohem$1du$1@dont-email.me>

Show all headers | View raw

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.

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