How to expand program space
cwyuzik
Posts: 13
Hi All, I have a project I've been working on based on a propeller one platform. It's using a character LCD and capacitive keys for human interface to operate a couple of relays so the prop one is hardware wise up for the task. Using the propeller two would be overkill.
The spin program calculates a fairly complex algorithm that takes a big chunk of program space and many variables. So as it is now I'm just about up to the limit on program space, less than 1000 longs left in ram usage. However, to be commercially viable in my country the interface needs to be bilingual, which would take me over the top but not that much.
Presently I'm using a 256 eeprom. Could I simply switch to a 512 and use a different I2C eeprom object to expand the program space or is there more to it than that?
Comments
The actual program space is always 32K byte / 256K bit / 8192 longs, because that's how big the Propeller's RAM is. 1000 longs left would mean you still have ~20% to go (but you need to leave a couple free at the end because that's where the main program stack goes)
However, you can use the extra space of a 64Kbyte / 512Kbit EEPROM (or a 128Kbyte/1024Kbit one) with an I2C object. For something like user interface text, that's great, because it doesn't have to be loaded in super quickly.
The main problem you get there is that Propeller Tool doesn't write data beyond the first 32Kbyte. So you need to figure out another way to get the data into the upper EEPROM part.
Maybe the text could be on external memory?
I agree with Ada on this: Put your strings into the upper 32K of a 64K device. I work for a laser tag company and we are fighting for every free long in our code. We always had our data in the upper 32K so that we could move between apps (Editor, Player, Referee) with the same data. We also moved many strings to the upper EE because (as Ada pointed out) they don't need fast access, and in our case we don't need to store 100 tagger names in RAM when the player only needs to know his own.
I have a nice award from The Toro Company where I worked as a young guy; my team created the first multi-lingual irritation control system app in the company's history. Back then were were running DOS apps with a standard 80x25 text screen. The neat thing about the old IBM PCs was the screen memory could be moved to and from a file. We started by creating English files and then sending them to our colleagues around the world for translation with our custom screen painting tool (which was written in Turbo Pascal). All we need to know the was the language and the screen files used the extension to reflect that, for example, SCREEN1.ENG, SCREEN1. SPA, SCREEN1.FRA, SCREEN1.GER (German was challenging -- they have looonng words), etc. In your case, you may want to make a map of your strings where each is at a specific offset within a language block. There can be some challenges with EEPROM page boundaries, but if you use a PASM cog for high-speed I2C you can readdress bytes to allow strings to overrun EE page limits.
Yep, for laser tag we have a little utility that clears the upper EE and formats the data and string tables. This is run in the controller before it is loaded with the laser tag firmware.