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

[James C. <ca...@vi...>]

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