From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Thread: 103376,136c120daac2a1
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!postnews.google.com!g47g2000cwa.googlegroups.com!not-for-mail
From: "Rolf" <rolf.ebert_nospam_@gmx.net>
Newsgroups: comp.lang.ada
Subject: Re: tasksing and TCP sockets
Date: 31 Jan 2006 23:39:16 -0800
Organization: http://groups.google.com
Message-ID: <1138779556.310888.211970@g47g2000cwa.googlegroups.com>
References: <uoe1tf7c8.fsf@acm.org><SfWdnT1feI18l0LeRVn-uw@comcast.com>
   <1138748598.084128.58760@o13g2000cwo.googlegroups.com>
   <uoe1ramz9.fsf@acm.org>
NNTP-Posting-Host: 84.152.4.164
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1138779561 24011 127.0.0.1 (1 Feb 2006 07:39:21
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Wed, 1 Feb 2006 07:39:21 +0000 (UTC)
In-Reply-To: <uoe1ramz9.fsf@acm.org>
User-Agent: G2/0.2
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.8) Gecko/20051111 Firefox/1.5,gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse@google.com
Injection-Info: g47g2000cwa.googlegroups.com; posting-host=84.152.4.164;
   posting-account=X6JcNAwAAACCYFUClJvh1OjD0lgttvkm
Xref: g2news1.google.com comp.lang.ada:2732
Date: 2006-01-31T23:39:16-08:00
List-Id: <comp.lang.ada>

Stephen Leake wrote:
> "Rolf" <rolf.ebert_nospam_@gmx.net> writes:
>
> > tmoran@acm.org wrote:
> >>   But it seems to me that if the object is to use TCP to emulate hardware,
> >> one should design for that hardware and do whatever is needed with UDP or
> >> TCP to make the best emulation.  Is the intended hardware going to be
> >> polled or generate interrupts or Windows messages or what?
> >
> > The real sensor hardware will be directly connected to the I/O pins of
> > the mcu.  I think that counts as polling.  The application code simply
> > reads variables from the h/w abstraction layer.
>
> How do those "variables" get set?
>
> Does one of the IO pins generate an interrupt, that triggers the h/w
> abstraction layer "read all pins" function?
>
> Or is the h/w abstraction layer a cyclic executor, driven by a clock?
>
> How does the application know when to read the variables? By a clock,
> or some interrupt/event from the h/w abstraction layer?

The main program essentially looks like this:

loop
   Read_Sens;

   Behave;

   delay until Next;
   Next := Next + Period; -- Period == 0.1 sec typ.
end loop;

The call to Read_Sens is commented out in the simulation case and
replaced by the second thread as outlined in the original posting. The
sensor data are global variables in a package spec. The Behave reads
them whenever it thinks it needs their values.

The world simulation program at the other end of the TCP socket does
not know about the internal timing of the application (perhaps I should
add a synchronization protocol, now that I think of it)