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


Groups > comp.arch.embedded > #21463

Re: Which scripting for embedded automation?

From Don Y <this@is.not.me.com>
Newsgroups comp.arch.embedded
Subject Re: Which scripting for embedded automation?
Date 2015-07-23 10:42 -0700
Organization Aioe.org NNTP Server
Message-ID <mor90q$21j$1@speranza.aioe.org> (permalink)
References <0e930740-22d8-4e2b-833f-bb5843437d0d@googlegroups.com>

Show all headers | View raw


On 7/23/2015 2:24 AM, abhishekkumardwivedi@gmail.com wrote:
> I was automating my home LAN. Need suggestion for automation scripting upon
> embedded Linux, to do some operations over LAN, such as scan and ping other
> devices, string like data transfer,etc. And there is need of some logic to
> parse received content. Perl, python, lua or simple shell scripting .. which
> one? There will be branch and loop operations, better to have more ready
> tools for network operations..
>
> Parser and LAN are the key here.

It depends on how many "other" tools you can call on to do any of the
"heavy-lifting" that you may require.

I've adopted Inferno/Limbo for use in my automation system.  It lets me
build real *applets* instead of just crude scripts.  So, for example,
my irrigation controller can be *coded* in Limbo -- instead of writing
something in, for example, C and dispatching that on a processor.

So, I can have a bunch of separate "processes" (multiple instances of
the same job spawned *in* the Limbo implementation) created to handle
each irrigation zone without being aware of the existence of the other
zones nor their current activities.

Each "job" queries the database service to determine the criteria for
it's irrigation zone.  It consults other services to qualify that
criteria (e.g., "how much rain have we had since I last irrigated *this*
zone?").  If it decides that irrigation is necessary, it makes a request
for some portion of the water resource (e.g., I can't turn on EVERY
irrigation zone concurrently as the supply wouldn't meet the load;  or,
there may be rules in place that require access to that resource to be
deferred:  "don't water during daylight hours", etc.).

[Think of this as requesting a portion of a LIMITED network bandwidth
from a daemon that allocates that bandwidth to clients based on preestablished
criteria]

Eventually, the daemon that administers the water supply will ensure the
master irrigation valve is open (else no water flows to the irrigation
valve manifolds) and grant the request to whichever client(s) it deems
appropriate.  It may notice that there is no water pressure from the
upstream supply (municipal water or harvested water stored on the premises)
and react accordingly.

*When* the resource is made available, it can meter the desired amount
of water to its zone.  If the resource is withdrawn for some reason
while being used, it can actively recover (re-request the resource,
throw an alarm, etc.) on behalf of the things that it is responsible
for irrigating.  And, when complete, it can signal the water daemon
of this fact (release it's allocation of that resource), close the
valve for this zone and update the database to record its actions.

Eventually, the water daemon will notice that all clients have released
their allocations and close the main irrigation valve.  It will then
signal appropriate zone controllers to briefly *open* their irrigation
valves to relieve any pressure in the irrigation line and ensure there
is no water standing in the lines above ground level (freeze protection).

With *just* a scripting language, much of this gets tedious to implement
(asynchronous comms between jobs, DBMS access, timers/timeouts, etc.).
So, you end up having to implement some of it in a HLL and some in a
scripting language -- worst of both worlds (especially if you want
folks to be able to write scripts like that without forcing them to
learn those languages).

http://www.vitanuovo.com

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


Thread

Which scripting for embedded automation? abhishekkumardwivedi@gmail.com - 2015-07-23 02:24 -0700
  Re: Which scripting for embedded automation? Les Cargill <lcargill99@comcast.com> - 2015-07-23 12:18 -0500
  Re: Which scripting for embedded automation? Don Y <this@is.not.me.com> - 2015-07-23 10:42 -0700
  Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-23 15:08 -0400
    Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-24 18:44 -0400
  Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-23 22:00 -0700
    Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-24 12:19 -0400
      Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-24 10:15 -0700
        Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-07-24 23:06 +0000
          Re: Which scripting for embedded automation? Don Y <this@is.not.me.com> - 2015-07-24 17:00 -0700
            Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-24 20:52 -0400
          Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-11-28 18:06 +0000
        Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-11-29 02:45 -0500
          Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-11-29 23:02 -0800
            Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-11-30 02:55 -0500

csiph-web