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

[Andrzej J. T. <an...@ch...>]

Ted clarifies:

> So the constraint is the interfacing hardware and the specialized
> programming techniques involved in controlling it.

Embedlets can handle the second issue.  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?

> At least for my initial pet target market, I envision that the number of
> Embedlets needed at first will be fairly small.  The reason for this is
> that even though enterprises will eventually need sophisticated monitoring
> capabilities, they are currently just getting started with this effort and
> they are not capable of handling anything more sophisticated than reading
> simple physical quantities like temperatures, pressures and switch states.
>  A relatively few well-chosen Embeldets, along with a clean way to submit
> measurements to an enterprise system, will be more than enough to get
> started with.

I think you'll find that once a company/developer gets the few simple ones 
running, they will immediately start thinking of more complex applications 
(even the Lego hobbyists have followed this pattern).  And the underlying 
container platform had better be designed such that they can address that. It 
seems to be the pattern that technology adoption follows. Just the number of 
potential temp/pressure/sensor devices out there makes this a challenge to 
deliver, since out of the box hobbyist sensors are not likely to stand up in the 
harsh world of a production floor.

> 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, fix 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.  I don't think the same market dynamics and customer requirements 
will apply to the manufacturing and distribution industries. But even with that 
said, a non-trivial number of Lego customers have gone on to code their own 
lower level stuff....we need that capability as well and probably on day one, 
since it could easily turn the tide against us if the system has artificial road 
blocks that prevent addressing of custom requirements.

> So, a full-blown Embedlet market is not needed up front to get started in
> most areas and my pet target market was never dependent on such a market.

Let's agree to disagree on this point.  I believe that the advanced capabilities, 
and a rock solid architectural foundation will be critical to longer term success, 
as it was with Servlets/EJBs/J2EE.  Interestingly enough, JavaBeans do not 
have such an design foundation, and have not succeeded.  Hmmmm....

> I think that James and Bruce could add much to the discussion here.  My
> perspective is that it is going to take years for us to see anything even
> approaching a significant number of these low-level programmers migrating to
> Java.  Over at least the next 3 years I think the best we can achieve is to
> allow them to easily attach their legacy and current systems to a network using
> some technique that does not require them to program in Embedded Java.

I don't think the first wave of sophisticated users (be it by evolution from the 
Graphical Tool, or through existing experience with other Component 
technologies) will be the existing C/C++/Asm Embedded programmers.  That 
was much of my point.  There are probably already as many if not more MIDP 
embedded Java programmers than all the C/C++/Asm guys put together, and 
if that isn't the case, it looks like it will be soon.

So I don't envision targeting the "established" embedded development market.  
I think this has the prospect of being a "disruptive" technology and defining a 
new market segment, which eventually could eclipse and replace the older 
way of doing embedded systems.  Disruptive technologies are rarely (if ever) 
adopted by the incumbents, since they have too much vested interest.

> I think that muvium address this need brilliantly for the PIC community. 
> Muvium will enable an assembly-language-only PIC programmer to develop an
> embedded solution in 100% PIC assembly language and then they can graphically
> wrap it in a JAPL object, wire it to an Outpost and from there  wire it to a
> wide number of things from PLCs to backend enterprise systems.

Agreed...there is no reason that you shouldn't be able to take C or Asm code 
and expose it through a JAPL interface.  And if you do that, then Embedlets 
won't care....they will think they are talking to a Java Device Driver since the 
underlying implementation language will be encapsulated and hidden.

But to run on a PIC (with something like uVM) we'll need an Embedlet 
container that is very lean and mean!  That is something that I strongly 
support.  But I do want to see the container run on aJile chips (Systronix 
boards) and on PC's as well (the latter for development/testing purposes if 
nothing else, though I do see a role for PC's in the upper end of the embedded 
space too)

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


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com