reading program from external EEPROM

Started by Michael Millikan February 21, 2004
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



Why would you do this??
A PIC can't execute from GPR (RAM), so you would have to program the instruction into
FLASH first. This takes several mS, and the FLASH has a limited number of writes before
it is destroyed......There must be better ways of getting the job done.

Michael Millikan wrote:

 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

--
*******************************************
VISIT MY HOME PAGE:
<http://home.online.no/~eikarlse/index.htm>
LAST UPDATED: 23/08/2003
*******************************************
Best Regards
Eirik Karlsen
 


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.
 

Wouter van Ooijen

-- -------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
 

 



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





> 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



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




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


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

_________________________________________________________________
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



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.


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