James elaborates on small PIC's:
> muvium's minimal footprint is 4K flash 368 byte RAM device (PIC16F87) and
> runs up to 64K Flash + 64K RAM *guestimate for PIC18F8720 device. The
> first device available now being the PIC16F877A at 8K Flash 368byte RAM (
> 4k RAM extended mode real soon)
>
> This is exactly what I am shooting for. To ensure that embedlets can run
> on the muvium minimal platform so that java/Embedlets is a one-stop-shop
> single development plaform for the full range of applications and that
> there is no reason or need on the basic of cost or otherwise to drop out
> to alternative languages/devices to handle the last point in the wide-fan
> application chain.
We can try, but I'm not sure that a container-based implementation, even a
minimal one, will be able to be shoehorned into a 4K flash, 368 byte RAM
device. The event queues could easily grow beyond the RAM in even a trivial
embedlet implementation. 64k/64K should be definitely doable.
Quite a challenge you have set for us, James! I'm willing to try...but no
promises.
James then elaborates on how to resolve the training issues Ted brought up:
<snip some good stuff>
> Sounds like a good 'co-operative' open source project to me!
The key will be to use design/archtiecture best practices such as
encapsulation, layering, modularity, black-boxing and the like, so that each
segment can contribute to the project (be they wrappered PIC asm code with a
JAPL interface, or java-based Embedlets, or Protocol/Transport
Communications Adapters) yet still have all the pieces be able to work
smoothly together.
Yup....not a bad approach! I like it....it would be doable with my current
architectural ideas.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
|
