embedlets-developer

Re: [Embedlets-dev] CNC machine controller -> JSIMM, TStik, Muvium

[Gregg G. W. <gr...@sk...>]

>Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
>_______________________________________________
>
>Well seems we are on the same wavelength with this one.
>
>>As soon as the fundamental design gets firmed up a bit, I will ask the
>experts
>>in the newcim group what command-set makes the most sense.
>
>Well then you have a lot of work left to do... The task of getting from
>a diagram of something to 'make' to a set of servo commands is not
>exactly trivial. I wonder if there is some standard for this. Is this a
>conversation for the CNC group?

Clearly the simplifying design will be one which allows the embedlet container 
send commands to the uVM devices which give them exact beginning and end of 
movement commands.  Then, the realtime requirements of the container will be 
non-existent, and the container could run on J2SE for instance...

-----
gr...@cy...  (Cyte Technologies Inc)

RE: [Embedlets-dev] CNC machine controller -> JSIMM, TStik, Muvium

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

Well I think curves are a bit tricker than just a beginning and end
because you need rate of change and that's a bit hard to send for each
line segment that makes up the resolution of the system. 

The real-time aspects may be important for example to understand how
fast the cutter is able to move in different directions and
accelerations given what it is cutting and its current speed and so
forth. Sending this as discrete commands may not be possible or very
slow to do so. So time and hence the real-time control is probably
important to the muvium JAPL servo controller implementation but you are
correct that it is not important to the container hence, as Ted has said
all along we are using muvium to solve these types of real-time problems
so the container doest have to worry about them. All the container needs
to do is to issue these commands, and It's done. The command set should
not have real-time dependencies, ie they should be atomic with respect
to time then it is just a matter of the container sequencing the
commands to the JAPL/muvium controller one after the other.

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



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...] On Behalf Of
Gregg G. Wonderly
Sent: Wednesday, 25 June 2003 5:14 PM
To: emb...@li...
Subject: Re: [Embedlets-dev] CNC machine controller -> JSIMM, TStik,
Muvium 


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


>Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
>_______________________________________________
>
>Well seems we are on the same wavelength with this one.
>
>>As soon as the fundamental design gets firmed up a bit, I will ask the
>experts
>>in the newcim group what command-set makes the most sense.
>
>Well then you have a lot of work left to do... The task of getting from

>a diagram of something to 'make' to a set of servo commands is not 
>exactly trivial. I wonder if there is some standard for this. Is this a

>conversation for the CNC group?

Clearly the simplifying design will be one which allows the embedlet
container 
send commands to the uVM devices which give them exact beginning and end
of 
movement commands.  Then, the realtime requirements of the container
will be 
non-existent, and the container could run on J2SE for instance...

-----
gr...@cy...  (Cyte Technologies Inc)




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

[Embedlets-dev] RE: JSIMM, TStik, Muvium (I2C?)

[Ted K. <tk...@ya...>]

James, 

What about using I2C for the communications channel on the JSIMM backplane? 
Since Ethernet is too expensive to implement at this low a level, it looks like
the multi-master I2C bus could serve as a 'poor man's ethernet'.

My thought is that each muvium, TStik, JStamp and JStik that is plugged into
the JSIMM backplane should be able to talk to each other as peers using the
standard Java networking APIs.  Right from the start you have been supporting
the idea of communicating with the muviums using either SLIP or PPP so what are
your thoughts on the feasibility of doing this over an I2C bus?

Ted


PS, here is some reference information on I2C and the JSIMM backplane:


http://www.esacademy.com/faq/i2c/

http://jsimm.com

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

[Embedlets-dev] RE: JSIMM, TStik, Muvium (I2C?) SPI is *much* faster.

[Bruce B. <bb...@sy...>]

At 08:36 PM 6/25/2003 -0700, Ted Kosan wrote:
>James,
>
>What about using I2C for the communications channel on the JSIMM backplane?
>Since Ethernet is too expensive to implement at this low a level, it looks 
>like
>the multi-master I2C bus could serve as a 'poor man's ethernet'.

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.

I2C can be multi-master or peer-peer though I've never seen an 
implementation. That's one advantage for it.

>My thought is that each muvium, TStik, JStamp and JStik that is plugged into
>the JSIMM backplane should be able to talk to each other as peers using the
>standard Java networking APIs.  Right from the start you have been supporting
>the idea of communicating with the muviums using either SLIP or PPP so 
>what are
>your thoughts on the feasibility of doing this over an I2C bus?

SPI is *much* faster on TINI, JStik, JStamp, etc.

Bruce


>Ted
>
>
>PS, here is some reference information on I2C and the JSIMM backplane:
>
>
>http://www.esacademy.com/faq/i2c/
>
>http://jsimm.com
>
>__________________________________
>Do you Yahoo!?
>SBC Yahoo! DSL - Now only $29.95 per month!
>http://sbc.yahoo.com

------- WWW.SYSTRONIX.COM ----------
   Real embedded Java and much more
      High speed 8051 systems
+1-801-534-1017  Salt Lake City, USA 

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

[Ted K. <tk...@ya...>]

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

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

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

[Christopher S. <cs...@oo...>]

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
>

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

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

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] JAPL Remoting Infrastructure

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

Hi Ted,

The advantage of SLIP is that it goes over any serial line. Putting the
current SLIP infrastructure over another serial 'transport' layer is not
very difficult except because the SLIP packet is processed on the fly
there is a limit to the baud it can support (which I haven't computed
yet) but at high PIC clocks speeds I expect it to be still very fast.

There are of course many many (infinite) to handle communications for
this this or any other project

Bruce has mentioned the use of the SPI Master/Slave as a way forward.
There is no doubt the clocked synchronous SPI is very fast.. It is
really just a UART (even uses the same hardware on the PIC) but with a
clocking scheme which makes it faster.

I2C is a good condender also, the PIC also has I2C hardware. I2C is
addressable which is handy but people seem to struggle with it plus it
has special pulldown wiring requirments and short-haul signal spec.

Standard UART is of course very popular and easy to use and plugs
straight into a PC and directly into java via javax.com or Visual Basic
with COMM which is why it remains a strong favourite. 

I do fully intend to support any* serial transport hardware for muvium
but let me just explain the idea for the SLIP over UART.

Imagine you have, I don't know, 30 uVM devices all connected to a serial
UART line. Each device has it's own IP address or unique Port or both.
You can connect the RX of all these devices to the TX of say the PC's
Serial PORT and then you can have a pull down through a reverse diode to
connect all the TX ports of the 30uVM's to the RX of the PC UART. The
only thing you have to ensure is to avoid collisions, I2C has an
elaborate Master/Slave clocking scheme to ensure this but if all the
muvium's are WebServers and we use SLIP protocol then only one uVM
device will respond to any one request and so collisions are not
possible. We can do discovery also very simply by simply scanning the IP
address range or Port Range using simple scanning software (hackers do
this all the time) 

So there we have a very simple and standard, polled system, not unlike
the 1-wire polled system with a master and multiple clients. The uVM
devices over UART with SLIP will support at least 115baud and possibly
several hundred baud at 40Mhz on the 18F family. I'ts not the 1Mb of SPI
but processing a protocol on the fly without a buffer to store the
packets is the actual limitation anyhow.

Now for this application, I doubt that the embedlet container generating
CAD commands will exhaust the communications capacity of (115baud / ~10
bits per byte / ~100 bytes per SLIP packet/Command / ~3 axis uVM devices
) = 38 packets/commands per axis device per second second. I imagine the
requirement will be at most one or two commands per second in fact.

The big advantage is that because it is a UART and not SPI or I2C, we
can plug the muvium controllers into the PC and test it all on the PC
embedlet container with the muvium controllers handling the real-time
direct through the PC UART and javax.com before moving it onto the
Jstamp/Tini/Embedlet Container implementation.

For uVM we can write a Servlet to handle the requests and write a Proxy
that can interface with a SLIP protocol generator (like the one that
Brill posted for cork) that can issue the commands as SLIP packets over
the UART to be instantiated by the container.

This is something we can do NOW with existing muvium technology. Later
when I extend the WebService capabilities of muvium to incorporate
WebServices RMI the 'servlet' we have to write for uVM will be automated
as will the proxy to access the RMI interface for the container. 

Hence from this we can derive something of a JAPL remoting
infrastructure I have in mind. I am willing to write the entire JAPL
Remoting Infrastructure based on this architecture using code I already
have developed for testing and development of muvium and contribute this
as open source to the embedlets project but obviously is very useful for
non-embedlet applications also for accessing muvium remote services.

I imagine the JAPL Remoting infrastructure will be simply a base class
that is extended by any device that wishes to access the JAPL remoting
services. Later this base class could offer full reflection but to begin
we could just use strings directly.

Example of useage of the JaplRemoteServices base class.

Public class ServoController extends JaplRemoteServices
{
	public ServoController(String remoteIPAddress, String
remotePort){
		super(remoteIPAddress,remotePort);
	}
	public void MoveTo(int x, int y, int z){
		japlRMI("MoveTo",new String[3] {
String.valueOf(x), 
	
String.valueOf(y), 
	
String.valueOf(z)});
	}
}

Attached is a diagram for my recommended remoting architecture for this
project.

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 5:36 AM
To: emb...@li...
Cc: bb...@sy...
Subject: [Embedlets-dev] RE: JSIMM, TStik, Muvium (I2C?)


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

James, 

What about using I2C for the communications channel on the JSIMM
backplane? 
Since Ethernet is too expensive to implement at this low a level, it
looks like the multi-master I2C bus could serve as a 'poor man's
ethernet'.

My thought is that each muvium, TStik, JStamp and JStik that is plugged
into the JSIMM backplane should be able to talk to each other as peers
using the standard Java networking APIs.  Right from the start you have
been supporting the idea of communicating with the muviums using either
SLIP or PPP so what are your thoughts on the feasibility of doing this
over an I2C bus?

Ted


PS, here is some reference information on I2C and the JSIMM backplane:


http://www.esacademy.com/faq/i2c/

http://jsimm.com

__________________________________
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

RE: [Embedlets-dev] JAPL Remoting Infrastructure

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

Hi Ted,

The advantage of SLIP is that it goes over any serial line. Putting the
current SLIP infrastructure over another serial 'transport' layer is not
very difficult except because the SLIP packet is processed on the fly
there is a limit to the baud it can support (which I haven't computed
yet) but at high PIC clocks speeds I expect it to be still very fast.

There are of course many many (infinite) to handle communications for
this this or any other project

Bruce has mentioned the use of the SPI Master/Slave as a way forward.
There is no doubt the clocked synchronous SPI is very fast.. It is
really just a UART (even uses the same hardware on the PIC) but with a
clocking scheme which makes it faster.

I2C is a good condender also, the PIC also has I2C hardware. I2C is
addressable which is handy but people seem to struggle with it plus it
has special pulldown wiring requirments and short-haul signal spec.

Standard UART is of course very popular and easy to use and plugs
straight into a PC and directly into java via javax.com or Visual Basic
with COMM which is why it remains a strong favourite. 

I do fully intend to support any* serial transport hardware for muvium
but let me just explain the idea for the SLIP over UART.

Imagine you have, I don't know, 30 uVM devices all connected to a serial
UART line. Each device has it's own IP address or unique Port or both.
You can connect the RX of all these devices to the TX of say the PC's
Serial PORT and then you can have a pull down through a reverse diode to
connect all the TX ports of the 30uVM's to the RX of the PC UART. The
only thing you have to ensure is to avoid collisions, I2C has an
elaborate Master/Slave clocking scheme to ensure this but if all the
muvium's are WebServers and we use SLIP protocol then only one uVM
device will respond to any one request and so collisions are not
possible. We can do discovery also very simply by simply scanning the IP
address range or Port Range using simple scanning software (hackers do
this all the time) 

So there we have a very simple and standard, polled system, not unlike
the 1-wire polled system with a master and multiple clients. The uVM
devices over UART with SLIP will support at least 115baud and possibly
several hundred baud at 40Mhz on the 18F family. I'ts not the 1Mb of SPI
but processing a protocol on the fly without a buffer to store the
packets is the actual limitation anyhow.

Now for this application, I doubt that the embedlet container generating
CAD commands will exhaust the communications capacity of (115baud / ~10
bits per byte / ~100 bytes per SLIP packet/Command / ~3 axis uVM devices
) = 38 packets/commands per axis device per second second. I imagine the
requirement will be at most one or two commands per second in fact.

The big advantage is that because it is a UART and not SPI or I2C, we
can plug the muvium controllers into the PC and test it all on the PC
embedlet container with the muvium controllers handling the real-time
direct through the PC UART and javax.com before moving it onto the
Jstamp/Tini/Embedlet Container implementation.

For uVM we can write a Servlet to handle the requests and write a Proxy
that can interface with a SLIP protocol generator (like the one that
Brill posted for cork) that can issue the commands as SLIP packets over
the UART to be instantiated by the container.

This is something we can do NOW with existing muvium technology. Later
when I extend the WebService capabilities of muvium to incorporate
WebServices RMI the 'servlet' we have to write for uVM will be automated
as will the proxy to access the RMI interface for the container. 

Hence from this we can derive something of a JAPL remoting
infrastructure I have in mind. I am willing to write the entire JAPL
Remoting Infrastructure based on this architecture using code I already
have developed for testing and development of muvium and contribute this
as open source to the embedlets project but obviously is very useful for
non-embedlet applications also for accessing muvium remote services.

I imagine the JAPL Remoting infrastructure will be simply a base class
that is extended by any device that wishes to access the JAPL remoting
services. Later this base class could offer full reflection but to begin
we could just use strings directly.

Example of useage of the JaplRemoteServices base class.

Public class ServoController extends JaplRemoteServices
{
	public ServoController(String remoteIPAddress, String
remotePort){
		super(remoteIPAddress,remotePort);
	}
	public void MoveTo(int x, int y, int z){
		japlRMI("MoveTo",new String[3] {
String.valueOf(x), 
	
String.valueOf(y), 
	
String.valueOf(z)});
	}
}

Attached is a diagram for my recommended remoting architecture for this
project.

http://www.muvium.com/projects/remoting/JAPLWebServicesRemotingInfrastru
ctureArchitecture.pdf

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 5:36 AM
To: emb...@li...
Cc: bb...@sy...
Subject: [Embedlets-dev] RE: JSIMM, TStik, Muvium (I2C?)


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

James, 

What about using I2C for the communications channel on the JSIMM
backplane? 
Since Ethernet is too expensive to implement at this low a level, it
looks like the multi-master I2C bus could serve as a 'poor man's
ethernet'.

My thought is that each muvium, TStik, JStamp and JStik that is plugged
into the JSIMM backplane should be able to talk to each other as peers
using the standard Java networking APIs.  Right from the start you have
been supporting the idea of communicating with the muviums using either
SLIP or PPP so what are your thoughts on the feasibility of doing this
over an I2C bus?

Ted


PS, here is some reference information on I2C and the JSIMM backplane:


http://www.esacademy.com/faq/i2c/

http://jsimm.com

__________________________________
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

RE: [Embedlets-dev] JAPL Remoting Infrastructure Diagram again.. sorry

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

http://www.muvium.com/projects/remoting/JAPLRMI.pdf

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



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...] On Behalf Of
James Caska
Sent: Thursday, 26 June 2003 9:38 AM
To: emb...@li...
Cc: mu...@ya...
Subject: RE: [Embedlets-dev] JAPL Remoting Infrastructure


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

Hi Ted,

The advantage of SLIP is that it goes over any serial line. Putting the
current SLIP infrastructure over another serial 'transport' layer is not
very difficult except because the SLIP packet is processed on the fly
there is a limit to the baud it can support (which I haven't computed
yet) but at high PIC clocks speeds I expect it to be still very fast.

There are of course many many (infinite) to handle communications for
this this or any other project

Bruce has mentioned the use of the SPI Master/Slave as a way forward.
There is no doubt the clocked synchronous SPI is very fast.. It is
really just a UART (even uses the same hardware on the PIC) but with a
clocking scheme which makes it faster.

I2C is a good condender also, the PIC also has I2C hardware. I2C is
addressable which is handy but people seem to struggle with it plus it
has special pulldown wiring requirments and short-haul signal spec.

Standard UART is of course very popular and easy to use and plugs
straight into a PC and directly into java via javax.com or Visual Basic
with COMM which is why it remains a strong favourite. 

I do fully intend to support any* serial transport hardware for muvium
but let me just explain the idea for the SLIP over UART.

Imagine you have, I don't know, 30 uVM devices all connected to a serial
UART line. Each device has it's own IP address or unique Port or both.
You can connect the RX of all these devices to the TX of say the PC's
Serial PORT and then you can have a pull down through a reverse diode to
connect all the TX ports of the 30uVM's to the RX of the PC UART. The
only thing you have to ensure is to avoid collisions, I2C has an
elaborate Master/Slave clocking scheme to ensure this but if all the
muvium's are WebServers and we use SLIP protocol then only one uVM
device will respond to any one request and so collisions are not
possible. We can do discovery also very simply by simply scanning the IP
address range or Port Range using simple scanning software (hackers do
this all the time) 

So there we have a very simple and standard, polled system, not unlike
the 1-wire polled system with a master and multiple clients. The uVM
devices over UART with SLIP will support at least 115baud and possibly
several hundred baud at 40Mhz on the 18F family. I'ts not the 1Mb of SPI
but processing a protocol on the fly without a buffer to store the
packets is the actual limitation anyhow.

Now for this application, I doubt that the embedlet container generating
CAD commands will exhaust the communications capacity of (115baud / ~10
bits per byte / ~100 bytes per SLIP packet/Command / ~3 axis uVM devices
) = 38 packets/commands per axis device per second second. I imagine the
requirement will be at most one or two commands per second in fact.

The big advantage is that because it is a UART and not SPI or I2C, we
can plug the muvium controllers into the PC and test it all on the PC
embedlet container with the muvium controllers handling the real-time
direct through the PC UART and javax.com before moving it onto the
Jstamp/Tini/Embedlet Container implementation.

For uVM we can write a Servlet to handle the requests and write a Proxy
that can interface with a SLIP protocol generator (like the one that
Brill posted for cork) that can issue the commands as SLIP packets over
the UART to be instantiated by the container.

This is something we can do NOW with existing muvium technology. Later
when I extend the WebService capabilities of muvium to incorporate
WebServices RMI the 'servlet' we have to write for uVM will be automated
as will the proxy to access the RMI interface for the container. 

Hence from this we can derive something of a JAPL remoting
infrastructure I have in mind. I am willing to write the entire JAPL
Remoting Infrastructure based on this architecture using code I already
have developed for testing and development of muvium and contribute this
as open source to the embedlets project but obviously is very useful for
non-embedlet applications also for accessing muvium remote services.

I imagine the JAPL Remoting infrastructure will be simply a base class
that is extended by any device that wishes to access the JAPL remoting
services. Later this base class could offer full reflection but to begin
we could just use strings directly.

Example of useage of the JaplRemoteServices base class.

Public class ServoController extends JaplRemoteServices
{
	public ServoController(String remoteIPAddress, String
remotePort){
		super(remoteIPAddress,remotePort);
	}
	public void MoveTo(int x, int y, int z){
		japlRMI("MoveTo",new String[3] {
String.valueOf(x), 
	
String.valueOf(y), 
	
String.valueOf(z)});
	}
}

Attached is a diagram for my recommended remoting architecture for this
project.

http://www.muvium.com/projects/remoting/JAPLWebServicesRemotingInfrastru
ctureArchitecture.pdf

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 5:36 AM
To: emb...@li...
Cc: bb...@sy...
Subject: [Embedlets-dev] RE: JSIMM, TStik, Muvium (I2C?)


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

James, 

What about using I2C for the communications channel on the JSIMM
backplane? 
Since Ethernet is too expensive to implement at this low a level, it
looks like the multi-master I2C bus could serve as a 'poor man's
ethernet'.

My thought is that each muvium, TStik, JStamp and JStik that is plugged
into the JSIMM backplane should be able to talk to each other as peers
using the standard Java networking APIs.  Right from the start you have
been supporting the idea of communicating with the muviums using either
SLIP or PPP so what are your thoughts on the feasibility of doing this
over an I2C bus?

Ted


PS, here is some reference information on I2C and the JSIMM backplane:


http://www.esacademy.com/faq/i2c/

http://jsimm.com

__________________________________
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

RE: [Embedlets-dev] JAPL Remoting Infrastructure Diagram again.. sorry

[Christopher S. <cs...@oo...>]

James,

For some reason you are showing up multiple times on the embedlets and
jstamp, muvium boards.

Chris
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> http://www.muvium.com/projects/remoting/JAPLRMI.pdf
>
> James Caska
> www.muvium.com
> uVM - 'Java Bred for Embedded'
>
>
>
> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...] On Behalf Of
> James Caska
> Sent: Thursday, 26 June 2003 9:38 AM
> To: emb...@li...
> Cc: mu...@ya...
> Subject: RE: [Embedlets-dev] JAPL Remoting Infrastructure
>
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Hi Ted,
>
> The advantage of SLIP is that it goes over any serial line. Putting the
> current SLIP infrastructure over another serial 'transport' layer is not
> very difficult except because the SLIP packet is processed on the fly
> there is a limit to the baud it can support (which I haven't computed
> yet) but at high PIC clocks speeds I expect it to be still very fast.
>
> There are of course many many (infinite) to handle communications for
> this this or any other project
>
> Bruce has mentioned the use of the SPI Master/Slave as a way forward.
> There is no doubt the clocked synchronous SPI is very fast.. It is
> really just a UART (even uses the same hardware on the PIC) but with a
> clocking scheme which makes it faster.
>
> I2C is a good condender also, the PIC also has I2C hardware. I2C is
> addressable which is handy but people seem to struggle with it plus it
> has special pulldown wiring requirments and short-haul signal spec.
>
> Standard UART is of course very popular and easy to use and plugs
> straight into a PC and directly into java via javax.com or Visual Basic
> with COMM which is why it remains a strong favourite.
>
> I do fully intend to support any* serial transport hardware for muvium
> but let me just explain the idea for the SLIP over UART.
>
> Imagine you have, I don't know, 30 uVM devices all connected to a serial
> UART line. Each device has it's own IP address or unique Port or both.
> You can connect the RX of all these devices to the TX of say the PC's
> Serial PORT and then you can have a pull down through a reverse diode to
> connect all the TX ports of the 30uVM's to the RX of the PC UART. The
> only thing you have to ensure is to avoid collisions, I2C has an
> elaborate Master/Slave clocking scheme to ensure this but if all the
> muvium's are WebServers and we use SLIP protocol then only one uVM
> device will respond to any one request and so collisions are not
> possible. We can do discovery also very simply by simply scanning the IP
> address range or Port Range using simple scanning software (hackers do
> this all the time)
>
> So there we have a very simple and standard, polled system, not unlike
> the 1-wire polled system with a master and multiple clients. The uVM
> devices over UART with SLIP will support at least 115baud and possibly
> several hundred baud at 40Mhz on the 18F family. I'ts not the 1Mb of SPI
> but processing a protocol on the fly without a buffer to store the
> packets is the actual limitation anyhow.
>
> Now for this application, I doubt that the embedlet container generating
> CAD commands will exhaust the communications capacity of (115baud / ~10
> bits per byte / ~100 bytes per SLIP packet/Command / ~3 axis uVM devices
> ) = 38 packets/commands per axis device per second second. I imagine the
> requirement will be at most one or two commands per second in fact.
>
> The big advantage is that because it is a UART and not SPI or I2C, we
> can plug the muvium controllers into the PC and test it all on the PC
> embedlet container with the muvium controllers handling the real-time
> direct through the PC UART and javax.com before moving it onto the
> Jstamp/Tini/Embedlet Container implementation.
>
> For uVM we can write a Servlet to handle the requests and write a Proxy
> that can interface with a SLIP protocol generator (like the one that
> Brill posted for cork) that can issue the commands as SLIP packets over
> the UART to be instantiated by the container.
>
> This is something we can do NOW with existing muvium technology. Later
> when I extend the WebService capabilities of muvium to incorporate
> WebServices RMI the 'servlet' we have to write for uVM will be automated
> as will the proxy to access the RMI interface for the container.
>
> Hence from this we can derive something of a JAPL remoting
> infrastructure I have in mind. I am willing to write the entire JAPL
> Remoting Infrastructure based on this architecture using code I already
> have developed for testing and development of muvium and contribute this
> as open source to the embedlets project but obviously is very useful for
> non-embedlet applications also for accessing muvium remote services.
>
> I imagine the JAPL Remoting infrastructure will be simply a base class
> that is extended by any device that wishes to access the JAPL remoting
> services. Later this base class could offer full reflection but to begin
> we could just use strings directly.
>
> Example of useage of the JaplRemoteServices base class.
>
> Public class ServoController extends JaplRemoteServices
> {
> 	public ServoController(String remoteIPAddress, String
> remotePort){
> 		super(remoteIPAddress,remotePort);
> 	}
> 	public void MoveTo(int x, int y, int z){
> 		japlRMI("MoveTo",new String[3] {
> String.valueOf(x),
>
> String.valueOf(y),
>
> String.valueOf(z)});
> 	}
> }
>
> Attached is a diagram for my recommended remoting architecture for this
> project.
>
> http://www.muvium.com/projects/remoting/JAPLWebServicesRemotingInfrastru
> ctureArchitecture.pdf
>
> 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 5:36 AM
> To: emb...@li...
> Cc: bb...@sy...
> Subject: [Embedlets-dev] RE: JSIMM, TStik, Muvium (I2C?)
>
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> James,
>
> What about using I2C for the communications channel on the JSIMM
> backplane?
> Since Ethernet is too expensive to implement at this low a level, it
> looks like the multi-master I2C bus could serve as a 'poor man's
> ethernet'.
>
> My thought is that each muvium, TStik, JStamp and JStik that is plugged
> into the JSIMM backplane should be able to talk to each other as peers
> using the standard Java networking APIs.  Right from the start you have
> been supporting the idea of communicating with the muviums using either
> SLIP or PPP so what are your thoughts on the feasibility of doing this
> over an I2C bus?
>
> Ted
>
>
> PS, here is some reference information on I2C and the JSIMM backplane:
>
>
> http://www.esacademy.com/faq/i2c/
>
> http://jsimm.com
>
> __________________________________
> 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: JSIMM, TStik, Muvium (I2C?)

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

Hi Ted,

The advantage of SLIP is that it goes over any serial line. Putting the
current SLIP infrastructure over another serial 'transport' layer is not
very difficult except because the SLIP packet is processed on the fly
there is a limit to the baud it can support (which I haven't computed
yet) but at high PIC clocks speeds I expect it to be still very fast.

There are of course many many (infinite) to handle communications for
this this or any other project

Bruce has mentioned the use of the SPI Master/Slave as a way forward.
There is no doubt the clocked synchronous SPI is very fast.. It is
really just a UART (even uses the same hardware on the PIC) but with a
clocking scheme which makes it faster.

I2C is a good condender also, the PIC also has I2C hardware. I2C is
addressable which is handy but people seem to struggle with it plus it
has special pulldown wiring requirments and short-haul signal spec.

Standard UART is of course very popular and easy to use and plugs
straight into a PC and directly into java via javax.com or Visual Basic
with COMM which is why it remains a strong favourite. 

I do fully intend to support any* serial transport hardware for muvium
but let me just explain the idea for the SLIP over UART.

Imagine you have, I don't know, 30 uVM devices all connected to a serial
UART line. Each device has it's own IP address or unique Port or both.
You can connect the RX of all these devices to the TX of say the PC's
Serial PORT and then you can have a pull down through a reverse diode to
connect all the TX ports of the 30uVM's to the RX of the PC UART. The
only thing you have to ensure is to avoid collisions, I2C has an
elaborate Master/Slave clocking scheme to ensure this but if all the
muvium's are WebServers and we use SLIP protocol then only one uVM
device will respond to any one request and so collisions are not
possible. We can do discovery also very simply by simply scanning the IP
address range or Port Range using simple scanning software (hackers do
this all the time) 

So there we have a very simple and standard, polled system, not unlike
the 1-wire polled system with a master and multiple clients. The uVM
devices over UART with SLIP will support at least 115baud and possibly
several hundred baud at 40Mhz on the 18F family. I'ts not the 1Mb of SPI
but processing a protocol on the fly without a buffer to store the
packets is the actual limitation anyhow.

Now for this application, I doubt that the embedlet container generating
CAD commands will exhaust the communications capacity of (115baud / ~10
bits per byte / ~100 bytes per SLIP packet/Command / ~3 axis uVM devices
) = 38 packets/commands per axis device per second second. I imagine the
requirement will be at most one or two commands per second in fact.

The big advantage is that because it is a UART and not SPI or I2C, we
can plug the muvium controllers into the PC and test it all on the PC
embedlet container with the muvium controllers handling the real-time
direct through the PC UART and javax.com before moving it onto the
Jstamp/Tini/Embedlet Container implementation.

For uVM we can write a Servlet to handle the requests and write a Proxy
that can interface with a SLIP protocol generator (like the one that
Brill posted for cork) that can issue the commands as SLIP packets over
the UART to be instantiated by the container.

This is something we can do NOW with existing muvium technology. Later
when I extend the WebService capabilities of muvium to incorporate
WebServices RMI the 'servlet' we have to write for uVM will be automated
as will the proxy to access the RMI interface for the container. 

Hence from this we can derive something of a JAPL remoting
infrastructure I have in mind. I am willing to write the entire JAPL
Remoting Infrastructure based on this architecture using code I already
have developed for testing and development of muvium and contribute this
as open source to the embedlets project but obviously is very useful for
non-embedlet applications also for accessing muvium remote services.

I imagine the JAPL Remoting infrastructure will be simply a base class
that is extended by any device that wishes to access the JAPL remoting
services. Later this base class could offer full reflection but to begin
we could just use strings directly.

Example of useage of the JaplRemoteServices base class.

Public class ServoController extends JaplRemoteServices
{
	public ServoController(String remoteIPAddress, String
remotePort){
		super(remoteIPAddress,remotePort);
	}
	public void MoveTo(int x, int y, int z){
		japlRMI("MoveTo",new String[3] {
String.valueOf(x), 
	
String.valueOf(y), 
	
String.valueOf(z)});
	}
}

Attached is a diagram for my recommended remoting architecture for this
project.

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 5:36 AM
To: emb...@li...
Cc: bb...@sy...
Subject: [Embedlets-dev] RE: JSIMM, TStik, Muvium (I2C?)


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

James, 

What about using I2C for the communications channel on the JSIMM
backplane? 
Since Ethernet is too expensive to implement at this low a level, it
looks like the multi-master I2C bus could serve as a 'poor man's
ethernet'.

My thought is that each muvium, TStik, JStamp and JStik that is plugged
into the JSIMM backplane should be able to talk to each other as peers
using the standard Java networking APIs.  Right from the start you have
been supporting the idea of communicating with the muviums using either
SLIP or PPP so what are your thoughts on the feasibility of doing this
over an I2C bus?

Ted


PS, here is some reference information on I2C and the JSIMM backplane:


http://www.esacademy.com/faq/i2c/

http://jsimm.com

__________________________________
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