Optimal EEPROM for the SXes

LoopyByteloose

Well, in my reading I have come across a need to add eeprom to an SX-28.

There seem to be so many types of eeprom, I was wondering if someone might bring me up to speed on what is optimal.·

First purpose is primarily DATA
I presume there is some kind of 'flash' eeprom that can be programed with the SXes themselves.· This would be a big advantage and I am wonder about how that process can be easily set up.

I am not trying to reverse engineer the BasicStamps.· I just want to know how to expand the capabilities to include more data [noparse][[/noparse]let's say for a menu set in an LCD output or for a lengthy data scheme to output controled pulses or voltages via pulses].

In the back of my mind is also the ever alluring idea of adding RAM to collect data for later transmission.· But that is really secondary.

Second purpose is to expand PROGRAM code.
I do understand that program code is 14bits wide and would require two byte pairs to retain it.· I am a bit fuzzy on the possiblity to actually move it into any place where it can become useable.· I presume that I would have to move blocks of it to pages of RAM and have a resisdent sub-routine put it into play.· Obviously this may slow code processing by a factor of 10 or more and it looks like I might have to jump in and out of·an ISR to store a return location for the program thread.

Am I right or just imagining things?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)

······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Paul Baker

Data expansion is fine, if updates are infrequent I would get an eeprom, if updates are frequent I would get FRAM. Program memory cannot be expanded, there is no mechanism to import program instructions into the SX. What the stamp does is store tokens (pseudo-instructional commands) which in turn executes pre-existing code segments in the SX. You would have to do the same if you wanted such exandability. EEPROM and FRAM come in two flavors, I2C and SPI, I2C is 2 wire, SPI is 3 wire (4 if /CS is used) but SPI is considerably faster. Another asset to FRAM besides its higher writable endurance is its programming speed, enabling "speed of serial" writing, eeprom requires ocassional programming wait times.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Post Edited (Paul Baker) : 11/22/2005 4:08:29 PM GMT

Guenther Daubach

Kramer,

to be honest, I have the feeling that you are bringing up a very theoretical question here. Let me analyze/comment this in simple steps:

1. Did you ever run into a situation when programming an SX28 with all the program memory used for program code? When the answer is "no" - don't worry for now, and keep going to hit the limit. In case the answer is "yes" - switch to an SX48 with twice as much program memory space. This will allow for much more code before hitting the limit again.

2. There is no way to directly expand any SXes program memory by adding external components. Due to the Harward architecture, there is no way to directly read instruction code from external memory and have it executed by the internal processor engine, i.e. you can't directly convert data (i.e. values read in via input ports) into instructions.

3. The only way to do it would be "BASIC-Stampish", i.e. by running an interpreter engine on the SX, reading and executing tokenized code from an external EEPROM. (I have developed such a system for a PLC-alike SX system, called µControl).

4. A minimum of SX I/O pins would be required when you use serial external memory devices, like I²C or SPI EEPROMS, or FRAMs with the drawback of reduced access speed. Using external memory devices with parallel data and address busses will "eat up" almost all of your available SX I/O pins, so you would have to add external address latches/multiplexers, for example.

5. Always keep in mind that the SX is perfect for many different applications, but not for each and every one. So you will always have to make a decision if it makes sense using an SX for a special application, or not. Since I learned about the SX, I've been using it for so many different purposes - complicated ones, but also for really trivial things. Instead of soldering together a bunch of "low-level" digital components, like gates, flip-flops, or shift registers, I just take an SX, and let it do the required task in software. This is so much fun, and saves you a lot of time! So, with the SX you may have a solution on hand for many applications within a minimum of time, but (like with any kind of device) there are limits as well, you should be aware of.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

Günther

LoopyByteloose

Well it is Thanksgiving Day here in Taiwan, so I just want to say thanks to all of you.

I must admit I should put some time in searching what has already been discussed about this topic and I know it is reoccuring. I will do so rather than try to make everyone rehash their knowledge and points of view.

I do realize that my question has a theoretical side to it, but it really disposes of the problem of me wasting time imagining the SX is something that it isn't. So, I think it may get more learners than myself pointed in the right direction.

It also clarifies the mysterious 'tokens' reason for existing. {It is really hard to find much written about using such a concept with Harvard architecture and I suspect anyone that needs or wants to truly jump the barrier should go to VonNeuman architecture on a single board computer.}

I do understand the pro and con of SPI versus I2C, but some people actually use a combined input and output wire on SPI. In that case they do take the same number of connections and the SPI apparently may run with less code to service it.

I thought that some EEPROM is in a 'page format' that is not appropriate for being read by the SXes. Is that true?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)

······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Post Edited (Kramer) : 11/24/2005 2:55:11 PM GMT

Guenther Daubach

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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

Günther

Nate

Gunther,

Great explanation of the token system!· Almost makes me want to write my own for my SX projects, but I enjoy writing in SASM too much.

A quick clarification on the EEPROM:· you can write to most EEPROM any size data you want, you will just have to wait for the internal write cycle·if you change pages.· EEPROM is eminently usable with the SX.· In most applications that I have written, I have been able to have the SX do something else while waiting for the EEPROM to do its internal write routine.

Also, the SX program registers are 12 bits wide (not 14), so you can store 1.5 bytes of hardcoded data in each program memory location.· I have written a driver application that runs a 640x480 LCD using a tile (sprite) system using the program memory of the SX to store alpha-numeric and other characters.· Since you will probably be writing to the·memory with IC2 or some other serial system, the width of the program memory registers is irrelevant as long as it is known.

My $.02

Nate

LoopyByteloose

I will just keep quiet and read. This is all good info.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)

······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan