Hi Gang, Well, I've gotten EEPROM writes working with 3 Seven Segment LED Displays. I finally found my last problem; I incorrectly initialized a variable. I used three values, one for each display, which indexes into two tables which hold the bit pattern for each of the displays. When the interrupt handler (I switch between the three displays at 2KHz) was displaying a value, it was getting an invalid offset into the table (which put the execution into another dimension, rather than returning the bit pattern for "0"). Big Arghhh... When I was writing the code, I copied a line repeatedly and didn't update the label name of the last display. The code worked initially because I wasn't running something that took a long time (like writing to the EEPROM) and the display value would be set correctly in the normal course of events. So, To get EEPROM writes working while displaying a byte on 3 seven segment displays, I had to debug with three problems: 1. The first (and most significant) was that the EEPROM Data and Address Registers have to be written in a specific order (EEDATA First and then EEADR) before initiating the "Data EEPROM Write" sequence described in the Data Sheets (which seems to imply that it is done in the reverse order). Once this was found and changed, I then had the problem of only one address in the EEPROM being written to, which made me think I hadn't flattened the problem. I ended up writing a simple routine which allowed me to experiment with writing multiple bytes. 2. The Individual Display Value Initialization wasn't present for one of the displays (although it was there twice for another one) (which I never thought to look at because I routinely clear all the registers before using them and I *never* get that wrong). What seems to be happening was that the LED displays would show the correct value ("000") on power up, but the interrupt handler code, when looking for the last digit (which hadn't been set yet by the program) would jump to somewhere in the PIC's Program that allowed it to reset, write the first byte off the EEPROM all over again, display correctly although not have the correct display value and branch to the boonies again and again... 3. I didn't understand how the MPLAB/PICStart Plus combination programmed the 'C84s data EEPROM. In Simulator Mode, the EEPROM is erased (written with all 0x0FFs) and cannot be read back. In Editor Mode, the EEPROM can be written to, but the Program Memory EEPROM, cannot be written AND does not update MPLAB's Program Memory EEPROM after Assembly. As you can imagine, these three different problems (along with a vacation and sending kids to camp during the process) were almost impossible to characterize. I did a *lot* of experimentation to finally understand all the problems I had. I really have to thank everybody who gave suggestions/hints/code and ideas. I really would never have solved the problems without them. I have received a number of questions on what I am doing, so here goes: As for the thermistor I am using, it is Radio Shack Catalog number 271-110 and cost me four bucks here in Canada. The cardboard package lists the different resistance values for different temperatures and as far as I can tell (from using my DMM), it is quite accurate (The package says the part is 1% tolerance). For the -5C to 50C temperature range that I am using for the application, the thermistor ranges between 34K and 4.16K with non-linear steps. I do not have a generic part number for the Thermistor. I am using the Basic Stamp II Resistance measuring circuit explained by Scott Edwards in "Nuts 'n Volts" a few months back. The thermistor is attached to Gnd on one side and a 0.1 uF Tantalum cap connected to Vdd on the other. At the connection between the thermistor and the cap, I have a 100 Ohm resistor connected to a PIC pin. The capacitor is charged from the PIC and then the time required for the charge to leak through the thermistor is measured. Scott indicates that the circuit works better with a 200 Ohm resistor between the RC and PIC, but I really haven't seen any difference in performance. The circuit is stable, but the sensor really should be on a longer wire. Right now, I have it attached quite closely to the PIC itself and I find that as the PIC runs a while and warms up, the measured temperature changes. The biggest issue I had was finding a cap of reasonable tolerance at 0.1uF. I have experimented a bit and found that they can range from 0.06uF to 0.2uF even for parts from the same bin (which matches my other experience). This is why I wanted to add my calibration routine, which stores a value in EEPROM (I don't feel like going through a ton of 15 cent capacitors to find one that is at the right tolerance and I don't feel like paying for a precision cap). The calibration code is written (it takes a scaling factor out of EEPROM and multiplies that with the measured value to get a table value) but not debugged (hopefully it will go better than the previous exercise). The 7 Segment Display Code, takes a byte and displays it as a positive/negative decimal number on 3 common cathode displays. Along with the conversion routine, the code uses the timer and interrupt handler (along with the FSR index register). The interrupt handler runs at 2KHz and each time it is invoked, reads and outputs the value for one of the displays. Because I built this using point to point wiring, I used all the PIC pins on one side of the 'C84. This makes the code a bit more complex, but eliminates the requirement for extra wires snaking around the bottom of the component (although pin RA4 has to be wired slightly differently than the other pins). The code itself can be easily modified for hex output or additional/fewer displays and I don't mind passing it along to anybody who is interested in it. The code that I will pass out at this time is the test code which I have been slaving over which loads an EEPROM value, displays it and allows you to modify it using to input pins. As for power, I am running the circuit using a 9 volt battery and a 78L05 with 10uF caps on either side for filtering. I haven't had any problems with the power draw and it seems to be capable of running for quite a while (ie for all my debugging, I'm still on the same alkaline battery). Once the completed circuit is complete and running, I will make it and the code available on the Microchip and Parallax BBS'. Myke Do you ever feel like an XT Clone caught in the Pentium Pro Zone?