CURRENT ISSUE Contests
Feature Article
|
|
Issue #212 March 2008
LESSONS FROM THE TRENCHES
Do You Want to Do a Design?
Linked Lists
by George Martin
Start | Design Challenge |Database Design | Use A Linked List | Design Implementation | Code Review | Sources & PDF
DATABASE DESIGN
The internal database would look like this:
INT8 DialOut[MAX_GROUPS][MAX_NUMB][MAX_DIGITS];
Database design is really straightforward. It’s just one large array of 8-bit entities indexed by groups (type of error detected) and the digits in the telephone number. MAX_GROUPS is defined as 10, MAX_NUMB as 4, and I’m going to define MAX_DIGITS as 25. That should be large enough to dial numbers like 9,,,18005551212,,123 (20 INT8s). Where the “,” indicates a pause. So, in my example we’re dialing 9, pausing three units, dialing a 1-800 number, then pausing two units, and then dialing extension 123. I think that should cover just about any dialing issue that might come up.
This design uses MAX_GROUPS × MAX_NUMB × MAX_DIGITS = 10 × 4 × 25 = 1,000 bytes of memory. That data needs to be saved in a nonvolatile memory area so that it’s preserved between power outages. That nonvolatile type of memory is usually EEPROM and it is more expensive and smaller than RAM or EPROM. So, we need to use it wisely. I think this design meets those requirements.
Great, I wrote up this design approach and was ready to start. Not so fast. The customer called and asked if we could also handle 30 events with only one number for each event. Well, of course we could, but how? If we extend the present design, MAX_GROUPS becomes 30 and MAX_GROUPS × MAX_NUMB × MAX_DIGITS = 30 × 4 × 25 = 3,000 bytes of memory. In the second design request, we would be using one of the four available numbers (25%), and in the original design we would be using 10 of the 30 groups (33%). Neither is using these valuable resources very well and I bet the customer will come up with alternative requests that lead to ever more inefficient EEPROM usage. This is a perfect opportunity to try linked lists.
