--- 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
Reply by rtstofer●March 3, 20042004-03-03
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
Reply by sergio masci●March 3, 20042004-03-03
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.
I have an easier solution that will probably work -- buy a different
PIC. For example, the PIC18F6720 has 64K words of program space.
That is *a lot* of PIC code.
How much code space do you really need? Or is it just that you are
hell-bent on doing this? (I'm okay if the answer is yes as I
sometimes do things just to prove I can too.)
--Scott
--- In , "Michael Millikan"
<uwobjectivist@h...> 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.
Reply by Michael Millikan●March 3, 20042004-03-03
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.
> Date: Mon, 01 Mar 2004 19:22:29 -0000
> From: "mr_gees100_peas" <>
>Subject: Re: reading program from external EEPROM
>
>--- In , "Michael Millikan"
><uwobjectivist@h...> wrote:
>Hmm, I had the same question at one point. I guess what you really
>want is a way to read from a hard drive kind of device just like your
>computer does. Maybe you could interface a compaq flash card. or
>maybe you could use 2 or more PICs. One as a Master and the others
>for the aditional software. Now when you say you don't have enought
>meory do you mean to say program meory or Ram memory. By this I mean
>is the program too big or is the data collected too big? if is data
>you could use RAM modules and store data there temporaliry.
>
--- In , "Michael Millikan"
<uwobjectivist@h...> wrote:
Hmm, I had the same question at one point. I guess what you really
want is a way to read from a hard drive kind of device just like your
computer does. Maybe you could interface a compaq flash card. or
maybe you could use 2 or more PICs. One as a Master and the others
for the aditional software. Now when you say you don't have enought
meory do you mean to say program meory or Ram memory. By this I mean
is the program too big or is the data collected too big? if is data
you could use RAM modules and store data there temporaliry.
> Hi there,
>
> I assume that people have attempted to have a PIC execute code that it reads > from an external EEPROM (when the PIC itself
doesn't have enough memory.) > Does anyone have a good reference on how I might
do this?
>
> I was thinking of loading an instruction from the EEPROM into the PIC's > memory - having a subroutine execute that one
instruction and jumping back > to do another read. Goto statements would have to
be done a little
> differently because as you can imagine it wouldn't work that way, so they > would have to be done as write instructions to the
next read address in the > PIC... anyway, those are just some thoughts I
had.
>
> Any help would be appreciated. Thanks.
>
> Vecheslav Silagadze
>
> _________________________________________________________________
> The new MSN 8: smart spam protection and 2 months FREE*
> http://join.msn.com/?pageatures/junkmail
> http://join.msn.com/?paget/bcomm&pgmarket=en-ca&RU=http%3a%2f% 2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca
Reply by ydexter●February 28, 20042004-02-28
I see that microchip docs are somehow confusing because they are
mixing advertising data with technical data. I will read again the
damn docs to be able to distinguish among types of memory present in
PIC family.
--- In , "Wouter van Ooijen" <wouter@v...> wrote: > > You are using the word flash here. Has PIC
another flash memory
> > different from 1024 kb where you suppose to load the PIC code ?
>
> If you have a particular PIC in mind you'd better say so. No PIC
has
> 1024 kb code memory, 0.5 .. 32 k instructions is common.
>
> PIC (except some 17C's? and/or TQPF 18's?) execute code only from
their
> internal code memory, which is EPROM on older PICs, flash on the newer
> ones.
>
> > I thought the flash is more flexible at write/read cycles ...
>
> what do you mean?
>
> Wouter van Ooijen
>
> -- -------
> Van Ooijen Technische Informatica: www.voti.nl
> consultancy, development, PICmicro products
Reply by Wouter van Ooijen●February 24, 20042004-02-24
> You are using the word flash here. Has PIC another flash memory > different from 1024 kb where you suppose to load
the PIC code ?
If you have a particular PIC in mind you'd better say so. No PIC has
1024 kb code memory, 0.5 .. 32 k instructions is common.
PIC (except some 17C's? and/or TQPF 18's?) execute code only from
their
internal code memory, which is EPROM on older PICs, flash on the newer
ones.
> I thought the flash is more flexible at write/read
cycles ...
You are using the word flash here. Has PIC another flash memory
different from 1024 kb where you suppose to load the PIC code ?
I thought the flash is more flexible at write/read cycles ...
--- In , "Wouter van Ooijen" <wouter@v...> wrote: > > I was thinking of loading an instruction from
the EEPROM into the
> PIC's
> memory - having a subroutine execute that one instruction and jumping
> back
> to do another read. Goto statements would have to be done a little
> differently because as you can imagine it wouldn't work that way,
so
> they
> would have to be done as write instructions to the next read address in
> the
> PIC... anyway, those are just some thoughts I had.
>
> You would wear out the flash pretty quick this way. Better define a
> vritual machine, store instructions for that machine in the eeprom, and
> have the PIC interpret them. Lots of compiler/interpreter combo's
work
> that way.
>
> Wouter van Ooijen
>
> -- -------
> Van Ooijen Technische Informatica: www.voti.nl
> consultancy, development, PICmicro products
Reply by Wouter van Ooijen●February 21, 20042004-02-21
Message
> I was thinking of loading an instruction from
the EEPROM into the PIC's memory - having a subroutine
execute that one instruction and jumping back to do another read.
Goto statements would have to be done a little differently
because as you can imagine it wouldn't work that way, so they would have to be done as write instructions to the next read address in
the PIC... anyway, those are just some thoughts I
had.
You would wear out the flash pretty quick this way. Better define
a vritual machine, store instructions for that machine in the eeprom, and have
the PIC interpret them. Lots of compiler/interpreter combo's work that
way.