Forums

reading program from external EEPROM

Started by Michael Millikan February 21, 2004

Sounds like Niklaus Wirth's P-Code implementation of Pascal. A very
powerful virtual machine running (in my case) on an 8080
microprocessor.

A more up to date example is the OOPIC which uses an 16F877 or
similar PIC and implements a virtual machine using external EEPROM
for the tokenized object code.

See www.oopic.com or the OOPIC group here on Yahoo. --- In , "sergio masci" <smypl@x> wrote:
> Michael Millikan wrote:
>
> > I meant that there may not be enough program memory.
> >
> > As pointed out by a few people, the approach I originally had
(i.e,
> dumping
> > the code from the EERPOM to the flash memory in the PIC) was a
bad idea
> > because the flash would wear out rather quickly.
> > I was thinking about another approach, which particularly takes
advantage
> of
> > the fact that the PIC has only 35 instructions. So I could store
the 35
> > posible instructions in the PIC memory as subroutines and use
the EEPROM
> as
> > a kind of pointer to tell the PIC which subroutines to execute.
Now this
> is
> > all rather complicated because you need to have special codes
for loading
> > data into the instructions and special codes for program jumps,
but I
> > definitely think this can be done.
> > A few potential problems: the PIC would slow way way down,
probably by at
> > least 50 times (this isn't an issue most of the time). It would
require
> > essentially developing a higher level language and an
interpreter.
>
> This sounds like a fun project. Go for it!
>
> The resulting program will run a hell of a lot slower than 1/50
normal
> speed. Your biggest bottle neck is going to be transferring
instructions out
> of the external EEPROM and into the 877 (I don't mean copying them
to the
> internal FLASH - just reading them into RAM). I2C at 400kHz will
give you
> about 14000 bytes / second or about 7000 instructions / second.
Compared to
> a native program running at about 5,000,000 instructions / second
this will
> be a reduction in speed of about 7/5000 or about 1/720.
>
> One way to speed things up would be to use much more powerful
instructions
> than native PIC machine code. Each emulated instruction would then
do more
> work than a standard PIC instruction. Maybe implement a simple 16
or 32 bit
> virtual processor.
>
> You might also consider preloading special functions into the 877
that get
> executed at full speed. Most of your program would be executed in
emulation
> mode and some of the subroutine calls would actually jump out of
emulation
> mode and call real subroutines then return back to emulation mode
when the
> real subroutine returns.
>
> You might also consider some kind of hybrid. Since all 877
instructions are
> 14 bits wide and you will be reading 16 bits per instruction from
the
> external EEPROM, you could use the top bit to indicate whether the
emulated
> instruction is a PIC instruction or a more powerful virtual
processor
> instruction (16 or 32 bit processor as mentioned above).
>
> The thing about storing a tokenised high level language program in
an
> external EEPROM is that you get a very high level of functionality
per byte
> read from the EEPROM. This will greatly improve performance.
>
> I would be interested to know how you get on. Maybe you can
publish your
> progress on a web page. Tell me where it is and I will call by
from time to
> time to see how you are getting on.
>
> Regards
> Sergio Masci
>
> http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC
compiler



--- In , "rtstofer" <rstofer@p...> wrote:
>
> Sounds like Niklaus Wirth's P-Code implementation of Pascal. A
very
> powerful virtual machine running (in my case) on an 8080
> microprocessor.
>
> A more up to date example is the OOPIC which uses an 16F877 or
> similar PIC and implements a virtual machine using external EEPROM
> for the tokenized object code.
>
> See www.oopic.com or the OOPIC group here on Yahoo.


How about considdering the actual use of the memory ?

Write a program that would look at the code and see how much stack
usage each part of the program, subroutines and function takes ?
Analize the code to see what uses the most memory and then tighten
the code for those parts.

Check out Don K's "RAMalizer" idea

http://www.kinzers.com/don/BX24/ I was involved (indirectly) with computer control of some processes
bay in the early 80's and with something like 2,000 total points
being monitored, 2 point took more programming than the rest of them
combined !

It may not be fair to compaire boolian logic on 1,998 points and
floating point math, square root and PID on 2 points, but you might
get the idea that concentrating on WHERE the memory is used may make
a better use of your time than on expanding where the operators are
stored. There are co-processors like the PAC-x modules from AWE
http://www.al-williams.com/pak1.htm
There are a dozen or so modules if you search around on the site.

The idea is that if you can isolate one or more program hogs, you can
use a co-processsor that can do those and free up space in your main
chip.

Dave