embedlets-developer — Outpost Embedlet container developer list

[Embedlets-dev] A use scenario and I/O device tagging

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

Here is the use scenario I would like to eventually achieve for the assembly of
the controller for the CNC Plasma Cutter that I am building:


1) Turn on a PC and launch the Graphic Wiring Tool.

2) Instantiate a new Embedlet Container.

3) Drag a CNCController Embedlet from the Embedlet Pallet and drop it into the
container.  The CNCControllerEmbedlet has been pre-designed to use a
JAPLServoController interface to talk to the servo I/O device that it will be
controlling.

4) Plug a JSIMM backplane into a serial port on the PC (The SLIP/UART scheme
really shines here!).

5) Plug a muvium-based 3 Axis industrial servo/stepper controller JSIMM card
into the JSIMM backplane and the JAPLServoController interface that represents
this servo card should *automatically* appear inside of the wiring tool.  The
only way that I can see this happening is if the servo card were tagged with
information that described what it is.

(Systronix has been working on tag-enabling their products and I think that we
will need to figure out a way to come up with a universal device tagging scheme
which can be used to associate any I/O hardware with the JAPL interface that
represents it).

6) Drag the JAPLServoController component (that 'magically' appeared) onto the
CNCControllerEmbedlet component in order to bind them.

7)  Configure the CNCControllerEmbedlet by right-clicking on it and giving it
information like the size and resolution of the X, Y and Z axis, maximum axis
traverse rate, etc.

8)  Power up the servo drives in order to test and adjust the system's
configuration on a *live* system.

9)  After everything is working as desired, have the wiring tool package the
application and then deploy it to a TStik.

10)  Disconnect the JSIMM backplane from the PC and then plug the TStik into
the backplane.  When the TStik powers up, its Embedlet based application should
automatically re-bind the JAPL interfaces it contains with the physical I/O
devices that are plugged into the backplane.


So far there does not appear to be any fundamental reason why a use-scenario
like this cannot be realized and we seem to be doing a fairly good job of
coming up with the step-by-step subsolutions needed to solve the overall
problem.

Ted

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

[Embedlets-dev] RE: MediaController

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

Chris wrote:

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

Chris, this is a killer idea!  The first question I have is whether the
MediaController is a JAPL interface or an Embedlet Adapter?  In my mind, JAPL
interfaces were designed to represent I/O circuits like a servo controller, a
temperature sensor, an emergency stop button, etc.

For example, I want the CNC controller Embedlet that I am building to use a
something like a JAPL ServoController interface to control the movements of the
XYZ positioning system.  I want to be able to have the Embedlet send a message
like:

servoController.moveTo(X, Y, Z, Speed);

to the servo mechanism and I don't want to know how the communications between
the JAPL interface and its analogous I/O circuit actually happens so it appears
that the MediaController is positioned behind the JAPL interface somewhere.

The MediaController appears to be a clean communications mechanism that allows
a JAPL interface to easily communicate with the physical I/O circuit that it
represents so perhaps it fits the role of Adapter better?

Ted

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

[Embedlets-dev] RE: SLIP/UART and Peer-to-peer over master/slave

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

James wrote:

>I do fully intend to support any* serial transport hardware for muvium
>but let me just explain the idea for the SLIP over UART. 
[...]
>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.


And Gregg wrote:

>If you want to create a peer to peer SPI based architecture that 
>allows arbitrary interconnects, then you would do the following.

Ok, after thinking about it for a while I have decided that I very much like
the SLIP over UART strategy as a place to start.  An aspect of this that really
caught my attention was the ability to plug the I/O hardware into a PC for
development purposes and then plug it into the target embedded system for
deployment.  In my opinion this is an absolutely brilliant concept!

Also, it seems that both you and Gregg had similar strategies for implementing
peer-to-peer on top of a master/slave architecture and this seems to be an
excellent idea which addresses a number of concerns that I had with
master/slave hardware.

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

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)

[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] 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: (I2C?) SPI is *much* faster (and much less flexible)

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

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

If you want to create a peer to peer SPI based architecture that allows 
arbitrary interconnects, then you would do the following.

A thread, on the master would loop continuously with 1-100ms (depending on 
time resolution needed), requesting a single bit from each SPI slave.  When it 
gets a one bit, it would put that slave number in a ready-list, and then stop 
polling it.  This would be one threads responsibility, and this thread would 
be called the 'carrier detect' thread.

Slaves in the ready-list are now ready to transfer packets between devices.  
The ready-list thread would start clocking bytes from the slaves, and feeding 
them any traffic that is destined for them.  Each slave in the ready-list 
would have a packet queue that would be composed of a several bytes of buffer 
(slave count + a few should work).  The packets from the slaves would have, at 
the front, a packet type identifier and a destination slave number.  The data 
would then be clocked, round robin, one byte at a time.  The master would 
transfer a byte to the slave, and take the return byte and process it.  When 
the slave indicated end of data, it would be put back in the poll list.

This would give you a full peer to peer (via the master) and multi session 
network that should be able to provide a high degree of flexibility using 
SPI...
-----
gr...@cy...  (Cyte Technologies Inc)

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

[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

[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] 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: 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

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

[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 

[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

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

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


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



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...] On Behalf Of
Ted Kosan
Sent: Wednesday, 25 June 2003 7:15 AM
To: emb...@li...
Subject: RE: [Embedlets-dev] CNC machine controller -> JSIMM, TStik,
Muvium


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

James,

> So three axis have to be controlled simultaneously to make any sense 
> all of which need to be sequenced from the one controller so I imagine

> the muvium device sitting in JSIMM backplane will receive commands 
> from the embedlet and execute the commands.

I would like the muvium motion controllers to be pluggable so that if
one muvium JSIMM card could handle up to 4 axis simultaneously, then if
I plug in 2 muvium JSIMM cards I can control up to 8 axis and if I plug
in 3 cards I can control up to 12 axis, etc.



> Commands Like.
> 
> LineTo(X,Y,Z,T) - Move a linear distance in X,Y,Z in time T
> Accelerate(dx,dy,dz,T) - Accelerate from the current position at rate 
> dx,dy,dz for time T

Yes, the commands should be similar to this and I am hoping that the CNC
people in the newcim group will be able to nail down exactly what this
interface should look like.



> The JAPL interface would have these commands, we would have a proxy 
> that is instantiated in the Embedlet and the Embedlet would issue 
> these commands according to the current thing under construction in 
> addition to issuing other commands such as monitoring emergency off 
> switches or tool-changes and so forth.

This is how I envisioned it working too.



> The JAPL Proxy would send instructions to the muvium implementation 
> over some sort of infrastructure we create hopefully generic to 
> transport such commands.  The simplest is a custom protocol over uART 
> or SPI, the more generic sophisticated being a SLIP WebServices RMI 
> communication into the muvium device.
> 
> Is this the idea you have?

Yes, this is the idea!  The JSIMM backplane also has I2C available and
for some reason SLIP over I2C keeps popping into my head but I am for
going with whatever works the best.



> ?How far down the track are you with the commands you expect the 
> muvium servo controller to execute (if this is the technique you have 
> in mind) ?Is there some standard you are following for generating such

> commands

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.


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: [muvium] Embedlet Container

[Nicola K. B. <nic...@ap...>]

Christopher Smith wrote, On 24/06/2003 20.58:

> [Embedlets-dev] RE: [muvium] Embedlet Container
...
> The point of this meandering down memory lane is that there definitely 
> is a need for a low cost, noise immune, simple, deterministic, 
> short-haul network. It has been the Holy Grail of the industry since its 
> inception. The Automobile industry seems to have settled on CAN, for 
> now... but they  invent a new 'standard' every couple of years anyway.

If they will ever do so. Look at the "standard" for the programming 
languages for PLCs, how they are supported, and most of all, how 
(little) they favor WORA.

In my automation firm in Italy (we sell all over the world, mainly) we 
have seen that the most "standard" sensor connection is Rockwell 
DeviceNet, that is becoming a sort of de-facto standard with the glass 
firms in the automotive field.

The standards are:

  - INTERBUS
  - PROFIBUS
  - DeviceNet
  - CANopen
  - Ethernet.

Basically it really all boils down here where we are to what Rockwell 
and Siemens provide, that is DeviceNet and PROFIBUS. There are 
conversion boxes, but they don't always work as suggested, as the way 
standards are followed are not 100% correct.

Ethernet is catching on very well and stirs a lot of interest, but 
that's on a higher level, not directly on the sensors.

My 3rd party reference for these things is Phoenix Contact 
http://www.phoenixcontact.com/, that basically tries to make things for 
all standards, having in connectors the initial core business.

-- 
Nicola Ken Barozzi                   nic...@ap...
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

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

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

James,

> So three axis have to be controlled simultaneously to make any sense all
> of which need to be sequenced from the one controller so I imagine the
> muvium device sitting in JSIMM backplane will receive commands from the
> embedlet and execute the commands.

I would like the muvium motion controllers to be pluggable so that if one
muvium JSIMM card could handle up to 4 axis simultaneously, then if I plug in 2
muvium JSIMM cards I can control up to 8 axis and if I plug in 3 cards I can
control up to 12 axis, etc.



> Commands Like.
> 
> LineTo(X,Y,Z,T) - Move a linear distance in X,Y,Z in time T
> Accelerate(dx,dy,dz,T) - Accelerate from the current position at rate
> dx,dy,dz for time T

Yes, the commands should be similar to this and I am hoping that the CNC people
in the newcim group will be able to nail down exactly what this interface
should look like.



> The JAPL interface would have these commands, we would have a proxy that
> is instantiated in the Embedlet and the Embedlet would issue these
> commands according to the current thing under construction in addition
> to issuing other commands such as monitoring emergency off switches or
> tool-changes and so forth.

This is how I envisioned it working too.



> The JAPL Proxy would send instructions to the muvium implementation over
> some sort of infrastructure we create hopefully generic to transport
> such commands.  The simplest is a custom protocol over uART or SPI, the
> more generic sophisticated being a SLIP WebServices RMI communication
> into the muvium device.
> 
> Is this the idea you have?

Yes, this is the idea!  The JSIMM backplane also has I2C available and for some
reason SLIP over I2C keeps popping into my head but I am for going with
whatever works the best.



> ?How far down the track are you with the commands you expect the muvium
> servo controller to execute (if this is the technique you have in mind)
> ?Is there some standard you are following for generating such commands

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.


Ted

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

RE: [Embedlets-dev] CNC machine controller -> JSIMM, TStik, Muvium (go with current event model...)

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

Ted, Some Questions:

So looking at the controller it has direction and stepping requirments..
Simple enough to generate.

So three axis have to be controlled simultaneously to make any sense all
of which need to be sequenced from the one controller so I imagine the
muvium device sitting in JSIMM backplane will receive commands from the
embedlet and execute the commands.

Commands Like.

LineTo(X,Y,Z,T) - Move a linear distance in X,Y,Z in time T
Accelerate(dx,dy,dz,T) - Accelerate from the current position at rate
dx,dy,dz for time T

The JAPL interface would have these commands, we would have a proxy that
is instantiated in the Embedlet and the Embedlet would issue these
commands according to the current thing under construction in addition
to issuing other commands such as monitoring emergency off switches or
tool-changes and so forth.

The JAPL Proxy would send instructions to the muvium implementation over
some sort of infrastructure we create hopefully generic to transport
such commands.. The simplest is a custom protocol over uART or SPI, the
more generic sophisticated being a SLIP WebServices RMI communication
into the muvium device.

Is this the idea you have? 
?How far down the track are you with the commands you expect the muvium
servo controller to execute (if this is the technique you have in mind)
?Is there some standard you are following for generating such commands

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



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...] On Behalf Of
Ted Kosan
Sent: Tuesday, 24 June 2003 8:54 AM
To: emb...@li...
Subject: [Embedlets-dev] CNC machine controller -> JSIMM, TStik, Muvium
(go with current event model...)


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

James wrote:

> What we really need for the embedlets is a great example to drive out 
> the issues. I know that Ted Kosan has begun to work on the 3-Axis 
> Plasma Cutter.

And I am ready go now!


Here is the CNC Plasma Cutting machine that I have coming:

http://etwb.javadevices.org/misc/plasma1.jpg


Here are the servo drivers I am using:

http://www.geckodrive.com/item.htbml?order_id=0&item_id=G320


And here is one of the servos:

http://etwb.javadevices.org/misc/cmc-servo2.jpg


I have been keeping this project kind of quiet until I had most of the
pieces in place but I guess it is time to bring it out in the open.
During the past month or so I have helped form a group of about 25
CAD/CAM/CNC people in order to start designing a network-centric CIM
(Computer Integrated Manufacturing) framework which leverages Embedlets.

http://groups.yahoo.com/group/newcim/

The above mentioned CNC plasma cutter is going to be an Embedlets based,
100% pure Java test-bed machine for this effort and this is what
hardware the controller is going to consist of:

1) A JSimm backplane:  http://jsimm.com

2) A TStik as the host for the Embedlet container: http://tstik.com

3) A muvium on a JSIMM card plugged into the backplane in order to
inexpensively handle the application's realtime needs:
http://muvium.com.


My current thinking on the Embedlets event issue is that we really
should give the container, as currently designed, a rigerous
industrial-quality test like this to see how well it performs. 

Beyond this, the new SLEE container appears to use almost the same model
as we currently have for Embedlets:

http://java.sun.com/products/jain/article_slee_principles.html

I think that this fact validates the approach that Andrzej pushed for
and I do not see a reason to prematurely gut the current event model
before it has been tested.


James, after thinking about the Embedlets/muvium issue for a while now,
it is my opinion that muvium's most likely initial role is to provide
inexpensive realtime capabilities to an Embedlet container as described
above.  In order to fulfill this role it does not need to host an
Embedlet container, all it needs to do is to be able to implement a JAPL
interface using mostly the software foundation you have already created.

Is there any chance I can talk you into setting aside trying to
implement an Embedlets container on muvium for right now and help me to
develop a JAPL/muvium based realtime servo motor controller that can
plug into a JSIMM backplane and talk to a TStik?

I now have almost all the parts I need to put this thing together and I
also have almost all of the next two months available to devote to this
project.

I would really like to see how good of a muvium based 3+ axis servo
controller we can come up with in 2 months!


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] CNC machine controller -> JSIMM, TStik, Muvium (go with current event model...)

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

>Is there any chance I can talk you into setting aside trying to
implement an Embedlets
>container on muvium for right now and help me to develop a JAPL/muvium
based realtime 
>servo motor controller that can plug into a JSIMM backplane and talk to
a TStik?

I agree with you that muvium is a natural contender for the real-time
JAPL extensions and this is the first place for muvium to interact with
the embedlets. I am not rushing to gut the work already done, just
examining the issues and trying to draw parallels with existing
solutions. Like you have done and I will be interested to examine
further the SLEE container and parallels with the Embedlets container.

I don't like the overheads associated with the current event model.. I
would prefer to use the system event model than create a new one. I am
not in a rush to build a container for muvium as there are many many..
Did I mention many things to implement for muvium sitting at a higher
priority on my implementation 'stack' :-)

>I would really like to see how good of a muvium based 3+ axis servo
controller we can come up with in 2 months!

Well I would really like to see how much of a muvium based 3+ axis servo
controller we can come up with in 3 weeks!

I will do some research on your resources and comment shortly

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



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...] On Behalf Of
Ted Kosan
Sent: Tuesday, 24 June 2003 8:54 AM
To: emb...@li...
Subject: [Embedlets-dev] CNC machine controller -> JSIMM, TStik, Muvium
(go with current event model...)


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

James wrote:

> What we really need for the embedlets is a great example to drive out 
> the issues. I know that Ted Kosan has begun to work on the 3-Axis 
> Plasma Cutter.

And I am ready go now!


Here is the CNC Plasma Cutting machine that I have coming:

http://etwb.javadevices.org/misc/plasma1.jpg


Here are the servo drivers I am using:

http://www.geckodrive.com/item.htbml?order_id=0&item_id=G320


And here is one of the servos:

http://etwb.javadevices.org/misc/cmc-servo2.jpg


I have been keeping this project kind of quiet until I had most of the
pieces in place but I guess it is time to bring it out in the open.
During the past month or so I have helped form a group of about 25
CAD/CAM/CNC people in order to start designing a network-centric CIM
(Computer Integrated Manufacturing) framework which leverages Embedlets.

http://groups.yahoo.com/group/newcim/

The above mentioned CNC plasma cutter is going to be an Embedlets based,
100% pure Java test-bed machine for this effort and this is what
hardware the controller is going to consist of:

1) A JSimm backplane:  http://jsimm.com

2) A TStik as the host for the Embedlet container: http://tstik.com

3) A muvium on a JSIMM card plugged into the backplane in order to
inexpensively handle the application's realtime needs:
http://muvium.com.


My current thinking on the Embedlets event issue is that we really
should give the container, as currently designed, a rigerous
industrial-quality test like this to see how well it performs. 

Beyond this, the new SLEE container appears to use almost the same model
as we currently have for Embedlets:

http://java.sun.com/products/jain/article_slee_principles.html

I think that this fact validates the approach that Andrzej pushed for
and I do not see a reason to prematurely gut the current event model
before it has been tested.


James, after thinking about the Embedlets/muvium issue for a while now,
it is my opinion that muvium's most likely initial role is to provide
inexpensive realtime capabilities to an Embedlet container as described
above.  In order to fulfill this role it does not need to host an
Embedlet container, all it needs to do is to be able to implement a JAPL
interface using mostly the software foundation you have already created.

Is there any chance I can talk you into setting aside trying to
implement an Embedlets container on muvium for right now and help me to
develop a JAPL/muvium based realtime servo motor controller that can
plug into a JSIMM backplane and talk to a TStik?

I now have almost all the parts I need to put this thing together and I
also have almost all of the next two months available to devote to this
project.

I would really like to see how good of a muvium based 3+ axis servo
controller we can come up with in 2 months!


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

[Embedlets-dev] CNC machine controller -> JSIMM, TStik, Muvium (go with current event model...)

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

James wrote:

> What we really need for the embedlets is a great example to drive out
> the issues. I know that Ted Kosan has begun to work on the 3-Axis Plasma
> Cutter.

And I am ready go now!


Here is the CNC Plasma Cutting machine that I have coming:

http://etwb.javadevices.org/misc/plasma1.jpg


Here are the servo drivers I am using:

http://www.geckodrive.com/item.htbml?order_id=0&item_id=G320


And here is one of the servos:

http://etwb.javadevices.org/misc/cmc-servo2.jpg


I have been keeping this project kind of quiet until I had most of the pieces
in place but I guess it is time to bring it out in the open.  During the past
month or so I have helped form a group of about 25 CAD/CAM/CNC people in order
to start designing a network-centric CIM (Computer Integrated Manufacturing)
framework which leverages Embedlets.

http://groups.yahoo.com/group/newcim/

The above mentioned CNC plasma cutter is going to be an Embedlets based, 100%
pure Java test-bed machine for this effort and this is what hardware the
controller is going to consist of:

1) A JSimm backplane:  http://jsimm.com

2) A TStik as the host for the Embedlet container: http://tstik.com

3) A muvium on a JSIMM card plugged into the backplane in order to
inexpensively handle the application's realtime needs:  http://muvium.com.


My current thinking on the Embedlets event issue is that we really should give
the container, as currently designed, a rigerous industrial-quality test like
this to see how well it performs. 

Beyond this, the new SLEE container appears to use almost the same model as we
currently have for Embedlets:

http://java.sun.com/products/jain/article_slee_principles.html

I think that this fact validates the approach that Andrzej pushed for and I do
not see a reason to prematurely gut the current event model before it has been
tested.


James, after thinking about the Embedlets/muvium issue for a while now, it is
my opinion that muvium's most likely initial role is to provide inexpensive
realtime capabilities to an Embedlet container as described above.  In order to
fulfill this role it does not need to host an Embedlet container, all it needs
to do is to be able to implement a JAPL interface using mostly the software
foundation you have already created.

Is there any chance I can talk you into setting aside trying to implement an
Embedlets container on muvium for right now and help me to develop a
JAPL/muvium based realtime servo motor controller that can plug into a JSIMM
backplane and talk to a TStik?

I now have almost all the parts I need to put this thing together and I also
have almost all of the next two months available to devote to this project.

I would really like to see how good of a muvium based 3+ axis servo controller
we can come up with in 2 months!


Ted

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

RE: [ Christopher Smith ] [Embedlets-dev] RE: [muvium] Embedlet Container

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

>An array of null references is empty.  Any loop through the array to
deliver 
>events can check for null listener references and skip those.  On
insert, you 
>just find a null spot,

This is exactly how it is implemented in the muvium APT listeners..
(except its' done in assembler) except I am not doubling the size at the
moment rather depending on the fixed sizing ( user defineable ). Down
the trek it will be easy enough to do the slot size doubling.

The thing about the listener model is that it is well understood and
efficient which is why I prefer it for the container. What needs to be
considered is how to publish events that interact with each other. It
might be as simple a declaring Listener Interfaces..


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



-----Original Message-----
From: Gregg G. Wonderly [mailto:gre...@po...] 
Sent: Tuesday, 24 June 2003 5:20 AM
To: emb...@li...
Cc: mu...@ya...
Subject: Re: [ Christopher Smith ] [Embedlets-dev] RE: [muvium] Embedlet
Container



>In designs where the wiring is fixed
>there is no issue since it is inexpensive to create a listener array of

>known size. Dynamic add/remove becomes more challenging.

An array of null references is empty.  Any loop through the array to
deliver 
events can check for null listener references and skip those.  On
insert, you 
just find a null spot, doubling the size of the array if there are none.
Delete just sets the entry to null.

The expansion of the array is a convienence that will happen seldom
enough in 
production code that it is a great savings is weird behavior/crashes due
to 
there not being any slots.  If you allocate a counter somewhere to count

'listener list overflows', you can inspect when this happens.  You can
also 
create a bit mask wide enough to hold an entry for each listener list to
know 
which overflowed.

This gets a little tedious in administration, but the runtime overhead
is 
minmized for most small size listener lists.

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



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Looking for the latest Free IT White Papers? Visit SearchNetworking.com
to access over 500 white papers. Get instant access at
SearchNetworking.com Today
http://us.click.yahoo.com/8lAzoD/OLNGAA/witMAA/5cFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
muv...@ya...

 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ 

Re: [ Christopher Smith ] [Embedlets-dev] RE: [muvium] Embedlet Container

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

>In designs where the wiring is fixed
>there is no issue since it is inexpensive to create a listener array of
>known size. Dynamic add/remove becomes more challenging.

An array of null references is empty.  Any loop through the array to deliver 
events can check for null listener references and skip those.  On insert, you 
just find a null spot, doubling the size of the array if there are none.
Delete just sets the entry to null.

The expansion of the array is a convienence that will happen seldom enough in 
production code that it is a great savings is weird behavior/crashes due to 
there not being any slots.  If you allocate a counter somewhere to count 
'listener list overflows', you can inspect when this happens.  You can also 
create a bit mask wide enough to hold an entry for each listener list to know 
which overflowed.

This gets a little tedious in administration, but the runtime overhead is 
minmized for most small size listener lists.

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