|
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 |
|
|
reading program from external EEPROM
Started by ●February 21, 2004
Reply by ●March 3, 20042004-03-03
Reply by ●March 4, 20042004-03-04
|
--- 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 |
