On Thursday 14 April 2005 2:21 am, François THIMON wrote:

> I currently work for a project in which I have to transmit orders with the
> I2C protocol. For the moment, I already have an I2CProtocol class that can
> send commands (as highSDA, lowSCL, sendACK and so on) to (almost) any kind
> of link (either a socket, a hardware port, ...). 

I can't imagine what sending I2C to a socket would be like, but that's 
interesting.

> My teachers would like me 
> to make my class as a stream : I2CStream. Currently I don't really think
> I'm fluent enough with the notion of stream, but I can still read any API's
> documentation on my own.

But I2C typically is message oriented, not stream oriented (that is, it's more 
or less a datagram protocol). Each message has an address, a read/write bit, 
and optional data. I'm not sure that it would make sense to make it into a 
stream.

Or maybe you could layer a stream on top of the I2C messages (but then you'd 
need to encapsulate a stream protocol in I2C).

Further, there isn't a clean model for bidirectional streams 
(command/response) in Squeak.

In my experience with I2C [1], I've found that the need to define a protocol 
that defines a message structure precludes making a general I2C stream 
interface.

I don't know what kind of device you're talking to, but does it really 
understand a stream protocol?

Typical in my experience is this kind of protocol is something like the SMBus 
protocol (see http://www.charmed.com/txt/smbus-protocol.txt), which defines a 
number of different read/write message formats that are defined by the 
receiving devices themselves.

> My questions are :
>  - according to you, what should I do in order to conceive a class that
> "fits" in squeak's current framework? What functionalities should my stream
> have? - is there already some project or code I should inspire myself from?

I'd probably use a SharedQueue (which is sort of like a double-ended stream) 
to connect to an I2C handler; its contents would be transaction-level objects 
which would then be converted into a series of I2C messages.

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

[1] including:
- writing code on PIC and AVR microcontrollers
- designing I2C buffer and mux hardware for 126-slave, 8-bus I2C system
- creating and debugging master/slave communications protocols using I2C
- doing SMBus smart battery communications
- writing a Linux I2C bit-banging driver for a Maxim I2C interface board
- writing a Perl module called Device::SMBus for I2C and SMBus/smart battery 
communications