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 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!news3.google.com!news.glorb.com!newsfeed2.telusplanet.net!newsfeed.telus.net!nntp.abs.net!news.abs.net!not-for-mail Newsgroups: comp.lang.ada Subject: Re: tasksing and TCP sockets References: <1138748598.084128.58760@o13g2000cwo.googlegroups.com> <1138779556.310888.211970@g47g2000cwa.googlegroups.com> From: Stephen Leake Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:xnTTBe2+8oYPkd/LDp3iugM0Zh8= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Feb 2006 09:52:25 -0500 NNTP-Posting-Host: 66.159.65.1 X-Complaints-To: abuse@toad.net X-Trace: news.abs.net 1138805547 66.159.65.1 (Wed, 01 Feb 2006 09:52:27 EST) NNTP-Posting-Date: Wed, 01 Feb 2006 09:52:27 EST Xref: g2news1.google.com comp.lang.ada:2734 Date: 2006-02-01T09:52:25-05:00 List-Id: "Rolf" writes: > Stephen Leake wrote: >> "Rolf" 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; Ok. So Read_Sens runs the h/w abstraction layer, Behave is the application layer. > The call to Read_Sens is commented out in the simulation case and > replaced by the second thread as outlined in the original posting. Better to not edit the code, but define an alternate body for Read_Sens. Not a big deal. > The sensor data are global variables in a package spec. The Behave > reads them whenever it thinks it needs their values. Ok. > 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) I'm still not clear where the sockets are. I think Read_Sens reads from a socket to get the simulated sensor values. Does it try to read data for all variables from the socket _every_ time it is called? Or does it check to see if some new data is available? Behave writes to a socket for user display? Then the question is what drives the simulation; does it wait for Read_Sens to read data, or just run at some rate? Does the simulation react to anything Behave does? Yes, you need synchronization between the simulation and Read_Sens, and possibly Behave. That is probably the root cause of your problem. -- -- Stephe