View Full Version : loading an external database

01-19-2006, 05:41 AM

i want to build a device that loads an external list from a database on a daily basis·and displays it across an LCD.· the list would be fairly large by·microcontroller standards;·anywhere between 200-800 records, each with up to 20 charachters.· i think the best way to go about this is to have·seperate EEPROM where i download the list, then access the list with my stamp but i'm not totally·sure the bast way to go about this.· any suggestions?


David B
01-19-2006, 08:49 AM
Can you say more about what you want?

Will a PC be involved, to store the database, maybe? What will populate the database? Are you thinking about a full-size relational database, or maybe just a simple file containing rows of data? Or will some external device feed individual rows of data into your storage device? And if that, what will erase the previous rows when your local storage gets full?

What sort of output will you want - will the display scrolling through the rows be automatic, say delayed for a second for a person to read, or will they be scrolled by some buttons a user has to press? Would you want the ability to scroll backwards as well as forwards? Will a person start the displaying of rows?

What is this thing? What is it for?

01-19-2006, 08:15 PM
this will acually function a lot like a list of contacts on a cell phone. i want to hook the device up to a PC once a day and download the latest list. once the list is on the device, you can use the back and forth buttons to maneuver the list. where i get lost is navigating such a large list and getting the list on the device. should i use some type of external eeprom, if so how do i navigate through that and how can i hook it up to a PC to download a list? the list will likely be in MySQL and i guess i can write a program to output the data from the DB out a serial port, but will that work? if so does anyone have any examples?

Loopy Byteloose
01-19-2006, 11:22 PM
You definetly would have to use some sort of external memory storage as the BasicStamp just cannot handle that much data.

A likely device is a I2C eeprom as it would leave you with the other pins free to control the LCD. Traditional memory [not serial] would take too many pins.

Having said that, you have to figure out your database in terms of how long each entry will be and how you are going to separate the data fields. The more fields you have, the more complex it gets. If you just have two [a name and telephone number] it isn't very demanding.

I suspect you won't have sort, you won't have the abilty to add new entries, and so on. If you really need that kind of think a PDA does it very well and programs are already available to set up a database. You even have your downloading from a PC pretty well set up.

You also can do a lot more on the fly. There are several C programs for the Palm PDA with On-board C being free [with some additional software for $40] and another one is $18.

Or, you can use Excel to manage your list and have it all in Documents-to-go.

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

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

Post Edited (Kramer) : 1/21/2006 5:11:56 PM GMT

David B
01-20-2006, 03:08 AM
This could be done with a RAM chip.

Say you wanted up to 32 characters per entry and up to 1024 entries. Then a 32K RAM would be just large enough. You could think of the 32K as 1024 sets of 32 character rows.

The first 5 address bits would scroll through the individual characters in each row. The next 10 addresses would scroll through rows.

Yes, if you actually only need 20 characters then there are lots of wasted bytes, but using the powers of two make row selection much easier.

You could use a counter like the CMOS 4040 12 bit counter to toggle the 10 row bits. You could use a separate counter to toggle through the 5 data bits of each row. You could even use up-down counters to make it easy to navigate through rows, but you might have to cascade several chips to obtain as many as 10 bits from up-down counters.

The 8 data bits would need to be individually connected to IO pins, as they will need both reading and writing.

I haven't actually worked out the pin count to figure whether a basic stamp has enough pins to do all this, including the RAM chip-select and read-write pin operation, and LCD display, data input and user button input. This sort of interface might be a good application for a Scenix sx48, with its many IO ports.

Your Basic stamp would first select a row using the row counter. Then it would scan the 20 characters out of that row for display using the character counter. If the user wanted the next row, your stamp would just increment the row counter and scan data to display again. If you wanted to scroll backwards with an up-only counter, you could issue 1023 pulses to it, resulting in your addressing the previous row, hopefully quickly enough that the user wouldn't notice any delay. Then just pop out that row for display.

Writing the RAM would involve a similar row/character selection.

I personally like working with ordinary static RAM because even though there are a lot of pins to deal with, the chip operation is usually straightforward and very fast, and small RAMs like this are pretty cheap. I've never worked with EEPROM or those FRAM chips, so I can't offer any advice about them.