NJQRP MicroBeacon

DESIGN (Part 3)

Memory for Memories

One of the other big design decisions is how to implement the message memories. My original thought was to use serial EEPROM, preferably putting it into a socket and choosing from a family that has show an increase in size of the years. This would allow us to pop out the current chip and drop in a larger one as newer members of the family appear on the market.

We're back to the same old question: which serial interface. I've looked at some of the Microchip chips and they are very easy to interface with (3 pins). I know other companies make similar devices with I2C and SPI interfaces. Which do we want? Ultimately, we want to be able to read consecutive bits at a slow rate; ie, playback speed.

One of the stated design goals is to allow variable length memories. While it's fairly easy to do dynamic buffer allocation and on-the-fly resizing in a system with tons of memory, it's a lot more difficult with serial eeproms and in a system that's sending CW, sampling paddles, etc, all at the same time. So, I propose we divide the available memory into 32 blocks of a fixed size. The first block contains information about the contents of the other blocks. A rough structure of the initial block would look somthing like this:

• Size of each block in bytes.
• Starting block number for memories 1-8 (or 0-7 if you prefer base-zero).
• Starting block of free-list.
• Checksum of block so the code can detect when an uninitialized chip is put in, or when the MicroBeacon is first powered on.

Each block would include a header that identifies which memory number it is part of and also the next block used in this memory.

The big problem with using either fixed block sizes or a fixed number of blocks is that we need to specify a minimum memory size. If we chose to set the number of blocks to 64, then the user obivously needs to install a 2k byte memory to get even a reasonable 32 bytes per block. If we reduce the number of blocks then we run the risk of having one or two big message memories using all available blocks. We could try to play games and use a minimal block size if the memory is small (<= 1K) and then switch to a fixed number of blocks when the memory is larger, but then the routines to deal with the blocks will get really messy and prone to bugs.

Just some thoughts; this is all open to discussion.

Go BACK to the MicroBeacon DESIGN page