RE: [Embedlets-dev] [Arch] Management of embedlets

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

Chris,

>This is true. A possible application for embedlets is in multi-processor
>distributed computing where an array of JVM's each run a small set of
>identical embedlets to perform matrix operations. This would create a low
>power, low cost, high density super-computer with inherent near-neighbor
>communication.

>Pretty exciting when you think about it!

Ted and I have been discussing the concept of putting a couple of dozen
interconnected PIC core's on a XILINX FPGA and integrating the Xilinx Java
hardware realiser for static hardware functions coupled with muvium running
on the PIC cores for the dynamic java management.

Nice place to put parallel processing embedlets for some seriously kick-ass
parallel processing java performance.

Then all we need to do is interconnect a couple hundred Xilinx on a board..
Hmmm, create a Java Hardware non-linear neural net function and hey presto -
massively parallel hyper-performance java executing Neural Networks..  Now
all I need to do is figure out what I would do with it.

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





> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Christopher Smith
> Sent: Tuesday, February 11, 2003 11:57 AM
> To: emb...@li...
> Subject: RE: [Embedlets-dev] [Arch] Management of embedlets
>
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
>
>
> >
> > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> > _______________________________________________
> >
> >
> > > IMO our embedlet architecture as it is now, is a little too
> much like a
> > > servlet architecture, and I don't think it fits the environment
> > as well as
> > > it should.
> > > I think it would be far better to do things the other way
> > around, so that
> > > the outpost device was sent its configuration, and then sent
> > its data back
> > > out to it's "listeners", similar to a subscriber pattern. This
> > would mean
> > > that the embedded devices could do their work in their own time
> > frame, as
> > > fast as they can reasonably do it, while not getting tied up
> servicing a
> > > single request.
> >
> > In the current architecture the 'real-time' components are JAPL
> > components.
> > In my imagining, JAPL components which are very much like, if
> not exactly
> > like, cork components will likely have Event driven orientation. I think
> > embedlets are subscribers to JAPL components which have event
> > generators for
> > which Embedlets are listeners for sure. In this way all real-time
> > is handled
> > by the container and the real-time features of the platform.
> >
> > Again though, the embedlet implementation may use no JAPL
> > components at all!
> > It may simply be a logic configuration and not be a real-time system.
> >
>
> This is true. A possible application for embedlets is in multi-processor
> distributed computing where an array of JVM's each run a small set of
> identical embedlets to perform matrix operations. This would create a low
> power, low cost, high density super-computer with inherent near-neighbor
> communication.
>
> Pretty exciting when you think about it!
>
> > James Caska
> > http://www.muvium.com
> > 'Java Bred for Embedded'
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: emb...@li...
> > > [mailto:emb...@li...]On Behalf Of
> > > Brill Pappin
> > > Sent: Tuesday, February 11, 2003 5:46 AM
> > > To: emb...@li...
> > > Subject: Re: [Embedlets-dev] [Arch] Management of embedlets
> > >
> > >
> > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> > > _______________________________________________
> > >
> > > > > I'd narrow that down a little I think... for the most part
> > an Embedlet
> > > > > would be talking to/gathering data from a single device, so
> > maybe the
> > > > > embedlet should be a singleton... also helps reduce load on
> > > the embedded
> > > > > environment by not trying to do to much at once.
> > > >
> > > > I don't see any reason why we should limit an Embedlet to
> talk to one
> > > device,
> > > > arbitrarily.  As for singletons...in a threaded system, you
> > > wouldn't even
> > > have
> > >
> > > I disagree with that, singeltons have their place in any
> > > development... most
> > > useful when you wnat to make sure an environment has only one
> > > instance copy
> > > regardless of how the implementation runs. I see it as good
> programming
> > > pratice to protect the areas of code that need it, against
> > poorly written
> > > implementations.
> > > IMO never depend on 3rd parties to do your work for you ;)
> > >
> > > > > For instance, on the physical level in Cork, only one
> device can be
> > > > > talking over I2C at any one time, so the underlying code
> > > allows the bus
> > > to
> > > > > be "locked" for any other requests, it also takes the
> > addresses of the
> > > > > available devices into account because you can't have more
> > > than one with
> > > > > the same address (in certain circumstances you can, but in
> > > that case it
> > > > > would be the same device as far as the software was concerned).
> > > >
> > > > Assuming it's a polled device, the Timer Service would create
> > a periodic
> > > event,
> > > > which an Embedlet would be listening for.  The Container
> > would then call
> > > the
> > > > embedlet's event processing method with the timer event.
> The embedlet
>
> > > > would lock the bus, poll the device, unlock the bus,
> possibly do some
> > > other
> > > > processing (send a device-specific event based on the value
> > it got) and
> > > would
> > > > exit.
> > >
> > > I think you have to be careful here, as not all external
> devices return
> > > immediatly... for instance a 1-Wire net with a heavy wieght and
> > > radius could
> > > take several seconds to properly search, which is an eternatiy in
> > > electronics. I2C is much faster, but till may take several hunbred
> > > milliseconds depending on the device (the Devantech SRF08 will
> > > take from 70
> > > to 100ms to return a single ping).
> > >
> > > > > Anyway, I don't think its really required that the embedlets
> > > behave that
> > > > > way, as the container can do the work of requesting data as
> > needed...
> > > > > however the embedlet should take into account that the
> container can
> > > only
> > > > > do things one at a time (for the most part). Anyway, quick,
> > > low traffic
> > > > > requests are important here.
> > > >
> > > > Not sure what you mean by this.  The Container only manages
> > > Embedlets....it
> > > > would not be it's responsibility to talk to a JAPL/Cork interface.
> > > (Separation of
> > > > Concerns).  The only time a physical device and Container would
> > > interact,
> > > > would be in the case of an interrupt drive device.  When
> the interrupt
> > > came in
> > > > the JAPL code would use a static Container method to get a
> > handle to the
> > > > Event Service, so it could post an Embedlet Event into the queue.
> > >
> > > What I was thinking is that the container could to all the
> > talking in the
> > > background to lower level stuff, and make the data availible to
> > > the embedlet
> > > when it needed it... or the embedlet could request some
> > specific data from
> > > the underlaying code (or the container) and receive a callback
> > > whent he data
> > > was actually delivered.
> > >
> > > > > The other option of course is to dump the data elsewhere
> (into a DB
> > > maybe)
> > > > > and allow the embedlet to redirect requests, or be used only for
> > > outgoing
> > > > > transmission (and not service requests on its own).
> > > >
> > > > Not necessary (and DB's won't typically be available on an embedded
> > > device).
> > > > The event queues effectively provide the capability you need (for
> > > transient
> > > > storage and linkage between a device, Embedlet and
> Container, but in a
> > > > decoupled manner).
> > >
> > > I agree, although I think it important that the device not have
> > to respond
> > > to the embedlet in the embedlets timeframe. so everything must
> > be loosely
> > > coupled so that the underlying system is not tied up  trying to
> > service a
> > > single embedlet request, at the expense of all else it must do
> > for normal
> > > operation.
> > >
> > > IMO our embedlet architecture as it is now, is a little too
> much like a
> > > servlet architecture, and I don't think it fits the environment
> > as well as
> > > it should.
> > > I think it would be far better to do things the other way
> > around, so that
> > > the outpost device was sent its configuration, and then sent
> > its data back
> > > out to it's "listeners", similar to a subscriber pattern. This
> > would mean
> > > that the embedded devices could do their work in their own time
> > frame, as
> > > fast as they can reasonably do it, while not getting tied up
> servicing a
> > > single request. This is somewhat how I thought it was to work, but I'm
> > > getting the idea recently that every request is polled from
> the outpost
> > > device... which will work up to a limited weight, but is a fairly
> > > significant point of failure as the outpost network grows
> (which is the
> > > problem we're attempting to solve here).
> > >
> > > - Brill Pappin
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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
> > >
> > >
> >
> >
> >
> > -------------------------------------------------------
> > 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
>
>
>
>
> -------------------------------------------------------
> 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
>
>