RE: [Embedlets-dev] RE: (I2C?) SPI is much faster (and much less flexible)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Yes, I agree entirely. If we define the top level remoting interface,
which could/should probably look a little like the reflection interface
then how that is 'implemented' should not matter to the embedlet
container. 

Love your work on the XML ;-)

James Caska
www.muvium.com
uVM - 'Java Bred for Embedded'

-----Original Message-----
From: emb...@li...
[mailto:emb...@li...] On Behalf Of
Christopher Smith
Sent: Thursday, 26 June 2003 9:26 PM
To: emb...@li...
Subject: RE: [Embedlets-dev] RE: (I2C?) SPI is *much* faster (and much
less flexible)

Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
_______________________________________________

Here is an idea:

Define a standard API that supports any physical layer. The important
thing is that developers can put a multiprocessor application together
and not have to worry about how devices talk to each other, just that it
will happen. This could encompass all master/slave and client/server
interaction with a relatively simple protocol.

The physical layer will be implemented based on demanded by users and
eventually one of those will dominate.

If the software protocol is accepted then no one will be locked into a
particular physical medium and the decision of which to use will be a
simple cost/benefit tradeoff for the individual project not a life
changing  event.

I am about to release the Embedlet TCP/IP protocol that implements a
simple Request/Response interaction using  XML as the packaging layer.
It uses a 'loose' XML structure to allow a light weight parser to decode
it. I have used this protocol on a PalmOS/SuperWaba app that
communicates via IrDA so it is fits smaller devices quite well.

The proposed API layer including JAPL would consist of:

interface/class CommunicationManager
	- sendRequest(Request request, boolean wait)
	- Response getResponse()
	- addListener(CommunicationListener listener)
	- sendObject(Object object) // serialization method
	- Object getObject() // deserialization method

interface/class Request
	- get/setCommand(int command)
	- addParameter(String name, String value)
	- addParameter(Parameter parameter)
	- String getParameter(int index)
	- String getParameter(String name)
	-
interface/class Response
	- int getStatus()
	- Object getPayload() // The response can carry an object back
with it

interface CommunicationEvent
	class RequestEvent implements CommunicationEvent
		- Request getRequest()
	class ResponseEvent implements CommunicationEvent
		- Response getResponse()

interface CommunicationListener
	- void event(Communication event)

// JAPL layer
interface MediaListener
	- void event(MediaEvent)

interface MediaEvent
	class ReceiveEvent implements MediaEvent
		- InputStream getInput()

	class SendCompleteEvent implements MediaEvent
		- OutputStream getOutput()

interface MediaController extends InputStream, OutputStream
	- open()
	- close()
	- byte readByte()
	- writeByte(byte b)
	- etc

class AbstractMediaController implements MediaController
	- utiliy methods

// This is the media specific implementation
class xxxMediaController extends MediaController
	- implmentation methods

If we all agree on the MediaController interface then everyone can
implement their favorite hardware device in their xxxMediaController and
expect a plug and play deployment.

This could be the first operational JAPL!

Lets go!

>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Hi Ted,
>
> I do agree that one limitation of the UART scheme is the lack of the 
> ability for the remote device to be the master and hence generate 
> asynchronous events as supported by I2C. However using your idea of 
> flexibility first, the UART scheme is far simpler to implement and 
> test using existing UART hardware and will cover the vast majority of 
> applications.
>
> The I2C version of the remoting infrastructure will require a more 
> complex callback mechanism to the registered listeners to the JAPL 
> events and also will require complex multi-master mechanisms with 
> solid collision detection handling and interrupted packet sending and 
> prioritised queing and with the dedicated I2C hardware so you can't 
> test from the PC or any embedlet platform that doesn't have I2C. For 
> example imagine a mobile phone running an embedlet container.. It 
> might have an irda port which can transport serial communications to 
> an muvium device with an irda connection and then we can do remoting 
> over JAPL remoting services infrastructure directly into the emedded 
> muvium JAPL application right from the embedlet in your mobile phone..

> Nice huh.
>
> The I2C can be done of course and will be very useful and more 
> powerful but I don't think it is needed for this application and I 
> think it should be the 2nd generation implementation.
>
> James Caska
> www.muvium.com
> uVM - 'Java Bred for Embedded'
>
>
>
> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...] On Behalf Of 
> Ted Kosan
> Sent: Thursday, 26 June 2003 8:56 AM
> To: emb...@li...
> Subject: Re: [Embedlets-dev] RE: (I2C?) SPI is *much* faster (and much

> less flexible)
>
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Bruce wrote:
>
> > I2C is about 100 kbits (if memory serves), SPI can be a few MBits. 
> > If you have to pick a standard for speed SPI wins.
>
> I would say to choose flexibility over speed in every case except 
> those that absolutely need maximum speed.  As an example, C is the 
> current language speed standard and yet slow, flexible Java is 
> replacing it for most applications where maximum speed is not the main

> design constraint.
>
> Beyond this, the original I2C bus was limited to 100kbits but since 
> then they have come out with a 400kbit spec:
>
> http://www.esacademy.com/faq/i2c/general/i2cfastm.htm
>
>
> and a 3.4Mbit spec:
>
>
> http://www.esacademy.com/faq/i2c/general/i2chighspeedm.htm
>
>
>
> > I2C can be multi-master or peer-peer though I've never seen an 
> > implementation. That's one advantage for it.
>
> If I2C can be made to work like a mini-ethernet then it is exactly 
> what I am looking for because this is the way to maximize Java's 
> potential. What I am after is a baby ethernet-like network for the 
> JSIMM backplane, not a peripheral expansion bus which is what SPI and 
> I2C have traditionally been used for.
>
> I think that one reason one does not see many peer-to-peer I2C 
> implementations is that the software needed to develop a distributed 
> application based on a peer-to-peer infrastructure is extremely tough 
> to write from scratch.  Java solves this problem.
>
>
>
> > SPI is *much* faster on TINI, JStik, JStamp, etc.
>
> I like the motto 'Flexibility over speed'.  This principle explains 
> why a lot more minivans are sold anually than dragsters, and it is my 
> opinion that I2C based peer-to-peer has the potential to outsell SPI 
> on the JSIMM backplane if implemented correctly.
>
>
> Ted
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting 
> Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly 
> Commission! INetU Dedicated Managed Hosting 
> http://www.inetu.net/partner/index.php
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting 
> Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly 
> Commission! INetU Dedicated Managed Hosting 
> http://www.inetu.net/partner/index.php
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>

-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Embedlets-developer mailing list
Emb...@li...
https://lists.sourceforge.net/lists/listinfo/embedlets-developer

RE: [Embedlets-dev] RE: (I2C?) SPI is *much* faster (and much less flexible)