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

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

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
>