Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #21427

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

Show all headers | View raw

Il 22/07/2015 02:19, Andrew Smallshaw ha scritto:
> On 2015-07-21, pozz <pozzugno@gmail.com> wrote:
>>
>> Suppose you have a complex dashboard with tenth of LEDs, gauges, values,
>> labels and so on. It could be a full-futured high-resolution TFT
>> display. The values shown on the dashboard come from remote controllers
>> connected through a bus. I think it's a very common scenario in my systems.
>>
>> When I design the firmware of the dashboard controller, I always have
>> many doubts on the design better to choose: refresh-based or event-based?
>>
>> Refresh-based is very simple: every 20ms, 100ms, 500ms or 1s a refresh
>> function is called. This function redraws *everything* on the dashboard
>> based on the current values collected on the bus.
>
>> Another approach is event-based. IMHO, it is very attractive and
>> elegant, because it remembers state-machines. The drawing operations are
>> performed only when necessary.
>
>> What is you preferred method?
>
> It depends a lot on the subtleties of the particular situation.
> I'll consider the technical issues first - what do you get from
> the sensors?  I note that you have already described them as having
> their own controllers and connected via a bus of some description
> so from our perspective they are intelligent units.  How do they
> communicate with the (I presume vehicular) dashboard?  Do they
> generate an interrupt when they record a change or wait to be
> polled?  Can they report their values on demand or do you need to
> begin a sample process and read the result some time later?  What
> do they report?  A raw figure or is it cleaned up first via e.g.
> some form or hysteresis or majority voting to eliminate noise and
> unnecessary fluctuations?  This is stuff that flavours your thought
> processes before you even start.

IMHO these questions (and answers) are very important, but not for my 
original discussion.
For each situation you describe, you have a lower-level layer that takes 
care to collect data from the field. A request/answer is needed to have 
the last updated engine temperature? It's the lower-level layer that 
takes care to trigger this at a regular rate. Does the remote controller 
sends a message with the updated value at a regular rate? The 
lower-layer level receive and save it in RAM for the GUI (and whatever 
else). Should the graphical system make some filtering on collected data 
from the bus? It's the lower-level layer that should take care of this.

At last, I have a clean and updated "image"/status of the remote 
peripherals in RAM. They are ready-to-use (from the HMI higher-layer) 
values. And now you can choose whatever you want: refresh the HMI at a 
regular basis or triggered by an event fired from the lower-level layer 
when the value really changes.


> Next consider the instruments themselves and how they are used.
> In a car the key instruments are probably the speedo and the
> tachometer and you will probably want to update them as near
> instantly as you can manage - several times a second at least.  On
> the other hand it doesn't matter if you only update the odometer
> every few seconds or the fuel gauge every minute.
>
> I'd also consider the nature of the output - if I was designing
> for a traditional dash where each indicator is independent I would
> by and large keep each controller equally independent - it potentially
> allows for smaller, cheaper chips (albeit more of them) but it does
> simplify the design and analysis of each.  They are also potentially
> more reusable, i.e. the next time I need a speedo for another dash
> I can copy the design over.  Of course, that approach doesn't
> work for a glass dashboard where everything needs to be unified on
> the same display.

I'm thinking about a system similar to a "glass dashboard", a regular 
display. It isn't stricly related to automotive. Think of a 
building-automation system and the wall-mounted display that shows the 
situation of the sensors spread over the house (temperatures, human 
presence, and so on).
Another application is an industrial automation system where the 
operator has a big display with a graphical representation of the 
current/updated status of the system.


> All other things being equal I suspect my preferred approach for
> the one big system model you seem to be envisioning would be what
> I assume you mean by the "refresh based approach" - a big main loop
> that polls and updates everything in turn.  If I then find the key
> instruments are not being updated quickly enough I may then introduce
> a system of numbered passes through that loop so that the important
> stuff gets done every time but only some the less important stuff
> gets done in turn each pass through the loop.

Indeed this is my last decision, after some thinking. However, the 
event-based approach is simpler (I'll explain in another post in this 
thread).


> I'd try to avoid an interrupt based ("event driven") approach if
> I could help it, and if I couldn't I'd aim for a hybrid approach
> where as little as possible interrupts and the rest is polled.
> Interrupts introduce their own complications, especially when there
> are multiple sources that can trigger at almost the same time,
> making them more difficult to write and more difficult to properly
> test.

As Paul Rubin said, even-based doesn't mean hardware interrupt. Anyway I 
agree with you, they can introduce complications... but in some cases 
are useful.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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