What you need to do is create an external databus. The msp430 does not have a dedicated external bus, but it is quite possible to bit-bang a bus. Use all 8 bits of a port as the databus, and some other lines as control signals. Whether you want other ports to be used as address lines, or to use external latches depends on how many free pins you have on the msp430. Then you can connect up standard 8-bit wide (or 16-bit, if you really want) asynchronous memories and control them "manually" from the msp430. You won't be able to access the external memory directly (using pointers, for example), but will have to go through functions to read from and write to the external memory. I've used this technique on a number of systems (I have a Cop8 processor connected to 4 MB flash in this way).
The msp430 can execute code from RAM, so it is possible to copy code from the external memory into internal RAM and run it there. However, I expect that would quickly get complicated (and slow, as you have to copy all the time) since you don't have huge amounts of RAM space to place with. Putting strings in the external memory, however, will work well, and give you plenty of room for multi-lingual versions, etc. David > > Hello, > > Is it possible to use external memory (ROM, RAM, FLASH) with the msp430 > which holds executable program instructions? So it is possible to make > programs which are bigger than 60KByte? > > I know that the answer is 'No'. But does anyone have a creative solution. > > We have applications which extend the 60KByte program code. A big part of > the code is text string, which are used by the menu user interface. > Currently we are using de intel C196 processor for these applications. The > C196 can use external memory. And program code is in a page switching flash > memory. The C196 is getting obsolete. So we are looking to alternatives. We > uses the MSP430F149 is used in a number of (smaller) projects. > > Of course it is possible to use another processor. Should we? > Or is there a way to still use the MSP. > > Thanks Robert Bon. >
