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

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

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