[Embedlets-developer] Re: Wiring tool versus Container Infrastructure: WE NEED BOTH!

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

>So let's build such a graphical tool....on top of the 
>best Embedlet Container architecture known to man!
>
>And along those lines....stay tuned for the imminent
>posting of an  "Outpost/Embedlets Architecture 
>Discussion Document" that is intended to 
>foster discussion of an architectural solution that 
>will allow us to do both!

Ok, Andrzej, I am with you.  The concerns I had about graphic Embedlet wiring
capabilities being marginalized have been addressed.



I would, however, like to clarify a few of my earlier points:

>How about all the MIDP/CLDC/CDC etc Java programmers, 
>who could easily  use Embedlets to write embedded 
>code?  There are more of those than in your total 
>of all of the above. [...]
>
>How about Java programmers in general?  There are 
>hundreds of thousands of them (more than C/C++ 
>programmers according to surveys over a year old).
>They could also easily write embedded code given 
>the right infrastructure and tools. [snip]

My position here is that it is not the programming environment that is
constraining the number of normal Java developers that become Embedded Java
programmers, it is their lack of computer interfacing and low-level embedded
programming background.  When Ajile and Sun had their “Dancing Robots” contest
at JavaOne two years ago I (along with Jac) volunteered to spend some time
helping people program the robots.  A real eye-opener for me was that 95%+ of
the Java developers that came up to the booth were scared to death to touch
these JStamp-based systems because the hardware was completely in the open. 
They were capable of programming the robots but the naked hardware really
intimidated most of them.  We had to do a lot of hand holding and re-assuring
that they were not going to blow anything up if they touched the robots and
even then we ended up doing most of the 'touching' for them.

I encounter a very similar situation when teaching Embedded Java using TINI
with the Systronix 8x1 board.  The ones that are already good Java programmers
can program almost anything one wants in Java but as soon as you encourage them
to do something like control a relay or read the frequency of a very low
frequency input signal, they are stopped cold because electronics, computer
interfacing and embedded style programming are completely foreign areas to
them.

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



>Chicken and egg syndrome Ted. Your argument holds only if 
>there is a large selection of pre-built embedlets 
>to choose from.
>
> The enterprise Java programmers were primarily a back 
>door strategy for marketing graphically wired embedded 
>systems to these IT personnel.  
>
>See above. Chicken and egg syndrome Ted!  Who's going 
>to produce all these great embedlet components that 
>the naïve users will be able to wire?

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.

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.

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.



> Here are some low hanging fruit markets that graphic assembly Embedlets
> has access to:
> 
> - PIC programmers (huge group of non-Java developers).
> - 8051 programmers (huge group non-Java developers).
> - AVR programmers (huge group of non-Java developers).
> - PLC programmers (huge group of non-Java developers).

>Who could all learn Java extremely quickly, at least 
>enough to write code for a well designed Outpost 
>Container architecture. To go from C/C++ to Java is 
>not that hard for most programmers, especially if 
>you have the plumbing already handled.  And who is 
>going to write the initial embedlets, device drivers 
>and communications adapters for all these platforms?  
>You're not going to wire those at first....

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


Ted

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