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

Groups > comp.arch.embedded > #21399 > unrolled thread

Design pattern: refresh-based or event-based?

Back to article view | Back to comp.arch.embedded

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#21430

pozz <pozzugno@gmail.com> writes:
> I use emWin graphical libraries, but I think the situation is similar
> to other similar toolkit.

I've never used emWin (it does look nice,
https://www.segger.com/emwin.html) but I've used various other GUI
toolkits and they were all event based.  Dealing with refresh within the
application sounds like a 1970's video game.  

These days if you have a 4" TFT touch screen and a fairly powerful
embedded Linux system running X windows and a Python application
underneath, the hardware cost will be dominated by the screen rather
than the computer.  So unless this is a super high volume application or
you have special hardware constraints, you should probably use high
level tools rather than dealing with the level of detail you're asking
about.

[toc] | [prev] | [next] | [standalone]

#21434

Il 22/07/2015 08:13, Paul Rubin ha scritto:
> pozz <pozzugno@gmail.com> writes:
>> I use emWin graphical libraries, but I think the situation is similar
>> to other similar toolkit.
>
> I've never used emWin (it does look nice,
> https://www.segger.com/emwin.html) but I've used various other GUI
> toolkits and they were all event based.  Dealing with refresh within the
> application sounds like a 1970's video game.

As I wrote in another post, one thing is the events triggered by the 
graphical toolikt (even emwin is event-based) and another is the events 
generated by the applications, for example from the lower level layer 
that manages the field bus (remote sensors/peripherals).

When the user touches a button, an event is raised automatically from 
emWin and a callback is automatically called. What to do is a work for 
the programmer that fills in the callback function.

Even in this scenario I can decide to update *values* on the display at 
a regular time base, for example every 100ms. A timer expiration event 
trigger a refresh function. Maybe the name of the function would be 
update() instead of refresh() that recalls the low-level mechanism of 
refreshing pixels.


> These days if you have a 4" TFT touch screen and a fairly powerful
> embedded Linux system running X windows and a Python application
> underneath, the hardware cost will be dominated by the screen rather
> than the computer.  So unless this is a super high volume application or
> you have special hardware constraints, you should probably use high
> level tools rather than dealing with the level of detail you're asking
> about.

[toc] | [prev] | [next] | [standalone]

#21437

pozz <pozzugno@gmail.com> writes:
> As I wrote in another post, one thing is the events triggered by the
> graphical toolikt (even emwin is event-based) and another is the
> events generated by the applications, for example from the lower level
> layer that manages the field bus (remote sensors/peripherals)...
> Even in this scenario I can decide to update *values* on the display
> at a regular time base, for example every 100ms. 

Yes, it's just not clear to me why to do that.

Do you know the idea of Model-View-Controller (MVC)?  It might be
helpful here:

  https://en.wikipedia.org/wiki/Model-view-controller

Basically it means you have a data object (the model) tracking the state
of the system.  The "controller" reads stuff from the field bus and
updates values in the model, and then the display (the view) shows the
contents of the model.

It's generally reasonable for the controller posting updates to values
in the model to also send events to the UI as the updates happen.  In a
simple system the model can be the state of the UI widgets.  UI
libraries will typically let you read from the widgets as well as write
to them.

You do end up wanting to use some concurrency in these interfaces, but
if you implement it with message passing and accept a bit of overhead
from that, you're reasonably safe from the classic hazards of concurrent
programming.

What hardware and OS are you using?  

[toc] | [prev] | [next] | [standalone]

#21452

Il 22/07/2015 17:26, Paul Rubin ha scritto:
> pozz <pozzugno@gmail.com> writes:
>> As I wrote in another post, one thing is the events triggered by the
>> graphical toolikt (even emwin is event-based) and another is the
>> events generated by the applications, for example from the lower level
>> layer that manages the field bus (remote sensors/peripherals)...
>> Even in this scenario I can decide to update *values* on the display
>> at a regular time base, for example every 100ms.
>
> Yes, it's just not clear to me why to do that.

For simplicity. The code is very simple, a single function to call 
regularly on a time basis that redraw every widget on UI.


> Do you know the idea of Model-View-Controller (MVC)?  It might be
> helpful here:
>
>    https://en.wikipedia.org/wiki/Model-view-controller

Interesting.


> Basically it means you have a data object (the model) tracking the state
> of the system.  The "controller" reads stuff from the field bus and
> updates values in the model, and then the display (the view) shows the
> contents of the model.
>
> It's generally reasonable for the controller posting updates to values
> in the model to also send events to the UI as the updates happen.  In a
> simple system the model can be the state of the UI widgets.  UI
> libraries will typically let you read from the widgets as well as write
> to them.

As I wrote in my original post, the event-based, asyncronous design is 
more attractive and clean for me... but it has some pitfalls and 
additional complexities... so the original question: what is the better 
method?


> You do end up wanting to use some concurrency in these interfaces, but
> if you implement it with message passing and accept a bit of overhead
> from that, you're reasonably safe from the classic hazards of concurrent
> programming.
>
> What hardware and OS are you using?

I think the question is indipendent from the hw. Anyway I'm actually 
using a LPC1788 MCU without a really OS.

[toc] | [prev] | [next] | [standalone]

#21409

On 7/21/2015 2:02 AM, pozz wrote:
> with tenth of LEDs

What does this mean ??

[toc] | [prev] | [next] | [standalone]

#21410

On 7/21/2015 1:07 PM, hamilton wrote:
> On 7/21/2015 2:02 AM, pozz wrote:
>> with tenth of LEDs
>
> What does this mean ??

s.b. "tens of LEDs" -- or something along those lines.  (?)

[toc] | [prev] | [next] | [standalone]

#21415

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.

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.

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.

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.

-- 
Andrew Smallshaw
andrews@sdf.lonestar.org

[toc] | [prev] | [next] | [standalone]

#21418

Andrew Smallshaw <andrews@sdf.lonestar.org> writes:
> communicate with the (I presume vehicular) dashboard? 

Wait is this an actual physical dashboard, as opposed to some kind of UI
displayed on a screen (often metaphorically called a dashboard)?  Hmm.

> I'd try to avoid an interrupt based ("event driven") approach ...
> Interrupts introduce their own complications, especially when there
> are multiple sources that can trigger at almost the same time,

Event driven doesn't necessarily mean interrupts.  There can be some
kind of message system, or simple polling of the different data sources,
dropping change notifications into a queue that the UI event loop
consumes.  This is a very traditional way to write a UI and is pretty
safe from the usual hazards of concurrency and interrupts.

[toc] | [prev] | [next] | [standalone]

#21442

On 2015-07-22, Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Smallshaw <andrews@sdf.lonestar.org> writes:
>
>> I'd try to avoid an interrupt based ("event driven") approach ...
>> Interrupts introduce their own complications, especially when there
>> are multiple sources that can trigger at almost the same time,
>
> Event driven doesn't necessarily mean interrupts.  There can be some
> kind of message system, or simple polling of the different data sources,
> dropping change notifications into a queue that the UI event loop
> consumes.  This is a very traditional way to write a UI and is pretty
> safe from the usual hazards of concurrency and interrupts.

You still (generally) have interrupts though - they are simply
buried in the system or library layers and you are presented with
a simplified abstraction.  It's also largely irrelevant for the
task in hand since our input is from a random collection of sensors
as opposed to more usual GUI user input.  Either those are not
going to fit into the GUI's input module or you are going to have
to do your own preparatory work to make them fit, i.e. write the
interrupt handlers that perform the appropriate callbacks.

-- 
Andrew Smallshaw
andrews@sdf.lonestar.org

[toc] | [prev] | [next] | [standalone]

#21451

Andrew Smallshaw <andrews@sdf.lonestar.org> writes:
> our input is from a random collection of sensors... Either those are
> not going to fit into the GUI's input module or you are going to have
> to do your own preparatory work to make them fit, i.e. write the
> interrupt handlers that perform the appropriate callbacks.

We don't know anything about the hardware or software setup of this
system, or even whether it has been firmly selected yet.  The CAN bus is
well supported by many OS's to the point where the application sees just
another network or serial-like interface.  It can handle that with an
event loop or with threads/coroutines, and communicate with the UI
through events or messages.  Anything having to do with interrupt
handlers is long since taken care of by the OS, if a reasonable OS is in
use.  Why re-develop all that from scratch?

[toc] | [prev] | [next] | [standalone]

#21427

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.

[toc] | [prev] | [next] | [standalone]

#21435

On Wed, 22 Jul 2015 00:19:10 +0000 (UTC), Andrew Smallshaw
<andrews@sdf.lonestar.org> wrote:

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

If this is a car application, the CANbus/CANopen controllers would be
the most likely type. In 11 bit CAN there are up to 2048 identifier
(source addresses) available to a whole system. A subset of these are
assigned to each of the various controllers.

Typically, each controller broadcasts these messages (with 64 bit
payload) each time it has something to say ("to whom it might
concern") and each other controller, including the display control,
listens for those CAN-IDs it is interested in. Since it knows (by
system configuration) what controller and what data is sent in an
specific message, it then can make decision what to do about it.

Typically, a controller sends out a message, when there is a
significant event in the controller, such as change of state in a
binary input or periodically. If only change of state, you need to get
the initial state by explicitly reading each CAN-Id with the RTR bit
set.

In CANopen, if the display controller is a CANopen master, it can
periodically send the SYNC message, prompting each controller to
immediately reply by the request sending the values of each message it
poses. Again, the messages are identified by the CAN-IDs and thus can
be decoded correctly.

With CANopen in the display controller sending SYNC messages, it would
be natural to do a full refresh (at least if any message contents has
changed) after a while after the SYNC message.

For a simpler CANbus system, especially if the controllers send
messages only on change of state, you definitively need e.g. a RTR
scan to get the initial states (and updated states periodically, if
some messages are lost) so some more event based display system  would
be preferable.

You should think about the whole system, not just the display.

[toc] | [prev] | [next] | [standalone]

#21428

Il 21/07/2015 10:02, pozz ha scritto:
 > [...]
> 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.
> The thing I don't like with this approach is that it could be time
> consuming. If the values change slowly, most probably only 1-5 values
> really change since the last refresh. Why do I redraw everything?
 > [...]

I forgot one situation where event-based is simpler and mor immediate 
than refresh-based approach.

Suppose you need to show a small popup in the front of other graphical 
elements for some seconds when the engine is started (or other event in 
the system under control).
Popups are graphical elements, so they are included in the HMI management.

In the refresh-based method, I have a refresh callback. IMHO it's not 
immediate to code this kind of popup:

   int old_engine_status;
   void refresh(void) {
     ...
     ... update every graphical element
     ...
     if ((engine_status() != old_engine_status)) {
       old_engine_status = engine_status();
       if (old_engine_status) {
         popup_show("Engine is turned ON");
       }
     }
     ...
   }

I need an additional variable (the old status). And there is another 
drawback. What happens if the engine is turned ON and OFF very fast 
inside a refresh window? There's a (small, not zero) probability that 
the engine change isn't captured by the refresh function if it is called 
immediately before the ON and immediately after the OFF.

With event-based approach:

   void engine_event(void) {
     update_engine_hmi();
     if (engine_status())
       popup_show("Engine is turned ON");
     }
   }

I don't need the old status variable and the code is cleaner. Moreover, 
I don't risk to loose any event.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.arch.embedded

csiph-web