'16C84 Data EEPROM, Working!'
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
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
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
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
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'.
Do you ever feel like an XT Clone caught in the Pentium Pro Zone?
At 10:43 AM 8/23/96 EDT, you wrote:
>Well, I've gotten EEPROM writes working with 3 Seven Segment LED Displays.
>I finally found my last problem; .... <snip>
Many thanks to Myke. The excellent description he gives about his PIC
adventure should be of help to many list members ... which is of course just
what the 'net is all about.
Well done, Myke!
> From: myke predko <PASSPORT.CA> myke
> 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.
In all my career, copying lines of code has caused the most bugs/headaches.
My rule is now: copy lines to save typing; don't copy lines to save
thinking. I now eyeball each line as if I just typed it manually.
I am surprised! I didn't know there was any requirement to set up
EEDATA before EEADR. I must have been lucky so far.
More... (looser matching)
- Last day of these posts
- In 1996
, 1997 only
- New search...