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

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

> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
Chess anyone?

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