embedlets-developer — Outpost Embedlet container developer list

Re: [Embedlets-dev] Interesting problem surely not unsolvable

[Brill P. <br...@pa...>]

heh... I'm still kurking on the list... But never got my time back.

In the end it was demanding work that stole my time... 3 years and two children later, I have even less time than I did then!

Its still a subject of interest for me but for now i'll watch from the side lines ;)

-- Brill Pappin

-----Original Message-----
   >From: "Ted Kosan"<tk...@ya...>
   >Sent: 25/01/06 2:46:26 PM
   >To: "emb...@li..."<emb...@li...>
   >Subject: Re: [Embedlets-dev] Interesting problem surely not unsolvable
   >
   >Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
   >_______________________________________________
   >
   >John wrote:
   >
   >> I appreciate this cultural difference between Computer science and
   >> traditional embeded systems people.
   >> 
   >> It is very positive that this project has identified the problem.
   >> 
   >> I fear that it appears to be failing because in trying to solve the issue
   >> it may have been adding another layer of complexity.
   >
   >I was the person who added the materials about the CS vs. traditional embedded
   >systems developers :-) My thought was that yet another layer would be added on
   >top of the Embedlets layer which would allow the Embedlet components to be
   >graphically wired together using a swing-based tool.  The graphical wiring
   >layer was never developed however for a number of reasons.
   >
   >
   >
   >
   >> I would very much like to know what work had been done before things
   >> slowed down to see if there is anything which can be used from this.
   >> 
   >> Is everything done detailed in the mailing list or is there any unfinished
   >> work, Lurking?
   >
   >What happened was that development pretty much stopped as soon as the code base
   >was proven to work.  There were 4 or 5 of us working on this project and I
   >think each one of us stopped development for a different reason.
   >
   >My main reason for working on Embedlets was that I was interested in using it
   >to help solve the CS/traditional embedded developer problem listed above.
   >
   >My main reason for stopping after Embedlets was proven to work is that I
   >decided that running an easier to learn language than Java, like BASIC or
   >Jython, on top of Java was a better way to solve the problem I was ( and am )
   >working on.
   >
   >Anyway, the Embedlet code base is in the CVS and it does work.  As far as I
   >know, the email list archive contains all of the discussions which are relevant
   >to the codebase.  Beyond this, if you have questions you can post them here and
   >we will try to answer them :-)
   >
   >Ted
   >
   >
   >
   >
   >
   >
   >
   >-------------------------------------------------------
   >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
   >for problems?  Stop!  Download the new AJAX search engine that makes
   >searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
   >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
   >_______________________________________________
   >Embedlets-developer mailing list
   >Emb...@li...
   >https://lists.sourceforge.net/lists/listinfo/embedlets-developer

RE: [Embedlets-dev] Interesting problem surely not unsolvable

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

> The graphical wiring layer was never developed however for a number of
reasons.

That's not entirely true. Visij is pretty much an implementation of the
embedlets container except it has been designed with *really* small
footprint devices in mind and oh.. it's windows based but with java =
back-end

http://www.muvium.com/developer/edu/Masters/VGP-938.zip

We are very close to rolling out commercial products based on this and =
then
will be looking at scaling it into a variety of java runtime platforms.

-- James

=20

Re: [Embedlets-dev] Interesting problem surely not unsolvable

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

John wrote:

> I appreciate this cultural difference between Computer science and
> traditional embeded systems people.
> 
> It is very positive that this project has identified the problem.
> 
> I fear that it appears to be failing because in trying to solve the issue
> it may have been adding another layer of complexity.

I was the person who added the materials about the CS vs. traditional embedded
systems developers :-) My thought was that yet another layer would be added on
top of the Embedlets layer which would allow the Embedlet components to be
graphically wired together using a swing-based tool.  The graphical wiring
layer was never developed however for a number of reasons.




> I would very much like to know what work had been done before things
> slowed down to see if there is anything which can be used from this.
> 
> Is everything done detailed in the mailing list or is there any unfinished
> work, Lurking?

What happened was that development pretty much stopped as soon as the code base
was proven to work.  There were 4 or 5 of us working on this project and I
think each one of us stopped development for a different reason.

My main reason for working on Embedlets was that I was interested in using it
to help solve the CS/traditional embedded developer problem listed above.

My main reason for stopping after Embedlets was proven to work is that I
decided that running an easier to learn language than Java, like BASIC or
Jython, on top of Java was a better way to solve the problem I was ( and am )
working on.

Anyway, the Embedlet code base is in the CVS and it does work.  As far as I
know, the email list archive contains all of the discussions which are relevant
to the codebase.  Beyond this, if you have questions you can post them here and
we will try to answer them :-)

Ted

[Embedlets-dev] Interesting problem surely not unsolvable

[<jo...@ad...>]

Hi

I appreciate this cultural difference between Computer science and
traditional embeded systems people.

It is very positive that this project has identified the problem.

I fear that it appears to be failing because in trying to solve the issue
it may have been adding another layer of complexity.

I would very much like to know what work had been done before things
slowed down to see if there is anything which can be used from this.

Is everything done detailed in the mailing list or is there any unfinished
work, Lurking?

John

RE: [Embedlets-dev] Re: Embedlets-developer digest, Vol 1 #237 - 3 msgs

[Kelly S. <be...@ea...>]

Dear Bruce - "Re: "JWire"

Now thats totally UNFAIR!  You already have one (a 1WDR board, and as far as
a "contest entry name", which brings to mind:

'Oneder' or 'Wonder' (as in "I wonder how they (DalSemi), ever got the
DS2450 to work?!?").

...Oooooo, thats AWEFUL, Kelly!

>I offer "1Wire++", as my official entry. I always like the KISS approach,
>and its kind of "catchy" to play off the C++ thing.

JWire?

[Embedlets-dev] Re: Is/Are Embedlets alive?

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

Christopher wrote:

> I just spent some time evaluating the jddac code release. Here are my
> conclusions:
> [...]
> The big advantage of JDDAC is the backing by Sun and Agilent and the
> conformity to the IEEE 1588 standard. My recommendation would be to make the
> Embedlets project a part of the JDDAC 'incubator' and rework Outpost as a
> J2ME appropriate implementation.

Another option for developers on this list would be to leave Embedlets dormant
for the time being and get involved directly with the JDDAC project.  As Chris
indicated, JDDAC is being backed by both Sun and Agilent and through Agilent
(which is helping to drive the IEEE 1451 standard) an increasing number of
important companies are being brought on board.

A large amount of the thinking that has been discussed in the Embedlets group
over the past couple of years lines up very well with JDDACs objectives but the
benefits to working directly with JDDAC over Embedlets include increased
visibility at the center of the Embedded Java universe (which has a greater
chance of leading to paying work).

Perhaps sometime in the future there will be an opportunity to bring Embedlets
under the JDDAC umbrella but for now, JDDAC is new but well-backed, momentum in
the project is growing and the opportunity is open for Embedded Java developers
to get involved.


Ted


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

[Embedlets-dev] Re: Embedlets-developer digest, Vol 1 #237 - 3 msgs

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

>From: "Kelly Smith" <be...@ea...>
>To: <emb...@li...>
>Subject: RE: [Embedlets-dev] 1WDR?
>Date: Sun, 8 Aug 2004 01:17:32 -0700
>Reply-To: emb...@li...
>
>Dear Bruce -
>
>(1) Re: "I thought there was a post about USB-serial adapters (and one that
>worked
>better than others) on the Dallas discuss list but a search didn't find it."
>
>I think you are looking for the Keyspan USB to Serial Adapter.
>
>Ref: http://lists.dalsemi.com/maillists/tini/2003-May/043731.html

Aha, that's the one. I was looking in the new discuss group and couldn't 
find this. Thanks.


>(2) Re: "We can't think of a better name than 1Wire Done Right but we're
>open to ideas."

Good points both. Hmm. Right now the PCB is labelled 1WDR and we don't have 
to tell anyone what it means I guess...

>I offer "1Wire++", as my official entry. I always like the KISS approach,
>and its kind of "catchy" to play off the C++ thing.

JWire?

>(3) Re: "rxtx-and-Dallas-1Wire1.00-Java-API to accomodate a USB adapter?"
>
>Brian Lane posted a proposed solution for Linux to relax the timeout (since
>the translate time through the USB-to-Serial is so slow), here:
>
>Ref: http://lists.dalsemi.com/maillists/tini/2003-May/043897.html

I'll check that out.

Regards

Bryuce

RE: [Embedlets-dev] 1WDR?

[Kelly S. <be...@ea...>]

Dear Bruce - Its 3:26 PM Sunday here in California, so for a quick reference
(for the edification of others), then jump over this to "(1)" - Kelly

Kelly wrote (on 08/07/2004
I will dig in to rxtx and see what I can find, but I'll bet that Scott
Hughes could tell you in a heartbeat.

I did a quick google on 'rxtx source', so I guess I will start here:

http://users.frii.com/jarvi/rxtx/download.html

I might not be able to get started until late Sunday afternoon. For Windoze
only, right?

(1) From the URL above, and from this text:

RXTX full comm implementation (developmental) for jdk-1.[1-4]*. The source
is available by cvs. cvs checkout -r commapi-0-0-1 rxtx-devel

Date:         Dec 5, 2001
Formats:      rxtx-1.5-8.tar.gz (~300 k)

...it appears (SWAG) that the "significant file" for timing tweaks, is
'termios.c', from the un-zip of rxtx-1.5-8.tar.gz

Also, take a look at win32termios.h

  Both of these files are <well documented (lots of "magic numbers" in
'win32termios.h' (mostly "undocumented"... no comments), but if you stare at
them they start to make some sense (like baud rates).

So, the un-zip creates a folder rxtx-1.5-8. And from there, go to
\src\termios.c

...and open with your editor-weapon-of-choice (TextPad does it for me).

(2) Here is a snippet of the code section in 'termios.c', that I think (I
could be FOS), needs the tweaks (alright, HACKS!):

#ifdef DEBUG_VERBOSE
	sprintf( message, "VTIME:%d, VMIN:%d\n", s_termios->c_cc[VTIME],
		s_termios->c_cc[VMIN] );
	report( message );
#endif /* DEBUG_VERBOSE */
	vtime = s_termios->c_cc[VTIME] * 100;
	timeouts.ReadTotalTimeoutConstant = vtime;
	timeouts.ReadIntervalTimeout = vtime;
	timeouts.ReadTotalTimeoutMultiplier = 0;
	timeouts.WriteTotalTimeoutConstant = vtime;
	timeouts.ReadTotalTimeoutMultiplier = 0;
	/* max between bytes */
	if ( s_termios->c_cc[VMIN] > 0 && vtime > 0 )
	{
		/* read blocks forever on VMIN chars */
	} else if ( s_termios->c_cc[VMIN] == 0 && vtime == 0 )
	{
		/* read returns immediately */
		timeouts.ReadIntervalTimeout = MAXDWORD;
		timeouts.ReadTotalTimeoutConstant = 0;
		timeouts.ReadTotalTimeoutMultiplier = 0;
	}
#ifdef DEBUG_VERBOSE
	sprintf( message, "ReadIntervalTimeout=%ld\n",
		timeouts.ReadIntervalTimeout );
	report( message );
	sprintf( message, "c_cc[VTIME] = %d, c_cc[VMIN] = %d\n",
		s_termios->c_cc[VTIME], s_termios->c_cc[VMIN] );
	report( message );
	sprintf( message, "ReadTotalTimeoutConstant: %ld\n",
			timeouts.ReadTotalTimeoutConstant );
	report( message );
	sprintf( message, "ReadIntervalTimeout : %ld\n",
		timeouts.ReadIntervalTimeout );
	report( message );
	sprintf( message, "ReadTotalTimeoutMultiplier: %ld\n",
		timeouts.ReadTotalTimeoutMultiplier );
	report( message );
#endif /* DEBUG_VERBOSE */
	if ( !SetCommTimeouts( index->hComm, &timeouts ) )
	{
		YACK();
		report( "SetCommTimeouts\n" );
		return -1;
	}
	memcpy( index->ttyset, s_termios, sizeof( struct termios ) );
	LEAVE( "tcsetattr" );
	return 0;
}

I think you may want to turn on the DEBUG_VERBOSE compile switch 'till you
get your bearings.  I hope that I have NOT lead you astray with this (waste
your time).

(3) Also look at:

BOOL init_serial_struct( struct serial_struct *sstruct )

Snip...snip...

	This needs to use inb() to read the actual baud_base
	and divisor from the UART registers.  Question is how
	far do we take this?

	*/

	sstruct->custom_divisor = 0;
	sstruct->baud_base = 115200;

End-snip...

(4) In \srcRXTXCommDriver.java

'CandidateDeviceNames', is probably very important to you.  I don't know
what COMx, that you intend this for...

Ref:

	private final String[] getValidPortPrefixes(String CandidatePortPrefixes[])


Best regards, my friend! Also, Check with Scott, at DalSemi     - Kelly
Smith

RE: [Embedlets-dev] 1WDR?

[Kelly S. <be...@ea...>]

Dear Bruce -

(1) Re: "I thought there was a post about USB-serial adapters (and one that
worked
better than others) on the Dallas discuss list but a search didn't find it."

I think you are looking for the Keyspan USB to Serial Adapter.

Ref: http://lists.dalsemi.com/maillists/tini/2003-May/043731.html

(2) Re: "We can't think of a better name than 1Wire Done Right but we're
open to ideas."

You are an "Authorized Distributor" for DallasSemiconductor\MAXIM 1-Wire
products, but there are two things that come to mind. (2-1) is that
1-Wire(R) would cause a doubly registered trademark, if you (in effect) pen
the name "1-Wire(R) Done Right(R)", which they DalSemi might not allow (I am
not a lawyer, nor do I know your arrangement with them), and (2-2) is that
the name you chose (If I put my DalSemi Marketing Hat on), casts a
dispersion on 1-Wire as "Is Systronix implying that we did 1-Wire WRONG?".
But after what the "Easter Bunny" told us regarding the DS2450 ADC debacle
that you had this previous week (short PCB run), maybe they did!

You could change it the Juan Wire Done Right (which Aitor Arrieta at AAG
would like), and stay out of any possible lawsuit.  Let me suggest that you
start a naming contest, and offer a free production 1WDR, to whomever you
choose who comes up with the best name.

I offer "1Wire++", as my official entry. I always like the KISS approach,
and its kind of "catchy" to play off the C++ thing.

(3) Re: "rxtx-and-Dallas-1Wire1.00-Java-API to accomodate a USB adapter?"

Brian Lane posted a proposed solution for Linux to relax the timeout (since
the translate time through the USB-to-Serial is so slow), here:

Ref: http://lists.dalsemi.com/maillists/tini/2003-May/043897.html

...and you have the info, to do the SW "tweaks" on UParameterSettings.java
for the DS2480.

I will dig in to rxtx and see what I can find, but I'll bet that Scott
Hughes could tell you in a heartbeat.

I did a quick google on 'rxtx source', so I guess I will start here:

http://users.frii.com/jarvi/rxtx/download.html

I might not be able to get started until late Sunday afternoon. For Windoze
only, right?

Best regards and nighty-night (going on 1 AM here in California), Kelly


-----Original Message-----
From: emb...@li...
[mailto:emb...@li...]On Behalf Of
Bruce Boyes
Sent: Saturday, August 07, 2004 10:38 PM
To: emb...@li...
Subject: [Embedlets-dev] 1WDR?


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

At 08:07 PM 8/7/2004 -0700,
emb...@li... wrote:

>Message: 2
>From: "Kelly Smith" <be...@ea...>
>To: <emb...@li...>
>Subject: RE: [Embedlets-dev] 1WDR working with OneWireViewer
>Date: Sat, 7 Aug 2004 08:14:44 -0700
>Reply-To: emb...@li...
>
>Dear Bruce - What is Systronix' "1Wire Done Right"?  Somewhere along the
>way, I must have lost track.  Best regards, Kelly Smith

This is a prototype, not released or mentioned on our website. This
technology is why we halted JSimm.1Wire since we didn't like the
performance of the DS2480B. We'll use the 1WDR technology on a new
JSimm.1Wire eventually. The first 1WDR is a 100x50 mm board (fits our
SnapTrack) with a serial interface so it works with PC, MAC, Linux etc.

I'm using it on the PC with Windoze and a serial port, with rxtx drivers.
Just started testing.

BTW I just tried it with a Belkin USB serial adapter but apparently the
latency gives the Java API fits. Does anyone know how to relax the timeout
for the rxtx-and-Dallas-1Wire1.00-Java-API to accomodate a USB adapter? I
thought there was a post about USB-serial adapters (and one that worked
better than others) on the Dallas discuss list but a search didn't find it.

We can't think of a better name than 1Wire Done Right but we're open to
ideas.

Regards

Bruce




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Embedlets-developer mailing list
Emb...@li...
https://lists.sourceforge.net/lists/listinfo/embedlets-developer

[Embedlets-dev] 1WDR?

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

At 08:07 PM 8/7/2004 -0700, 
emb...@li... wrote:

>Message: 2
>From: "Kelly Smith" <be...@ea...>
>To: <emb...@li...>
>Subject: RE: [Embedlets-dev] 1WDR working with OneWireViewer
>Date: Sat, 7 Aug 2004 08:14:44 -0700
>Reply-To: emb...@li...
>
>Dear Bruce - What is Systronix' "1Wire Done Right"?  Somewhere along the
>way, I must have lost track.  Best regards, Kelly Smith

This is a prototype, not released or mentioned on our website. This 
technology is why we halted JSimm.1Wire since we didn't like the 
performance of the DS2480B. We'll use the 1WDR technology on a new 
JSimm.1Wire eventually. The first 1WDR is a 100x50 mm board (fits our 
SnapTrack) with a serial interface so it works with PC, MAC, Linux etc.

I'm using it on the PC with Windoze and a serial port, with rxtx drivers. 
Just started testing.

BTW I just tried it with a Belkin USB serial adapter but apparently the 
latency gives the Java API fits. Does anyone know how to relax the timeout 
for the rxtx-and-Dallas-1Wire1.00-Java-API to accomodate a USB adapter? I 
thought there was a post about USB-serial adapters (and one that worked 
better than others) on the Dallas discuss list but a search didn't find it.

We can't think of a better name than 1Wire Done Right but we're open to ideas.

Regards

Bruce

RE: [Embedlets-dev] 1WDR working with OneWireViewer

[Kelly S. <be...@ea...>]

Dear Bruce - What is Systronix' "1Wire Done Right"?  Somewhere along the
way, I must have lost track.  Best regards, Kelly Smith

-----Original Message-----
From: emb...@li...
[mailto:emb...@li...]On Behalf Of
Bruce Boyes
Sent: Friday, August 06, 2004 10:33 PM
To: emb...@li...
Subject: [Embedlets-dev] 1WDR working with OneWireViewer


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

Our 1Wire Done Right prototype is working with the OneWireViewer demo in
the 1Wire API and with the RXTX serial interface. So this means that the
1WDR board indeed appears to the Java API to be a DS2480B. RXTX should work
fine on Linux and other systems.

We need to add some tagging memory to this board and make a couple of other
tweaks and then test it a lot more with some varied networks. But so far so
good.

This might be good first test case hardware for further Embedlet work.

Regards

Bruce




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Embedlets-developer mailing list
Emb...@li...
https://lists.sourceforge.net/lists/listinfo/embedlets-developer

[Embedlets-dev] 1WDR working with OneWireViewer

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

Our 1Wire Done Right prototype is working with the OneWireViewer demo in 
the 1Wire API and with the RXTX serial interface. So this means that the 
1WDR board indeed appears to the Java API to be a DS2480B. RXTX should work 
fine on Linux and other systems.

We need to add some tagging memory to this board and make a couple of other 
tweaks and then test it a lot more with some varied networks. But so far so 
good.

This might be good first test case hardware for further Embedlet work.

Regards

Bruce

RE: [Embedlets-dev] Re: Is/Are Embedlets alive?

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

I just spent some time evaluating the jddac code release. Here are my
conclusions:

1. Jddac addresses many of the issues the embedlets project addresses
including:
	Component/Containment
	Configuration
	Lifecycle
	Communication
	Threading

2. JDDAC adds several important aspects
	Data Model
		- ArgArray
	Network communication (publish/subscribe over http)
	Java Tranducer Interface (JTI)
	Server Platform - J2EE based colection and presentation service
3. Embedlets has the following advantages:
	System logging
	Working implementation for Ajile and Dallas processors
	Hierarchical Persistence model (embedlets/persistence)

Missing in the current JDDAC release is client/server model that is
appropriate for inter-component communication in an embedded application.
(Embedlets has a pub/sub model as well although we had discussed a
client/server model).

The big advantage of JDDAC is the backing by Sun and Agilent and the
conformity to the IEEE 1588 standard. My recommendation would be to make the
Embedlets project a part of the JDDAC 'incubator' and rework Outpost as a
J2ME appropriate implementation.


Some notes on the current JDDAC release:


The xml configuration files are 'flat' and are difficult to navigate with a
tree-based editor because everything is an 'arg'.  This is not a major
drawback but I prefer a more structured object diagram such as I submitted
in the embedlets/persistence model.

The sample application does not run without some debugging of the ant builds
and the getting started documentation produces none-compilable code. After
debugging I did manage to get things running.

Chris



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...]On Behalf Of Ted
Kosan
Sent: Thursday, August 05, 2004 11:20 PM
To: emb...@li...
Subject: [Embedlets-dev] Re: Is/Are Embedlets alive?


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

Bruce wrote:

> I'm slow on the uptake, apparently. I only recently wondered why I hadn't
> heard anything interesting from the Embedlet group, went to SourceForge
and
> there have been no new postings since April.

I wouldn't say dead but the project definitely went dormant after we hit a
brick wall trying to decide how to solve the plug-and-play peripheral
problem.
Also, we have not heard from the main architect in a while (Andrzej, are you
still out there? :-)


At that time a lot of posts were submitted which were dedicated to the idea
of
plug and play sensors and actuators and this was tied in with Brill's Cork
library.  The place where we hit a wall with this was on trying to decide
what
the protocols and standards should be for tagging the sensors and
communicating
with them.

After letting this sit for a while what eventually happened (which I do not
think most of the people on the list are aware of yet) is that Sun started
their JDDAC community (http://jddac.dev.java.net) about 5 months ago based
around the new IEEE 1451 Plug-and-play transducer standard and this standard
pretty much solves all of the problems we were discussing.



> We're revising the TILT400 schematics and putting the Embedlet project URL
> on them, at the Embedlet connector, but this may be moot if the group has
> gone dormant.
>
> TStik and TILT400 are starting to catch on - there has been a nice
increase
> in orders in the last 90 days or so. TILT400 has the Embedlet connector -
> added in specifically to support the efforts of this group.

At this point I do not think it is safe to put the Embedlet name at the
connector and as to whether or not you leave the connector itself on the
board
is a judgment call.

Ultimately I was the person who pushed for a buffered I2C connector because
I
think that it provides an enormous amount of flexibility.  In my mind it
could
provide the plug and play capability that 1-Wire does at significantly
increased speeds (especially when used with muvium devices).

What comes to mind now is that the connector would be useful for plugging
1451
devices into because that was the kind of capability we were shooting for
originally.



> So I'm just wondering what the status of the group and project is.

This is a good question.  The Embedlets code base works and now that the
JDDAC
project has some Java code that implements various parts of the new 1451
standard, perhaps it is a good time to move development forward again?


Ted



__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Embedlets-developer mailing list
Emb...@li...
https://lists.sourceforge.net/lists/listinfo/embedlets-developer

RE: [Embedlets-dev] Is/Are Embedlets alive?

[Kelly S. <be...@ea...>]

IM<HO - Embedlets might be fizzle, but JackNet will sizzle; as long as it's
using an X10 module connected to a toaster, or a heater... or for that
matter ANYTHING ELECTRICAL.

X10 is the most unreliable piece of crap electronics foisted upon commercial
electronics user's since the ignition system on on the Ford Pinto (my little
joke).  E.g., I would not use X10 on a toaster... you could and probably,
would set your house on fire).

Best regards, Kelly Smith

-----Original Message-----
From: emb...@li...
[mailto:emb...@li...]On Behalf Of
Bruce Boyes
Sent: Friday, August 06, 2004 11:08 AM
To: Brill Pappin
Cc: emb...@li...
Subject: Re: [Embedlets-dev] Is/Are Embedlets alive?


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

At 11:48 AM 8/6/2004 -0400, Brill Pappin wrote:
>FYI - Ted, I am unable to post to the embedlets mailing list at all, my If
>is dynamic which sourceforge blocks (even though I have a secure server).
>If we get involved in the project again could we host the list at a
>different location?
>This is the second sending of this mail because the last one bounced.
>
>-------------
>
>Hi Bruce, I haven't heard a lot lately, and I haven't had much time to
>keep up momentum myself (new work, new baby, new house, etc.)
>
>There is the hardware as well (that 1-wire id system from Rogue I spoke to
>you about a while ago) that never finished development for various reasons.
>
>Anyway, the idea is still a good one and I think the JDDAC project doesn't
>quite fit the nitch Embedlets where working toward... our main problem
>(IMO) was that we didn't have the development capital for the hardware
>side of things.
>
>That said, there may be some interest in picking it up again in line with
>what you folks at Systronix are doing... is there a good source of
>documentation on how you are expecting your systems to work?

All I'm thinking is that we could make a simple I/O board which plugs into
the Embedlet connector and uses I2C for some analog inputs and digital I/O,
without taking up a JSimm slot. We'd use this board to help test TILT400
and TStik.

It appears that Embedlets might be fizzling so my question may be moot.
We'll still do the board since we need one ourselves.

Bruce




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Embedlets-developer mailing list
Emb...@li...
https://lists.sourceforge.net/lists/listinfo/embedlets-developer

Re: [Embedlets-dev] Is/Are Embedlets alive?

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

At 11:48 AM 8/6/2004 -0400, Brill Pappin wrote:
>FYI - Ted, I am unable to post to the embedlets mailing list at all, my If 
>is dynamic which sourceforge blocks (even though I have a secure server). 
>If we get involved in the project again could we host the list at a 
>different location?
>This is the second sending of this mail because the last one bounced.
>
>-------------
>
>Hi Bruce, I haven't heard a lot lately, and I haven't had much time to 
>keep up momentum myself (new work, new baby, new house, etc.)
>
>There is the hardware as well (that 1-wire id system from Rogue I spoke to 
>you about a while ago) that never finished development for various reasons.
>
>Anyway, the idea is still a good one and I think the JDDAC project doesn't 
>quite fit the nitch Embedlets where working toward... our main problem 
>(IMO) was that we didn't have the development capital for the hardware 
>side of things.
>
>That said, there may be some interest in picking it up again in line with 
>what you folks at Systronix are doing... is there a good source of 
>documentation on how you are expecting your systems to work?

All I'm thinking is that we could make a simple I/O board which plugs into 
the Embedlet connector and uses I2C for some analog inputs and digital I/O, 
without taking up a JSimm slot. We'd use this board to help test TILT400 
and TStik.

It appears that Embedlets might be fizzling so my question may be moot. 
We'll still do the board since we need one ourselves.

Bruce

[Embedlets-dev] Re: Is/Are Embedlets alive?

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

Bruce wrote:

> I'm slow on the uptake, apparently. I only recently wondered why I hadn't 
> heard anything interesting from the Embedlet group, went to SourceForge and 
> there have been no new postings since April.

I wouldn't say dead but the project definitely went dormant after we hit a
brick wall trying to decide how to solve the plug-and-play peripheral problem.
Also, we have not heard from the main architect in a while (Andrzej, are you
still out there? :-)


At that time a lot of posts were submitted which were dedicated to the idea of
plug and play sensors and actuators and this was tied in with Brill's Cork
library.  The place where we hit a wall with this was on trying to decide what
the protocols and standards should be for tagging the sensors and communicating
with them.

After letting this sit for a while what eventually happened (which I do not
think most of the people on the list are aware of yet) is that Sun started
their JDDAC community (http://jddac.dev.java.net) about 5 months ago based
around the new IEEE 1451 Plug-and-play transducer standard and this standard
pretty much solves all of the problems we were discussing.



> We're revising the TILT400 schematics and putting the Embedlet project URL 
> on them, at the Embedlet connector, but this may be moot if the group has 
> gone dormant.
>  
> TStik and TILT400 are starting to catch on - there has been a nice increase 
> in orders in the last 90 days or so. TILT400 has the Embedlet connector - 
> added in specifically to support the efforts of this group.

At this point I do not think it is safe to put the Embedlet name at the
connector and as to whether or not you leave the connector itself on the board
is a judgment call.

Ultimately I was the person who pushed for a buffered I2C connector because I
think that it provides an enormous amount of flexibility.  In my mind it could
provide the plug and play capability that 1-Wire does at significantly
increased speeds (especially when used with muvium devices).

What comes to mind now is that the connector would be useful for plugging 1451
devices into because that was the kind of capability we were shooting for
originally.



> So I'm just wondering what the status of the group and project is.

This is a good question.  The Embedlets code base works and now that the JDDAC
project has some Java code that implements various parts of the new 1451
standard, perhaps it is a good time to move development forward again?


Ted


		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

[Embedlets-dev] Is/Are Embedlets alive?

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

I'm slow on the uptake, apparently. I only recently wondered why I hadn't 
heard anything interesting from the Embedlet group, went to SourceForge and 
there have been no new postings since April.

We're revising the TILT400 schematics and putting the Embedlet project URL 
on them, at the Embedlet connector, but this may be moot if the group has 
gone dormant.

TStik and TILT400 are starting to catch on - there has been a nice increase 
in orders in the last 90 days or so. TILT400 has the Embedlet connector - 
added in specifically to support the efforts of this group.

So I'm just wondering what the status of the group and project is.

We're planning to build a JSimm board with some I2C devices on it to be 
used in manufacturing test of TILT400 and TStik, to replace the current 
fixture design which uses the 1Wire DS2450 (that's another story).

So I was going to ask this group if there were "favorite" I2C ADC devices. 
We've been looking at those from TI/Burr Brown.

Regards

Bruce

[Embedlets-dev] Announcing JDOS (Java Device Open System)

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

I apologize for not informing the group of the following news earlier but there
were some issues that needed to be worked through with Sun and Systronix first.

From day one of the formation of the Embedlets group my personal vision for the
most likely initial lucrative market for Embedded Java was for feeding process
data into J2EE systems.  

Recently it has become increasingly clear to me that nothing short of having a
full-blown J2SE-based Embedded System was going to be adequate to meet this
market opportunity.

Therefore, for the past couple of months I have been researching what it would
take to create an Embedded Java platform that was based upon the new full-blown
J2SE 1.5 release and I am convinced that I have found a viable solution.

You can read more details about what I have called JDOS (Java Device Open
System) at the newly-created JDOS project site:

https://jdos.dev.java.net


Sun's JDDAC project (https://jddac.dev.java.net) is sponsoring the JDOS project
and Systronix has decided to become a value-added reseller of Nano and Mini ITX
systems.

JDOS Embedded Java systems will have more than enough power to run software
like Embedlets, JBASIC, JXTA and JINI along with being able to easily access
almost any kind of modern I/O hardware (like USB, IEEE1394, PCI, PCMCIA) and
communicate with cutting-edge devices (like RFID and Smartcard readers).


If anyone on this list is interesting in participating in the development of
what may be the first open Embedded Java platform, I encourage you to become a
member of the JDOS project.

Thanks,

Ted


__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

Re: [Embedlets-dev] What wld be the relation between Outpost & Savant ?

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

Ramesh wrote:

> Just wondering.. what would be the relationship between Outpost
> container and Savant? Would Outpost be a possible implementation layer
> for Savant? Or, would outpost feed into Savant- as an intermediary
> between the devices and Savant?

An 'Enterprise Outpost' was conceived to be an open 'black-box'
Internet-connected computer platform that is specifically designed to be easily
interface to a company's physical processes and also easily integrated with its
backend enterprise systems.  The idea is to allow backend Enterprise systems to
monitor and control all aspects of a company's physical processes through the
use of standardized 'black boxes' that embody standardized embedded software
and hardware components.

As part of this process, this group developed what we call Embedlets (embedded
system software components, think servlets for embedded systems) and an
Embedlet Container to run them in in order to help achieve this goal.

Another goal that we have is to enable Outposts to be easily managed and
re-configured in the field so that their numbers can be scaled up into the
thousands.

Given this definition of an Enterprise Outpost, I see an RFID Savant server as
being a software system that simply runs on an Outpost.  The Outpost black-box
computer would be directly interfaced to an RFID reader and it would then host
the Savant software.  In addition to this, the Outpost would provide the
capability to interface to other physical things around the Outpost along with
providing the ability for the whole system to be managed remotely.

This group now has the ability to make at least an alpha-level version of these
Enterprise Outposts but now we are at a point where we need to partner with a
community of J2EE developers to help evolve the technology. 



> While Outpost is an implementation platform for any apps involving
> devices, may accelerate adoption if we can have a clear articulation
> for RFID based solutions?

I agree with this completely.  Our group of Embedded Java developers has been
in need of an embedded systems related problem that the J2EE community needed
help solving and it appears that RFID meets this requirement very well.

At this point, it appears that no one knows exactly what the main RFID-oriented
problems and best-practice solutions are going to be and this is why I think
that an open, experimental RFID project (like the proposed one involving TSS
members) would be useful in starting to figure things like this out.

We can handle the hardware and embedded software aspects of an open project
like this if we could get a group of J2EE developers to handle its Enterprise
Software aspects.


Ted

__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

[Embedlets-dev] What wld be the relation between Outpost & Savant ?

[<ra...@pr...>]

Just wondering.. what would be the relationship between Outpost
container and Savant? Would Outpost be a possible implementation layer
for Savant? Or, would outpost feed into Savant- as an intermediary
between the devices and Savant?

While Outpost is an implementation platform for any apps involving
devices, may accelerate adoption if we can have a clear articulation
for RFID absed solutions?

Cheers,
Ramesh

Re: [Embedlets-dev] Interested in sharing a J2EE perspective

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

>From what Gregg indicated, it appears that Cyte has developed some patterns
>that effectively handle the 'large number of devices' management problem.  It
>would be nice to start collecting these device-oriented patterns so that they
>can be made available to distributed system's architects.
>
>Hey Gregg, now that I am thinking about it, wouldn't a pattern like this be
>considered a secret that Cyte would want to use for competitive advantage?

Well, mostly yes.  We've developed software technologies that let us, as a 
small company, tackle large scale data collection.  There's lots of practical 
engineering involved.  There's also nothing like real world experience to help 
shape your thought processes.

My previous email highlights the points that I think are important to 
understand about what we do from an end to end perspecive.  There are other 
things that I've discussed on the list over the past year as well.

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

Re: [Embedlets-dev] Interested in sharing a J2EE perspective

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

>> We've added 100's 
>> of devices into systems day and night with zero impact to the existing 
>> devices.
>
>Is the 'we' here Cyte employees or customer IT personnel?  Who decides what
>types of devices are deployed and where?

Field technicians and IT staff, depending on the customer and the application.

>> The systems don't have per device configuration, or automatically 
>> recognize and configure the system for the new devices if device specific 
>> configuration is needed.  
>
>Can you give an idea again of what types of devices are typically connected to
>these systems?  What are some of the things they are doing?  Are they only
>monitoring or are some of them also doing control?

Metering equipment as well as control equipment.

>It sure would be interesting to visit one of your installations!  The Cyte
>website shows that Cyte has a Midwest regional contact.  Does Cyte have any
>installations like you described above anywhere near Ohio?

Not Yet.  We have pipeline based equipment throughout the lower midwest and 
going west into wyoming.  The equipment is not that special Ted.  It's mostly 
the arcom control systems director.  It is monitoring and controlling 
equipment via modbus and/or digital and analog I/O.  The director would be an 
outpost class device.  It does all the work of a realtime environment.  We 
just send it things to do (mostly via modbus) for certain controls.  It also 
has scheduled reporting and exception based reporting that it is performing 
unattended.

We use a proprietary binary protocol from the directors in many cases.  In 
others, we shoot back XML.  It just depends on what is the easiest.

These programmable controllers are available everywhere.  What is not being 
done is the publish/subscribe model.  Instead, everyone is polling these 
devices with modbus or similar protocols.  Polling doesn't scale well to large 
numbers of devices, comming from a single source.

So, we do the polling at the Director devices, and then have them publish the 
data back into the enterprise.  There is a whole series of error management 
strategies that come into play when you have networking between the enterprise 
and its vital data.  For each type of application/data, we've engineered 
solutions that make sure the data can be retrieved within reasonable 
contraints of communications failures.  There are things like 30days of 
history that needs to be archived at the remote sites so that someone can 
drive out there and collect manually if needed.  Some of the end devices do 
this themselves already.  Some need the director to buffer data.  So, it needs 
certain size flash for certain apps.

It's really an end to end engineering job.  But, once you have the pieces 
engineered, then anyone can drop them into the network and plug them together.

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

Re: [Embedlets-dev] Interested in sharing a J2EE perspective

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

Ramesh wrote:

> As Greg pointed out in his post, believe handling of individual
> outposts is probably not a serious challenge.

From what Gregg indicated, it appears that Cyte has developed some patterns
that effectively handle the 'large number of devices' management problem.  It
would be nice to start collecting these device-oriented patterns so that they
can be made available to distributed system's architects.

Hey Gregg, now that I am thinking about it, wouldn't a pattern like this be
considered a secret that Cyte would want to use for competitive advantage?



> We could explore this. I can also bring this up with TSS (know Floyd).
> But for this to be effective, the kit must include good simulators- so
> one can explore without actually needing any tags or readers.

Including some simulators sounds like an excellent idea.  I have been looking
at Texas Instruments' RFID evaluations kits and their LF Micro evaluation kit
appears like it might be a good candidate for the kind of group experimenting
we are talking about:

http://www.secureorderprocess.com/ti/products.asp


Here is the main TI RFID website that contains more details:

http://www.ti.com/tiris/default.htm


Anyway, I/we definitely would be interested in pursuing a TSS sponsored RFID
experimental project if they are interested.  It seems like it would be a good
way to obtain some valuable experience in this new area.  If you could see what
the TSS management thinks about this idea that would be great.


Thanks,

Ted

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools

Re: [Embedlets-dev] Interested in sharing a J2EE perspective

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

Gregg wrote:

> We've added 100's 
> of devices into systems day and night with zero impact to the existing 
> devices.

Is the 'we' here Cyte employees or customer IT personnel?  Who decides what
types of devices are deployed and where?



> The systems don't have per device configuration, or automatically 
> recognize and configure the system for the new devices if device specific 
> configuration is needed.  

Can you give an idea again of what types of devices are typically connected to
these systems?  What are some of the things they are doing?  Are they only
monitoring or are some of them also doing control?



> Out status monitoring software automatically creates new standard views for 
> new devices. As soon as a new device is sending traffic in the system, you
> can search for a device by id and get a list of views to look at. [snip]

It sure would be interesting to visit one of your installations!  The Cyte
website shows that Cyte has a Midwest regional contact.  Does Cyte have any
installations like you described above anywhere near Ohio?


Ted

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools

Re: [Embedlets-dev] Interested in sharing a J2EE perspective

[James T. <Jam...@Su...>]

Agreed Ted! Very much so in fact.

Being of the "JXTA frame of mind," we have the opportunity to *securely*
(underscore securely) interconnect all things, big and small, to a much
larger degree then was possible a few short years ago.

Having been on the original "team of two" that helped bring Tomcat to the
free world I have a keen interest/sense in what a J2EE model would look
like in a vastly distributed world ... but it isn't here yet. So, let's
get our heads together and simply deal with the facts.

note: there are some *low* level JXTA api's in the next release that
should make this all the more understandable.

- james

Ted Kosan wrote:
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
> 
> Ramesh wrote:
> 
> 
>>My take on this is that this is more a pitch to push high end
>>hardware. 
> 
> 
> It is my understanding that the concept for the RFID Savant server was
> developed at the original MIT RFID center and this center probably did not have
> a need to push high-end hardware?  My impression from Sun's RFID white paper is
> that they simply took this core Savant concept and innovated on it.
> 
> From my perspective, I view Sun's RFID whitepaper as a huge inflection point
> indicator because, up until I read this paper, it was my opinion that the class
> of embedded system that would be the first to be widely interfaced to J2EE
> backends would be 8-bit Internet-connected systems.  (The Embedlets group has
> developed the term "Enterprise Outpost" to describe the class of
> Internet-connected embedded system that is specifically designed to interface
> with J2EE backend systems.)
> 
> Since RFID appears to be the driver that is finally going to force a
> J2EE/Embedded Systems marriage, whatever class of embedded system is needed to
> run a Savant server is going to be the main class of Internet-connected
> embedded system that is going to experience wide adoption on the shop floor.
> 
> Since Savant servers require J2SE-level technology to run, it follows that the
> class of hardware system needed to host them is standard PC class hardware.
> 
> For those of us in the JINI and JXTA communities, this information is like gold
> because it means that we will be able to start bringing the full capabilities
> of both of these technologies to bear against the formidable problems that
> exist on the shop floor.
> 
> 
> 
> 
>>Even if a truck full of tags were to move past a reader, the
>>challenge today is to accurately scan these tags (I know atleast 2
>>large software players in rfid space that have said this is still a
>>problem. Even just a small crate moving past a scanner on a conveyor
>>belt is a challenge). Given this, the least of the worries (yet) is
>>the lareg number fo hits.
> 
> 
> I personally do not view the ability to process a large number of tags in a
> short time span the primary problem.  I think that competent Java programmers
> will be able to solve this problem with the appropriate amount of linear hard
> work.
> 
> To me the main problem is that the entities which decide where, when and how
> many Enterprise Outposts will be deployed in a company (regardless of whether
> they are RFID readers or other process monitoring and control computers) are
> process improvement committees, not J2EE developers.  For example, Sun uses the
> 6-Sigma process improvement system and it would be Sun's legion 6-Sigma
> committees that would determine this.
> 
> My point here is that I can see how linear hard work can design a J2EE/Embedded
> System solution that will handle almost any information input rate.  What I can
> not see is how a linear solution can solve the problem of thousands of shop
> floor data sources and sinks being dynamically added and removed from a
> company's Intranet by IT personnel completely apart from the involvement of
> J2EE developers.
> 
> What kinds of designs can automatically handle these dynamic load changes?  How
> can thousands of dynamically-connected Enterprise Outposts be managed by
> existing IT personnel?  How can Enterprise Outposts be configured and deployed
> by existing IT personnel without the help of the Java developers who designed
> them?
> 
> These are the bigger-picture problems that keep some of us nights ;-)
> 
> 
> 
> 
>>This is a good idea. But not sure how TSS will fit in. TSS is ore a
>>discussion forum- so a good place to sound ideas out. But it is not a
>>forum where people could try out stuff.
>>
>>If anyone has an actual problem they are working on, and can share the
>>details without going thru the specifics, we can collectively evolve
>>some paradigms. Any takers?
> 
> 
> This is what I had in mind.  Most TSS members would not be able to spec-out a
> RFID reader, the Internet-connected embedded system to control it and the
> software needed to read the tags and send them to a J2EE system.  Members of
> the Embedlets group could do this, however, and this could be made available as
> an open kit that interested TSS members could just purchase.
> 
> This could be done as a TSS experimental project where some of us Embedded Java
> developers could provide support for these RFID experimenter's kits so that
> interested TSS J2EE developers can start playing with them.  The idea would be
> to do this before most people actually had a need for it so that when the need
> does arise, people can capitalize on it.
> 
> 
> Ted
> 
> 
> __________________________________
> Do you Yahoo!?
> Get better spam protection with Yahoo! Mail.
> http://antispam.yahoo.com/tools
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer

-- 
Java == platform independence
XML  == application independence
JXTA == network independence

Secure End-to-End Computing