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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

>To go from C/C++ to Java is not that hard for most programmers,

I don't actually think this is the key Issue. I think it is the real-time
nature of Embedded programming that puts people in a bit of a spin. We only
need to look back at the Nutty Threading problems to understand that
simulataneous processes are confusing. With the combinatorial problem of so
many things going on at once, embedded programmers first instinct is to
reduce the number of possible things that can be wrong, and a buggy High
Level Language is usually the first thing to go stripping back to the
assembly level to see what is wrong.

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

Bingo! - Got it in one Ted :-)

But even better than this is they can use C! and even a C Library! in fact
anything that can generate PIC assembly in function form without a
dependency on some sort of OS can be used because my uvmjni technology scans
for dependencies in a pseudo virtualisation of the PIC code and maps it all
safely into a java wrapper while protecting my JavaOS. Even has a point and
click wizard to make the mappings!

It is the kind of thing with enough 'wow' factor to get PIC people
interested in bringing code accross to the java world especially if they can
plug it straight into something like the Embedlets container.

This creates the opportunity to very quickly inherit vast quantities of
legacy code to populate the JAPL layer of the Embedlets spec and involve an
army of PIC developers to help with this part of the port is a very central
theme to the muvium strategy of enhancing rather than replacing embedded
skill sets.

It might also give us a chance to get a really big win early which is
critical for developing momentum.

James Caska
http://www.muvium.com
'Java Bred for Embedded'

> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of Ted
> Kosan
> Sent: Sunday, February 02, 2003 2:56 PM
> To: emb...@li...
> Subject: [Embedlets-developer] Re: Wiring tool versus Container
> Infrastructure: WE NEED BOTH!
>
>
> >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 naove 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
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
>