Re: tasksing and TCP sockets

[Stephen Leake <stephen_leake@acm.org>]

"Rolf" <rolf.ebert_nospam_@gmx.net> writes:

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

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