Streams in squeak.

Ned Konz ned at squeakland.org
Mon Apr 18 15:13:51 UTC 2005


On Monday 18 April 2005 3:42 am, François THIMON wrote:

> > I can't imagine what sending I2C to a socket would be like, but that's
> > interesting.
>
> I think I'd encapsulate the orders in strings (I could use XML tags an copy
> RPC, for instance). The server would then just decapsulate them with a XML
> parser.

I don't think that using XML here would get you anything but slowness and 
complexity.

> > Further, there isn't a clean model for bidirectional streams
> > (command/response) in Squeak.
>
> Are you allunding to the fact that a stream is not meant to be used for a
> dialog-based communication but rather to handle messages coming at
> unpredictable moments?

Streams generally handle data, not messages. Their advantages include 
buffering and the ability to read (or write) different-sized chunks of data.

In your case, the problem (sending messages to robots) is not one that 
requires streams and their buffering.

In fact, because of the need to respond quickly to status changes, you 
probably don't want much buffering at all.

> If so, as you say, I may need another model : I2C is 
> designed to always have an answer for one given request.

I'm not sure what you mean. I2C itself just expects to be able to have the 
master address a slave, maybe send data to it, or maybe receive data from it, 
and be able to find out whether the slave exists or not, and when the slave 
is done receiving or sending data.

What meaning you assign to those messages is up to you (assuming you're 
designing both the master and the slave devices).

> My device is a kind of robot made out of two commands modules transmitting
> data between the motors/captors/LED and the software. It comes from our
> students and it could understant what we want him to.

Then I would suggest coming up with a vocabulary based on your robotics needs, 
and representing that in a way that fits I2C. Anything you can express in I2C 
messages should also be able to be expressed over a serial or TCP stream 
protocol. But I would try to stay message-based.

One reason is that you'll want to know right away about whether a slave device 
is there or not, and whether or not it accepted the command (or was able to 
respond with data). A strategy that I often use in similar cases is to pass 
back some of the slave status as part of every response. So you might have a 
communication like:

[slave1 and slave2 are motor controllers; slave3 and slave4 are position 
encoders; slave5 is a bank of LEDs]

Master W => slave1: turn on 100%
Master R <= slave1: [ACK, no fault, power OK]
Master W => slave3: report position
Master R <= slave3: [ACK, no fault, power OK] 10300
Master W => slave2: turn on 50%
Master R <= slave2: [ACK, fault, power bad]
Master W => slave2: report fault conditions
Master R <= slave2: no motor power, motor overtemp

where the first byte of every slave response has several bits encoded into it:
ACK - Slave accepts command (actual I2C ACK is out-of-band)
Fault - set if some fault (further query needed for more specific fault 
information)
Power OK - power supply within limits

etc.

> Do you mean I should send high-level data through the SharedQueue and let
> the receiver decode this data afterwards (for example, the abstract command
> "go-forward" would trigger a I2C sequence with START, ADDRESS RESOLUTION,
> ACK, DATA, STOP).

Exactly.

So your SharedQueue could hold commands, and there could be a SharedQueue back 
to each requester:

=SharedQueue for commands=> Controller1
=SharedQueue for responses=> Client1
=SharedQueue for responses=> Client2

And each message could contain the identity of the SharedQueue to pass the 
response back to.

Each pair of masterW/masterR messages in the example above would be generated 
by a single command; the response from the slave would be packaged and 
reported back to the requesting client.

-- 
Ned Konz
http://bike-nomad.com/squeak/



More information about the Squeak-dev mailing list