Spin equivalent of PBASIC Read and Write commands

Genetix

How would I do the equivalent of the PBASIC Read and Write commands which read and write from the EEPROM in Spin?

Mike Green

There are several objects in the Propeller Object Exchange that allow programs to read and write EEPROM (or other I2C devices). The simplest is "Basic_I2C_Driver". There are comments in the source file that explain what each of the routines do and the comments at the beginning show a simple example. ReadByte and WriteByte are simple ways to handle a single byte while ReadWord and WriteWord handle a 16-bit word as two bytes. WriteWait will handle waiting for the EEPROM to finish writing or you could use "waitcnt(clkfreq/10 + cnt)" to wait for 1/10 of a second which should be long enough for any EEPROM.

JonnyMac

I do a lot of non-volatile storage with the Propeller so I wrote an EEPROM object. This uses a child object for I2C.

Note: My I2C object requires a pull-up on the SCL (clock) line.

The EEPROM object has several methods for writing to and reading back from the EEPROM. One of the neat tricks with the Propeller is that you can save a variable to the EEPROM such that it will automatically be reloaded with the last written value on the next power-up cycle. Assuming you're wanting to do with with a long, the syntax looks like this:

ee.wr_long(@someVariable, someVariable)

The first argument is the address to write to. If one uses the address of the variable being written, it will auto load after the next reset.

Bobb Fwed

Or a more complex scheme. I find very useful for systems with user input that needs to be saved, is my very own Memory Storage Management -- Either a "lightweight" one here, or one that allows you to store strings and arrays too here.

These objects also have basic read/write wrapper commands to handle basic byte operations. Hope these can help someone.

And what JonnyMac said is very useful. I implement that all the time in my software, with methods like these:

VAR

  long myvar

PUB Main

  store_and_save(@myvar, 26, 4) ' stores myvar to a new value of 26, and saves it to EEPROM. Next time the Propeller boots up, myvar is set to 26 without having to read from EEPROM

PRI save (addr, size)'' save a value to the variable's EEPROM address


  MEM.write(addr, addr, size)


PRI store_and_save (addr, value, size)
'' assist in setting a value then storing it to EEPROM


  CASE size
    1: byte[addr] := value
    2: word[addr] := value
    OTHER: long[addr] := value


  save(addr, size)

Genetix

Thanks everyone. I looked at those objects and saw they all communicate directly with the EEPROM by bit-banging.

JonnyMac

You're aware that's how the BASIC Stamp connects with its EEPROM as well, correct? The reason that the Propeller can be so much faster than the BASIC Stamp, even with an external memory, is that the code and data is copied from the EEPROM to [much faster] RAM after reset. This leaves the I2C lines free for our use, including modification of the boot EEPROM (with care).

If you were looking for direct analogs for READ and WRITE, they don't exist because there was not enough room in the interpreter. For the same reason you don't find HIGH, LOW, INPUT, PAUSE, SHIFTIN, SHIFTOUT, etc. That said, the Propeller is far more powerful than the BASIC Stamp, and we can easily include advanced features with a bit of code. The best part about that is we get to decide exactly how those features work. I created my EEPROM object because I was developing a commercial product that records and plays back from the EEPROM. That object works exactly the way I need it to work.

Bobb Fwed

Genetix wrote: »

Thanks everyone. I looked at those objects and saw they all communicate directly with the EEPROM by bit-banging.

That's embedded systems for you. It's lower level programming than most are used to. The nice thing is that people have (for the most part) already written the bit-banging side of things, so you can just simply use the write and read functions. But all embedded systems, PBASIC included, come down to bit-banging the information out. Each IC has a specific protocol that the controller has to conform to, so the software is customized to fit that protocol.

Genetix

I see that the BS2 writes from the Top of the EEPROM down and that only the first 32KB is affected by Propeller programming, so since new Propeller boards have 64KB, I should start from 65535 or $FFFF and work downward. I also noticed that the newer Propeller boards have pull-ups on both lines which Jon's code expects. Jon's excellent BS2 write-ups and code have given me a good understanding of how the I2C protocol works though I have only skimmed the Spin versions thus far. After looking at EEPROM datasheets, I would use Random Write and Sequential (Page) Read for data-logging.

JonnyMac

If you have a 64K EEPROM, you can start writing at $8000 (end at $FFFF) -- this will put your nonvolatile data above the 32K program size of the Propeller and it will be safe from program downloads. I'm working on a customer app that has three distinct sections, and all three will not fit in one program. The solution is to save non-volatile data in upper EEPROM and load the desired program element from an SD card that is part of the project, anyway. If the desired application segment is already running, there is no need to reload.