In SX Microcontrollers, SX/B Compiler and SX-Key Tool, g_daubach wrote:

Using Harvard architecture does not exclude external memory extension per-se - it it only the question if you do have address and data buses available for such purpose which is not the case with the SXes. An advantage of Harvard is that you never can run into such desasters like programs overwriting their own code (provided it is held in RAM memory). I think we all have made such experiences with "hanging" PCs under good old DOS, or Win 3.11, and even protected mode does not always protect from such things. Therefore, I prefer Harvard architecture - at least with microcontrollers.

Again, the "tokens" concept has nothing to do with Harvard architecture - you can run tokenized code on any type of computer. For example, the BASIC interpreters that came with the first home computers usually worked this way. While entering program instructions with an editor, these instructions were translated into tokens, and stored in memory. For example, a PRINT would be translated into $01. Most BASICs allow to use "?" as shorthand for "PRINT". In case you entered "?", and later did a "LIST" to display the program on the screen again, you could notice that instead "?" a "PRINT" was displayed. This is because the "LIST" re-translated the tokens back into "long".

To execute a tokenized program, you need an interpreter program running on the SX, reading token by token from the EEPROM, and executing pre-defined code, depending on the token.

This is exactly how a BASIC stamp works. On the PC, you enter the PBASIC program in text form. When this program is compiled, the textual instructions are translated into tokens. Such tokens are sent to the BS and stored there in an EEPROM. The token interpreter which is resident in the BS mocrocontroller's program memory, then reads, interprets, and executes the tokens. You can imagine that program execution is a lot slower compared to a program directly running on the controller but for many purposes, it is still more than fast enough, with the advantage that larger programs are possible.

IMO, I²C vs. SPI is also a matter of taste - I prefer I²C, and the code size for handling I²C or SPI is not that different.

Most EEPROMS are in page format but this is only important for writing. Usually, when writing data to an EEPROM, you need to do this page-wise, e.g. 8 or 16 bytes at a time. This is because the data you send for writing go into an internal RAM first, and then the EEPROM cells are programmed by reading from this RAM buffer. This takes a while, and your rouine must wait until the write process is finished, before sending new data. Reading an EEPROM usually has no page limitation. Once you have sent a starting address to the EEPROM, you can "linearly" read as many bytes as required. See the datasheet for any popular serial EEPROM for more details.

---------- End of Message ----------


You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=97449#m97803

Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com

The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)