RE: [Embedlets-dev] But wait there's more

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

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

Well this is one of the advantages of using standards, and there are
others for example the JAPL Remoting infrastructure I am talking about
(and have begun implementing) is compatible with .NET Ie you can also
plug the uVM controller into a .NET application and invoke remoting
services in the controller and connect it via the same UART/SLIP
connector. In actual fact what we are talking about here is WebServices
in the HttpGet format but then also we can extend this with the XML SOAP
(Gregg will like this) format down the track.

So then.. be it, a java application or embedlet using the
'JAPLRemotingServices' Stack over a javax.com controlled UART or a .NET
application using Remoting over a Windows SLIP direct connection, with
packets bounced half-way around the world and back, it can all access
the uVM remoted device in the same way. 

First pass requires a servlet to be implemented in the uVM controller.
Second pass I will support WebServices directly in the uVM devices with
auto-generated WebServices descriptor files a.k.a .NET

P.S Speaking of .NET, soon you will be able to program your uVM device
in C# or VB.NET! I have been working on a server side transform tool
that makes it all happen. Just send a .NET assembly and get back a .uvm
file.. Pretty cool huh.

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



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...] On Behalf Of
Ted Kosan
Sent: Friday, 27 June 2003 6:53 AM
To: emb...@li...
Subject: [Embedlets-dev] RE: SLIP/UART and Peer-to-peer over
master/slave


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

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


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