High Altitude Balloon Tracker and using the SST25VF032B 4Mbyte Flash memory

srnet

Senior Member
I have been working on HABAXE, my take on a PICAXE based high altitude balloon tracker.

The UK High Altitude Society (UKHAS) have a very well organised method of tracking high altitude balloons (HABs) whereby a lot of listeners co-operate by connecting their stations to the Internet and the results are plotted on line in real time on a map. The trackers generally transmit GPS location and other data as FSK RTTY.

This works well, but there is no reason why tracking a balloon cannot be done an a smaller scale with one person or a team following a balloon by receiving telemetry back containing the balloons location. If you are the only person tracking a balloon, it would be good when you eventually get it back if it had its track recorded on the tracker itself, record it in the right way and it can be loaded into Google maps. .

So I was looking at the SST25VF032B Flash memory, its a 4Mbyte SPI based device, in a 8pin SOIC package and ideal for the logger part of a tracker. The device supports single byte write and read, as well as word write with auto address increment. Endurance is 100,000 erase cycles minimum, and the erase can be by 4Kbyte, 32Kbyte or 64kbyte blocks, or indeed the whole device. If a tracker was switched on, the Flash memory erased (50ms) and the GPS data written as single byte writes to sequential memory locations as the balloon flight progresses, 100,000 count endurance on each byte is plenty. If a single location entry is 64 bytes each, recorded every 10 seconds, there is 182 hours worth of logging available.

Once I had the basic routines for the SST25VF032B working using the HSPIOUT and HSPIIN commands and could erase, read and write to the device, I wrote some software to check the endurance limit for a single 4K sector, using a sector right at the top of memory. I did this on two sectors and got to 325307 and 225417 erase cycles before an erase error occurred, so the endurance is well within data sheet limits.

When implementing designs on a PICAXE some peripheral devices need a SPI bus interface whilst some need I2C. The X2 PICAXEs do support both bus interfaces, but you cant use them at the same time. The SPI device has a chip select so it can be turned off, but a lot of I2C devices do not have a chip select. The I2C device can then be confused and corrupted by the clock and data lines being active for the SPI device.

So what to do if your design needs SPI and I2C ? There at least 4 solutions to this;


Use an I2C bus isolator.

There are I2C bus isolators which could be used, but they tend to be neither cheap or in hand assembly friendly packages.


PEEKSFR and POKESFR on the PIC hardware directly

For SPI peeking and poking the PIC hardware directly is surprisingly easy to do, and whilst not as fast as using the PICAXE HSPIOUT and HSPIIN commands, it is faster than using SHIFTOUT and SHIFTIN.

On the 28X2 and 40X2 there are two of the SPI\I2C hardware interfaces but the PICAXE firmware only supports one of them. The second SPI|\I2C interface can be used via the PEEKSFR and POKESFR route.


The SHIFTOUT and SHIFTIN PICAXE commands

These commands can be used to emulate an SPI bus interface, and have the advantage that they can be used on any available PICAXE pin.


Use the bit bang routines in the PICAXE program manual.

These do work, and can also be used on any available pins, but are quite slow.


I next wrote a program for the normal PICAXE hardware SPI interface that erased the device, set the first 256 bytes to 0-255 respectively, then had the PICAXE read each byte back one at a time, and recorded the time for 20 cycles of this, so a total of 5120 individual byte reads and checks. Also using a scope I measured the rate at which each of the methods could write to the memory.

I converted the program to use POKESFR and PEEKSFR commands on the PIC No2 SPI interface. In theory the routines for this approach should check that a byte has been sent by checking the PIC register status flags, but at 8Mhz the slowest SPI data clock (fosc/64 = 125Khz) will still clock a byte out in 64uS so the byte is sent long before the PICAXE can execute a PEEKSFR command to check the status flag.

I then converted the program using the SHIFTOUT and SHIFTIN commands, and finally I converted the program to one that drove the SPI bus by a bit bang approach.

These last two versions of the program (SHIFTOUT and BitBang) can be used on any available PICAXE pins. The SHIFTOUT command is only available on X1/X2 devices.

The time to read back and check a byte, the maximum byte read write rates on the overall program size for the 4 methods were;

Method, Average time to check a byte, Byte R\W rate, Program Size Bytes,
HSPIIN, 5.4mS, 120-140uS, 778
PEEKSFR, 6.7mS, 320-330uS, 868
SHIFTOUT, 9.6mS, 860-880uS, 848
Bit Bang, 91mS, 8-10mS, 963



All the routines worked at 64Mhz, so 8 times faster than above, although the first HSPOUT program needed to use the spimedium setting, spifast caused errors.

The PEEKSFR and POKESFR approach on the X2s second SPI interface seems to be the way to go, its almost as fast and the inbuilty HSPIIN and HSPIOU commands.

programs are attached, which include routines for single byte read\write and sector and device erase.
 

Attachments

Morganl

Senior Member
Thanks :)

Using SPI + I2C will probably be needed one day :)

Another method could be to use a HCMOS 4051 to mux the PICAXE outputs (if it is master).
 

hippy

Technical Support
Staff member
programs are attached, which include routines for single byte read\write and sector and device erase.
Excellent examples. There is nothing wrong with way you have done it and the modular approach is a good one but to gain execution speed it is sometimes necessary to sacrifice modularity.

Looking at the HSPI and PEEKSFR versions it seems there could be some increase in speed to be gained from in-lining the gosub calls to 'disableblockprotection' and 'writeenable', and worth that at least in the more commonly used routines like 'writesinglebyte' or 'readsinglebyte'. As 'wvar1' is a word variable there is no need to split it explicitly into two bytes and some of the high/low 'NSELRAM' changes could probably be optimised away.

Such speed gains would probably apply to the others as well but would make for a smaller percentage increase in speed.
 

srnet

Senior Member
There is nothing wrong with way you have done it and the modular approach is a good one but to gain execution speed it is sometimes necessary to sacrifice modularity.
Rather than optimise for each method, I stuck to the same general structure so I could get a reasonable comparison of the speed of the various options.
 

srnet

Senior Member
Another method could be to use a HCMOS 4051 to mux the PICAXE outputs (if it is master).
Well, yes I did think to try the analogue switch method.

Whilst an analogue switch did isolate the I2C side and prevent any corruption, the flash memory on the SPI side was all over the place with lots of errors when the clock line was connected to the analogue switch.

(and yes I do have a scope)
 

Morganl

Senior Member
Use the third switch in 4051 to ground the clock to SPI cirquit when I2C is selected.

Anyhow, your method means one one IC less :)
 

srnet

Senior Member
Use the third switch in 4051 to ground the clock to SPI cirquit when I2C is selected.
It was the fact that the clock line (from the PICAXE) was connected to the analogue switch in the first place that was the cause of the problem.

There would be no need to ground the clock to the SPI device when I2C was in use anyway, as the SPI device is made in-acative via its select line.

The analogue switch method, switching off the data and clock line did prevent the I2C being corrupted however, whilst at the same time there were no errors writing and reading to a I2C RAM device.

Anyhow, your method means one one IC less
And simpler too, if your sharing the SPI\I2C hardware in this way, you would need to re-issue the SPI and I2C setup commands all the time.
 
Top