-----Original Message----- From: Caisson [SMTP:caisson@TELEBYTE.NL] Sent: Thursday, February 04, 1999 3:06 AM To: PICLIST@MITVMA.MIT.EDU Subject: Re: To C or not to C > Van: Eric Oliver > Aan: PICLIST@MITVMA.MIT.EDU > Onderwerp: To C or not to C > Datum: woensdag 3 februari 1999 15:43 > > Hi guys, Hello Eric, Not fair ! ;-) I was just busy thinking about/doing the same, on a somewhat smaller scale (no keypad, no LCD. no MAX232. Requests received thru RS232), using 24Cxx I2C-memory (8 to 32 (64 ?) KByte variants). Maybe even leeching it's power from the RS-232 connection ... This is a specialized device to collect data from equipment in our plant so design on !! > First, I plan to implement a very scaled down version of the DOS FAT system > in the NVRAM. Master file table, FAT, sectors, and no subdirectories. The > user will not be aware of the storage scheme. I want to use it to > facilitate memory reuse as data blocks are added, changed, or deleted. Another way to link "sectors" together could ne done by adding a pointer to each data-block telling where the next "sector" is. What would be the benefits of this over a FAT. If I understand you correctly, a FAT accomplishes the same task. Sitting here thinking about it, Then by using your approach, sectors could be variable length. Since all my data is ASCII text, I can use 0x00 to denote the end of a "sector". No wait a minute. That would make the efficient reuse of sectors after a "file" has been deleted more problematic. The appeal of a FAT system to me is that all "sectors" can be reclaimed when "files" are deleted and "files" can grow or shrink without me ever having to worry about it. Having all information in the MFT and FAT makes "sector" reuse fairly simple. What do you think ? By the way : with 2 (or 4) MB of space a Directory-structure would be handy .. Although a file system was a good analogy to use, it was not exactly per fect. I will not have sub-directories per-se. "Files" will also be grouped based upon certain attributes, thus effectively implementing sub-directories for the user. > Second, the user must be able to search for a "file name". I thought I > would take the approach the cell phone manufacturers used. The user enters > a few characters from the beginning of the name by way of the numeric > keypad and then uses the up and down keys to scroll through the list. This > may require maintaining an index in a reserved portion of the NVRAM. If a standard DOS-type directory-entry will be used to store the file-names there is room to add 2 pointers, one "up" and one "down", creating a double-linked list. An "insertion" routine could add a new file-name anywhere, but by opdating the link-pointers make sure that the file-name list stay's sorted. This is a very good idea. Thanks !! Saves space. Warning ! DOS Standard way's to communicate thru RS-232 ("TYPE {text} > COMx" or "COPY {file} COMx") do not use handshake ... And you will need it (I think) when up-loading something to your device. So, the first thing to do is to load & install a "driver" for it .... My device will communicate in "ASCII text mode" only. Flow control is managed via XON/XOFF or RTS/CTS. This is not my choice it is a constraint placed upon me by our existing equipment. Thanks very much for your comments !! You have been very helpful. As I progress ( which should take quite awhile ), I'll keep you informed if you like since you want to build a similar device. Eric