|
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 |
|
|
reading program from external EEPROM
Started by ●February 21, 2004
Reply by ●February 21, 20042004-02-21
|
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,-- ******************************************* VISIT MY HOME PAGE: <http://home.online.no/~eikarlse/index.htm> LAST UPDATED: 23/08/2003 ******************************************* Best Regards Eirik Karlsen |
|
|
Reply by ●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.
Wouter van Ooijen |
|
|
Reply by ●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 ? 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 ●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 ... what do you mean? Wouter van Ooijen -- ------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products |
|
|
Reply by ●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 ●March 1, 20042004-03-01
|
--- 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 ●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. > _________________________________________________________________ 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 ●March 3, 20042004-03-03
|
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 ●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. Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC compiler |
|
|
