Storage and Retrieval BS2

rmnsc1v16

I am fairly new to the Basic Stamp (have worked with it for about 5 months on and off).· I am presently helping some of my classmates with a project on which they will be taking temperature readings at about 10 000ft.· I have been able to calibrate the thermisistor to accurately measure temperature using an RC circuit, but since they may not retrieve their device before the battery runs out, I am not positive what the best way to store and retrieve their would be.

So my question,·· how do I store information to be later retrieved using a BS2 stamp?·
Could someone demonstrate a very simple example of code?

Thank you all

allanlane5

An SPI eeprom (24LC640?) can be easily interfaced using SHIFTIN/SHIFTOUT commands. And it will hold data with the power off.

Using the WRITE command, you can write to the internal EEPROM of the BS2. However, the BS2 has a limited number of write cycles allowed to each location of the EEPROM. In normal use this is not a problem -- you have like a million writes. But during testing and debug you MUST be careful not to WRITE to the internal eeprom in a run-away loop, or you can 'wear out' locations.

rmnsc1v16

Once you write to EEPROM, disconnect serial cable, and power, how do you go back and retrieve that data that you wrote?

Bruce Bates

rmnsc1v16 -

The answer to your question very much depends on a couple of things.

1. How much data do you need to save? (I.E. A total of 200 bytes)

2. How often do you need to save it? (I.E. 3 bytes every 2 minutes)

3. Does the data need to be transportable - say to an off-site PC for analysis?

4. Are there any cost or other restrictions on the ideal solution?

This and perhaps other similar questions will lead to one of the following answers:

Onboard EEPROM

External EEPROM

Externnal Flash memory

External IDE, CF or SD "drive" media.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->

rmnsc1v16

The number of test values will be relatively low. I haven't been given the full details of the project, but I would say that no more than 15 data points will be taken.· Also, the information would probably simply be read out with a laptop.· The only numbers I need to retrieve are the RCTIMEs.· I have derived equations to do conversions using Excel.

Bruce Bates

rmnsc1v16 -

You write a program to read the data from the EEPROM, or make it an option in the original progream.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->

rmnsc1v16

So, if I run a new program to read from the EEPROM, it will not erase the information I write? just the old program?

allanlane5

Typically you put a time-outable SERIN as one of your first statements in the program.

Then, you reset your program. In the first 5 or 10 seconds, you enter something from an attached laptop terminal.

If the BS2 gets something on the SERIN, then it jumps to a 'dump' routine, that reads out the eeprom and sends it (via SEROUT) to the attached laptop. If the SERIN times out, then the BS2 'knows' it's really data recording time.

An alternative to this is assign one I/O pin to a 'data record' vs 'data playback' purpose. Put a simple switch and pull-up resistor on this pin. In one position, the switch indicates 'record'. In the other position, 'playback'.

Bruce Bates

rmnsc1v16 -

Programs load into one end of EEPROM memory, and user EEPROM is allocated from the other. It IS possible to clobber a program by writing a whole bunch of data into the EEPROM, but it's not terribly common. If you get to that point, there are aloso safety measures you can take to avoid that and produce an error message instead of "blowing" program memory.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->

Sarten-X

What I would do is something like this, and use a jumper to set the state of pin X:

---

' {$STAMP BS2}
' {$PBASIC 2.5}

' Set up a jumper on pin X, using the active-low circuit in the documentation for the BUTTON command.

L VAR Word ' Location
Temp VAR Word ' Temporary variable
Measurement VAR Byte ' Measurement
N CON 1 ' Sleep time
PROGRAM_SIZE CON 96 'Length of tokenized program, padded a bit

IF (INX) THEN GOTO OUTPUT_CYCLE ' Check state of pin X
L = 1 '
DO ' Begin recording cycle
L = L + 1 ' Move to the next location. This also starts recording at position 2.
RCTIME ... ,Measurement ' Take measurement
WRITE L, Measurement ' Record it immediately
WRITE 0, L ' Keep track of where we last wrote to
IF L > 2047 - PROGRAM_SIZE THEN END ' Stop recording if we get too close to the program
SLEEP N ' Sleep until the next measurement - THIS LINE IS ABSOLUTELY NECESSARY!!!
LOOP

OUTPUT_CYCLE:
READ 0, Temp ' Get the number of samples taken
DEBUG Temp, " samples",cr
FOR L = 1 TO Temp ' Loop through each measurement
READ L, Measurement ' Get the data
DEBUG DEC Measurement, CR ' and send it to the console
next

END_CODE:

END

---

To record data, put a jumper where the switch is in the BUTTON circuit. This will connect the pin to ground, making the program enter the recording loop. Then, to retrieve the data, connect the stamp to a computer, and remove the jumper.
This program uses an extra byte of storage (location 0) to keep track of the number of data points.

Tracy Allen

Hi, I think your program strategy makes sense, and with so little data and probably a weight limit for flight, it is probably best to keep everything simple.

RCTIME data might be words, so the syntax would probably have to be
WRITE L, WORD measurement
L = L+2

I don't recommend using location 0 over and over like that to store the data pointer. Danger of overusing that one location. Another strategy is to allocate 500 bytes (250 measurements) for data memory and erase is to $ff to start. Don't allow $FFFF as a measurement (maximize at $FFFE). Then when you offload the data, keep reading until it returns $ffff or until 250 measurements, whichever comes first. Then erase for a new run.

Also, if the logger happens to reset, the program should seek out the current next location to write, so that it doesn't overwrite existing data prematurely, until specifically commanded to do so.

If the project will have a real time clock chip with a battery backup, then it may have RAM and that is a highly superior place to store the log pointers.

For the top of the program, a serial branch is convenient. At reset:

top:
SEROUT 16,$54,[noparse][[/noparse]"0) start logging 1) offload 2) erase <enter 0,1,2> "]
SERIN 16,$54,10000,startlogging,[noparse][[/noparse]DEC1 response] ' defaults to logging on timeout
ON response GOTO [noparse][[/noparse]startlogging, offload, erase]
GOTO top

The scheme to use hardware buttons would also be fine. Put in another button or combination or hold down for a long time, some scheme to signal the logger to erase the existing file and start over.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Sarten-X

Rather than allocating a fixed, small, number, I prefer to use 2047 - PROGRAM_SIZE, with PROGRAM_SIZE being defined as a constant. The memory map (and memorizing multiples of 16) makes this easy, and it maximises data.

Good idea about filling the EEPROM... recording to 0 was the best solution I could think of for the power outage possibility, and I didn't think about the possibility of it resetting.

what buttons? I'm just referring to the help file that comes with the PBASIC editor. In the documentation of the BUTTON command, there is a schematic to properly set a pin's state, and optionally force it to change. I suggest using a jumper in place of the button, so it's a hardware seting whether or not to record data. I was·thinking that with a jumper in place meaning "record", a masking-tape label could be attached to the jumper, so that after retrieval, the·label would be an obvious reminder to remove the jumper, so the data would not be overwritten. With a resuming feature, such a tag would be unnecessary.

A thought about the resuming feature: Perhaps it should write a special token to the EEPROM, so it is evident some samples might be missed?