[Embedlets-developer] RE: Hardware interfacing...

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

Andrzej,

>No problem there...this [Wiring Tool] could easily be a separate but parallel
subproject.

This is the way I saw the Wiring Tool being developed too.  Embedlets should
not have any dependencies on a Wiring Tool but they need to be able to support
manipulation by a Wiring Tool.  Since you have (thankfully!) taken the lead on
the Embedlets architecture my plan is to put together enough of an Alpha level
Wiring Tool to be able to provide solid feedback to the architecting process.



>How do you propose we mitigate the hardware interfacing 
>problem?  It's probably beyond this group to define plug 
>'n play cabling and interfacing standards for hardware, 
>though Systronix and such could tackle that and have to 
>some degree.
>
>Are you suggesting that we develop hardware as well as 
>the software infrastruction for Outpost?

You found me out!  Yes, this is exactly what I am proposing and this is what I
and some of the developers on the Cork list have been researching as a side
project.  At this point it looks like all of the 1-Wire devices (accessed
through the 1-Wire Java API) can be used as a base for Plug-and-play I/O
modules by placing tags inside of them that indicate what JAPL interface the
module they are a part of implements.

Each PnP I/O module is designed to implement one or more JAPL interfaces and as
they are plugged into a live Outpost an instance of the JAPL peripheral that is
used to communicate with the module automatically appears in a pallet in the
Wiring Tool.  The graphic representation of this module can then be selected
and dropped into the wiring area where it can be configured using an inspector
and then wired to Embedlets as needed.  Everything is done 'live' so state
changes happening in the JAPL peripheral are reflected in its companion I/O
module and state changes happening in the I/O module are reflected in the JAPL
peripheral.

The cabling and connector standard for 1-Wire modules have already been
developed so this can be leveraged directly.  1-Wire based modules should be
adequate for architecting the PnP software layers that will need to be created
and also for satisfying the initial sensing needs of early Outpost adopters.  

The next logical step up from a 1-Wire network appears to be an I2C based PnP
network and initial steps are already being taken in this direction too.  For
instance, the new TStik socket board has an I2C buffer included on it to
support a usable I2C network length.  Aside from normal I2C devices I think
that this network will work very will with PnP modules based on muvium.

Finally, the Systronix JSimm boards are also scheduled to have 100% PnP
capabilities in the near future and they should integrate nicely with the JAPL
based PnP I/O module software specification we possibly will be developing.

The whole Graphic Wiring Tool idea depends on having I/O modules available that
can be wired to an Outpost in realtime and I have been working very hard to
help make this a reality.

I have not talked too much about this on the list yet because I did not want
people to tell me that it was a bad idea and that it would not work. ;-)



>>Success with a graphical wiring application that has access to only a
>>handful of components is easily seen with the Lego mindstorms environment.
>> This environment contains a small, fixed number of well-chosen components
>>and it has done very well in the marketplace.
>
>I suspect this is not a fair comparison, since this is 
>a toy market. The majority of buyers will stick to the
>constraints of the platform, since they are only playing.

But Andrzej, back in the 70s and early 80s, the PC market was only a 'toy'
market too dominated by Apple IIs, Commodores, TRS-80s, Ataris and Timex
Sinclairs and people were only 'playing' with these machines too.  So what was
so different about the IBM XT that all of a sudden it caused this toy market to
became legitimate?  I am not saying that Legos are going to be used for
industrial applications.  My position is that the graphic assembly of software
components paradigm has been well proven to work for a wide range of
functioning (albeit simple) applications and that this paradigm should be
transferable to industry.  I think that Embedlets have a shot at bringing some
legitimacy to this market.



>JavaBeans do not have such an design foundation, and have not 
>succeeded.  Hmmmm....

Why do you say they have not succeeded?  Most Java applications that use AWT
and Swing use lots of JavaBeans components and every modern Java IDE supports
graphic configuration of JavaBeans using an inspector.  I would agree that a
strong market for JavaBeans components has not developed but Sun states that a
significant reason for this was the lack of a robust long term persistence
mechanism.  The long term persistence API has fixed this problem.  Despite the
presence of the BeanContext container, however, I agree with you that JavaBeans
could have been architected better (especially the event mechanism).  Anyway, I
have not once argued against having a rock-solid design foundation for
Embedlets if for no other reason than my name will be on the specification too!
;-)



>Sounds like we might be in violent agreement on the fundamental 
>points here...

Yes, again, I am with you.  I primarily wanted to work through some of these
issues before the architecting process moved too far along.


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com