*** I don't think this made it to the list... If so, forgive the duplicate!
***

 My initial thoughts would be to create a set of classes where  each class
 encapsulated specific functionality of the MPU in question.  The
 interfaces for these classes would be well defined and only the
 implementation would vary.

 Some examples of classes would be (Just a quick thought):

       +-- class Interrupt
       |
       +-- class IOPort
       |    +-- class I2C
       |    |    +-- class EEProm
       |    |    +-- class RealTimeClock
       |    |
       |    +-- class UART
       |    |    +-- class SerialLCD
       |    |
       |    +-- class LCD (4/8 wire)
       |    +-- class IButton
       |
       +-- class Application
       |
       ...

 Some of these classes would be implemented in the VM (Time  critical) and
 others could be implemented as p-code (Non-time critical) included with
 the users program.

 This would obviously mean that there would need to be a VM for each
 type/family of processor.

 Depending on the feedback I get, I would try to make it so that each
 user could customize and build the features needed for any given project
 into the VM.  (Not sure how to accomplish this without having to devote
 all my time to tech support!)

 As for the ram limitations... it is a problem.  The only way around it,
 IMHO is to limit the use of real ram that the program can use, and offer
 EEProm as a place to persist values that do not change/get used very
 often.  I will have to think about this.

 The first attempt at a VM would probably use SEEProm just because I know
 how to use it.  I will just have to wait and see how bad the performance
 is.  (Doesn't the Basic stamp use SEEProm?)

 Any help in the design/implementation of the VM would be welcome!

 David.

> -----Original Message-----
> From: Dan Larson [mailto:dlarson@citilink.com]
> Sent: Thursday, September 24, 1998 7:02 AM
> To: PICLIST@MITVMA.MIT.EDU
> Subject: Re: Java?
>
>
> On Tue, 18 Aug 1998 08:19:40 -0700, Nicholas Irias wrote:
>
> >I like the idea of being able to run a high level language
> from EEPROM, but
> >I'm not sure I understand how java would offer a more
> universal environment
> >than a 'C' or BASIC interpreter.
> >
> >Supposedly, the same java code runs in all VMs, and java is
> supposed to be
> >great for MCUs as well as larger computers.  But it seems to me that
> >virtually everything you want an MCU to do is specific to
> that MCU, so that
> >your java source for the PIC could not be loaded up on a
> Motorala MCU -
> >unless that java source code did not attempt to invoke any
> PIC-specific
> >capabilities.
>
> Perhaps a more universal port twiddling interface could be
> made for Java,
> that would port easily from one mcu to another,, but that
> would only work
> for very common hardware.  Ports, A/D, Timers...  but not
> much else.  If that's
> all you wanted, great.
>
> If you didn't care about portable code and just want to use
> Java for its
> own merits, then a PIC specifc library wouldn't do any harm.
>
> One other concern is the potential high demand that an object oriented
> interpreter would place on RAM.  The typical PIC probably does not
> have enough. I never wrote a Java VM though, so I don't know for sure.
> Serial RAM may be way too slow.
>
> Just $.02 from a softare guy.....
>
> Dan
>