LCD controlling with comparators

[Danny T]

Hi all,

I've (half-)built a "clock" using a cheap LCD display and a couple of
PICs. Currently, it's very OTT with pics, since I don't have any shift
registers or anything to control the 40 pins on the LCD, so I've got a
PIC for each digit, 8 input pins, and 7 output pins (7 segments per
digit). When the 8th input pin goes high, the other 7 are copied to the
output. This way, 4 digits can be driven from one PIC with 11 output
pins (7 for the segment, and one linked to each "active" input for each
digit).

What's the best (least components etc.) to do this in "the real world"?
I was thinking of addressable shift registers or something to replace
the PICs, but then it occured to me that it's also possible with a
comparator... Wire all the segments together, and use a comparator so
only when I "clock" the correct 7 comparators, would the outputs be
carried across to the LCD. I'm not sure of the relative costs of shift
registers/comparators - how would you do it?
--
Danny

 

[Anthony Fremont]

"Danny T" <danny@nospam.oops> wrote in message
news:41e93bbb$0$14590$ed2619ec@ptn-nntp-reader01.plus.net...

Hi all,

I've (half-)built a "clock" using a cheap LCD display and a couple of
PICs. Currently, it's very OTT with pics, since I don't have any shift
registers or anything to control the 40 pins on the LCD, so I've got a
PIC for each digit, 8 input pins, and 7 output pins (7 segments per
digit). When the 8th input pin goes high, the other 7 are copied to
the
output. This way, 4 digits can be driven from one PIC with 11 output
pins (7 for the segment, and one linked to each "active" input for
each
digit).

What kind of LCD do you have? You may need to be careful with how you
drive the digits.

What's the best (least components etc.) to do this in "the real
world"?
I was thinking of addressable shift registers or something to replace
the PICs, but then it occured to me that it's also possible with a
comparator... Wire all the segments together, and use a comparator so
only when I "clock" the correct 7 comparators, would the outputs be
carried across to the LCD. I'm not sure of the relative costs of shift
registers/comparators - how would you do it?

There's a bunch of ways this can be done, but yours wins the Rube
Goldberg award. ;-) You should multiplex the digits from just one pic.
You can use PORTB to connect to all the segments in parallel and then
turn on the anode (or cathode whichever it is) from PORTA pins. You put
the segments for the first digit on PORTB and then drive PORTA, 0 low
(or high) to illuminate the first digit. You then turn off the PORTA,0
pin and put the data values for the second digit onto PORTB, then turn
on PORTA, 1. Cycle thru PORTA, 2 and PORTA, 3 then back to PORTA, 0.

If you setup say a timer interrupt to occur every 10mS or so, you can
switch digits in the ISR and leave them till the next interrupt 10mS
later. That would update the entire display every 40mS or 25 times per
second. Your eyes will never know the difference and it will only need
11 i/o pins.

You could also use a shift register(s) in order to use less i/o pins.

 

[Danny T]

Anthony Fremont wrote:

What kind of LCD do you have? You may need to be careful with how you
drive the digits.

57-0160 from rapidelec.co.uk

It seems to be available in a 4-pin option, but I ordered the "31/2"
assuming it meant 21 pins on each side, but it only has 40 (no idea what
the "4" flava is then!)

CBarn24050 just suggested I shouldn't be driving it from DC - is this
really a big problem? It seems to be working fine, my clock has two
digits! Other two can wait till after tea - I've already wired about 60
pins together across 4 PICs...

http://dantup.me.uk/tmp/wires.jpg

There's a bunch of ways this can be done, but yours wins the Rube
Goldberg award. ;-) You should multiplex the digits from just one pic.
You can use PORTB to connect to all the segments in parallel and then
turn on the anode (or cathode whichever it is) from PORTA pins. You put
the segments for the first digit on PORTB and then drive PORTA, 0 low
(or high) to illuminate the first digit. You then turn off the PORTA,0
pin and put the data values for the second digit onto PORTB, then turn
on PORTA, 1. Cycle thru PORTA, 2 and PORTA, 3 then back to PORTA, 0.

If you setup say a timer interrupt to occur every 10mS or so, you can
switch digits in the ISR and leave them till the next interrupt 10mS
later. That would update the entire display every 40mS or 25 times per
second. Your eyes will never know the difference and it will only need
11 i/o pins.

This sounds like a fantastic idea *but* of the 40 pins on my display,
the only ones marked on the datasheet are one for every segment/dp on
the screen, plus two "com" (one on each side). I assumed it meant
"common" and grounded it, while connecting the other pins to pic
outputs, and they drive fine. I assume your method isn't useful for this
particular LCD?

Ta
--
Danny

 

[Anthony Fremont]

"Danny T" <danny@nospam.oops> wrote in message
news:41e96671$0$96019$ed2619ec@ptn-nntp-reader02.plus.net...

Anthony Fremont wrote:

What kind of LCD do you have? You may need to be careful with how
you
drive the digits.

57-0160 from rapidelec.co.uk

I found it, but no datasheet.

It seems to be available in a 4-pin option, but I ordered the "31/2"
assuming it meant 21 pins on each side, but it only has 40 (no idea
what
the "4" flava is then!)

CBarn24050 just suggested I shouldn't be driving it from DC - is this
really a big problem? It seems to be working fine, my clock has two
digits! Other two can wait till after tea - I've already wired about
60
pins together across 4 PICs...

Matrix type LCDs have to be scanned, the pixels can never be allowed to
see any DC voltage or they will cook. Your display does not appear to
be in this category. Your display is a very fixed purpose display.
Your display will only display 3 1/2 digits, that means the first column
can't show all the numbers 0 - 9, only 0-1 or 0-3 depending on the
display.

http://dantup.me.uk/tmp/wires.jpg

You should see the BASIC-52 computer I made with scads of jumpers for
the external latches and ram for the 8052. Kinda neat about 3.5" square
and runs on a 9V battery, just hook up to the serial port, push the
reset button, hit the space bar (or is it return) and it's 1977 again.
;-)

There's a bunch of ways this can be done, but yours wins the Rube
Goldberg award. ;-) You should multiplex the digits from just one
pic.
You can use PORTB to connect to all the segments in parallel and
then
turn on the anode (or cathode whichever it is) from PORTA pins. You
put
the segments for the first digit on PORTB and then drive PORTA, 0
low
(or high) to illuminate the first digit. You then turn off the
PORTA,0
pin and put the data values for the second digit onto PORTB, then
turn
on PORTA, 1. Cycle thru PORTA, 2 and PORTA, 3 then back to PORTA,
0.

If you setup say a timer interrupt to occur every 10mS or so, you
can
switch digits in the ISR and leave them till the next interrupt 10mS
later. That would update the entire display every 40mS or 25 times
per
second. Your eyes will never know the difference and it will only
need
11 i/o pins.

This sounds like a fantastic idea *but* of the 40 pins on my display,
the only ones marked on the datasheet are one for every segment/dp on
the screen, plus two "com" (one on each side). I assumed it meant
"common" and grounded it, while connecting the other pins to pic
outputs, and they drive fine. I assume your method isn't useful for
this
particular LCD?

This appears to be the case. If you don't have access to the cathodes
of each individual segment, then you can't multiplex it in the way I
described. You should be using a Hitachi type LCD display anyway, or 7
segment LEDs. ;-)

 

[Robert Monsen]

Danny T wrote:

Anthony Fremont wrote:

What kind of LCD do you have? You may need to be careful with how you
drive the digits.


57-0160 from rapidelec.co.uk

It seems to be available in a 4-pin option, but I ordered the "31/2"
assuming it meant 21 pins on each side, but it only has 40 (no idea what
the "4" flava is then!)

CBarn24050 just suggested I shouldn't be driving it from DC - is this
really a big problem? It seems to be working fine, my clock has two
digits! Other two can wait till after tea - I've already wired about 60
pins together across 4 PICs...

http://dantup.me.uk/tmp/wires.jpg


There's a bunch of ways this can be done, but yours wins the Rube
Goldberg award. ;-) You should multiplex the digits from just one pic.
You can use PORTB to connect to all the segments in parallel and then
turn on the anode (or cathode whichever it is) from PORTA pins. You put
the segments for the first digit on PORTB and then drive PORTA, 0 low
(or high) to illuminate the first digit. You then turn off the PORTA,0
pin and put the data values for the second digit onto PORTB, then turn
on PORTA, 1. Cycle thru PORTA, 2 and PORTA, 3 then back to PORTA, 0.

If you setup say a timer interrupt to occur every 10mS or so, you can
switch digits in the ISR and leave them till the next interrupt 10mS
later. That would update the entire display every 40mS or 25 times per
second. Your eyes will never know the difference and it will only need
11 i/o pins.


This sounds like a fantastic idea *but* of the 40 pins on my display,
the only ones marked on the datasheet are one for every segment/dp on
the screen, plus two "com" (one on each side). I assumed it meant
"common" and grounded it, while connecting the other pins to pic
outputs, and they drive fine. I assume your method isn't useful for this
particular LCD?

Ta

The rest of the pins are probably not connected to anything, but are
there for physical support.

Your digits aren't arranged for multiplexing. Displays which are
arranged for multiplexing have only one group of 7 bits to control all
of the digits, and separate anodes or cathodes for each of the digits.
You set up the data for a digit, then turn it on using the separate
anode or cathode. If you do this fast enough, it looks like they are all
on.

For your device, there are several ways to go. You could use a chip
designed to drive a common cathode LED for each digit. Then, you would
have only 13 bits to control from the PIC, since the high bit is only a
1 or blank.

The easiest way, however, is to go get some serial-in parallel out shift
registers. The one I generally use for PICs is the MC14094, which have
enables, strobes, and can be chained together. You have 28 bits to
control, so you'll need 4 of them. (they have 8 outputs each)

There are 3 PIC pins used to shift data into the things and display it.
You set a data bit either high or low, and then twiddle (0-1-0) a clock
bit to clock it in. Once the bits are all shifted into the devices, you
strobe the data in the shift register to the outputs using a separate
strobe bit.

The clock and strobe pin from the PIC are attached to all of the shift
registers. The data is attached to only the first one. There is a 'shift
out' pin on the shift registers that you attach to the next one in line,
etc.

I would devote a shift register to each digit, just to simplify the
setup. Having a table mapping binary data to 7 segment codes simplifies
matters.

Finally, you can easily get your timing data off of the AC line, if your
clock is meant to be plugged in. It is a nice way to go, since it varies
only a small amount, so your clock is more accurate. If you use the
internal oscillator, it can easily vary by a few percent in either
direction, which will cause your clock to run fast or slow. You can
compensate for this a bit, but temperature also affects the oscillator
in the pic, so the only really good solution is an external oscillator
or crystal.

--
Regards,
Robert Monsen

"Your Highness, I have no need of this hypothesis."
- Pierre Laplace (1749-1827), to Napoleon,
on why his works on celestial mechanics make no mention of God.

 

[Anthony Fremont]

"Danny T" wrote

Anthony Fremont wrote:

57-0160 from rapidelec.co.uk

I found it, but no datasheet.

Datasheet came with it (cos it's not on the web):

http://dantup.me.uk/tmp/datasheet.gif

Bummer, that's it huh? Unfortunately, that doesn't tell us anything
important about how to drive the display other than the pin-out. Maybe
you shouldn't purchase any more surplus LCDs from them. Hitachi based
displays are the common display for tinkering. You can get them in
anything from a 1x8 to a 4 * 80. They are usually as cheap as the one
you have, but have much more utility.

The table in the bottom right is blown up here:

http://dantup.me.uk/tmp/pins.gif


Matrix type LCDs have to be scanned, the pixels can never be allowed
to
see any DC voltage or they will cook. Your display does not appear
to
be in this category. Your display is a very fixed purpose display.
Your display will only display 3 1/2 digits, that means the first
column
can't show all the numbers 0 - 9, only 0-1 or 0-3 depending on the
display.

It'll only do 1 on the first character. I thought maybe it was good
for
clocks (as I'm doing now), but there's no "decent" am/pm indicator,
and
it can't do 24hr, so maybe it's even more useless!

You need to find yourself a nice Hitachi based display. ;-)

http://dantup.me.uk/tmp/wires.jpg

You should see the BASIC-52 computer I made with scads of jumpers
for
the external latches and ram for the 8052. Kinda neat about 3.5"
square
and runs on a 9V battery, just hook up to the serial port, push the
reset button, hit the space bar (or is it return) and it's 1977
again.
;-)

heh, at least it does something - this just lights up a few segments,
and it's got more wire in it than my entire apartment!!


There's a bunch of ways this can be done, but yours wins the Rube
Goldberg award. ;-)

This appears to be the case. If you don't have access to the
cathodes
of each individual segment, then you can't multiplex it in the way I
described. You should be using a Hitachi type LCD display anyway,
or 7
segment LEDs. ;-)

So, given the LCD, and the available hardware, would you agree that my
"Rube Goldberg" clock, is indeed, the best way I could've done it? ;P

Well if you had to make it out of only the parts you used, then ok.
However, if you had a couple of shift registers on hand, you could have
used only one PIC.

The 5 PICs I've used... 4 are just simple registers (cos I don't have
any) like this:

Start
btfsc PORTB, 5 ; If RB5 is high
movf PORTB, W ; Copy input!
movwf PORTA ; Move to output
GOTO Start ; Start again

END

Out of curiosity, why did you chose PORTA to drive the segments and
PORTB to read data in?

And the "driver" I haven't done yet. I know in the code above, if RB5
goes low between the first two instructions, it might not work
properly,

Why do you say that?

How about this:

Start
btfss PORTB, 5 ; If RB5 is low
goto Start ; then no data is available
movf PORTB, W ; Otherwise, copy input!
movwf PORTA ; Move to output
GOTO Start ; Start again
END

it should copy PORTB into a register, then work on it from there -
however, ther's *no way* I'm getting those chips out of those
breadboards with all those wires in (around 80 wires so far, and the
driver chip isn't there), so it can stay for now ;-)

In cases like this, it's ok to just check the port pin without making a
shadow copy of the whole register. It's output pins that you need to be
concerned about the read-modify-write issues.

 

[Anthony Fremont]

"Danny T" <danny@nospam.oops> wrote in message

That said... Only my driving chip would need the crystal, and I do
have

That's right. ;-)

2x4Mhz that I bought a while back (I didn't realise they had internal
ones). Since my driving chip has spare pins (the only one that
does!!),
I might hook it up to that. What's the best way to time something like

this - the only delays I've done so far are done by decrementing a
register and skipping if 0 - I'm sure there's a nicer way to do it?

Er um, not really. There are other ways to do long delays, but I'm not
sure that I'd say they were nicer. ;-) You would probably want to use
a timer and associated interrupt routine to keep accurate track of
elapsed intervals (like seconds for example). That way, your main level
code could go about it's business without worrying about updating the
seconds ticker at the right time.

 

[Danny T]

Anthony Fremont wrote:

Bummer, that's it huh? Unfortunately, that doesn't tell us anything
important about how to drive the display other than the pin-out. Maybe
you shouldn't purchase any more surplus LCDs from them. Hitachi based
displays are the common display for tinkering. You can get them in
anything from a 1x8 to a 4 * 80. They are usually as cheap as the one
you have, but have much more utility.

Yeah - I didn't buy it for any purpose really, was just interested in
seeing how it worked - something extra for debugging output and was
fairly cheap

Well if you had to make it out of only the parts you used, then ok.
However, if you had a couple of shift registers on hand, you could have
used only one PIC.

That's why I programmed 4 pics to work as I understood shift registers
would (I didn't consider serial-in), it's the main driving pic that'll
be the clever stuff
(if I get a clock working quickly, I might add time set / alarm buttons,
like most alarm clocks )

Out of curiosity, why did you chose PORTA to drive the segments and
PORTB to read data in?

For parallel data, I needed 7 outputs (7 segments) and 8 inputs (7
segments plus clock/latch (what's the right word?))

My programmer doesn't like turning MCLR off (internal), so that left me
with 7 I/O pins on one port. I used the same pin on the other port as
the clock/latch, so I could just copy (other 7 bits would be in the
right place). Copying over MCLR doesn't matter since it's ignored.

I didn't have enough room on my breadboard, so I had to fudge it
slightly... I put two chips upside down, with the bottom left 4 pins in
the same rows as the top right 4 of another pic. Then I wired those 4
inputs up the other way, since all intputs are driven from the same 7
outputs of the driving pic, with just the clock (RB5) being wired
seperately.

And the "driver" I haven't done yet. I know in the code above, if RB5
goes low between the first two instructions, it might not work
properly,

Why do you say that?

How about this:

Start
btfss PORTB, 5 ; If RB5 is low
goto Start ; then no data is available
movf PORTB, W ; Otherwise, copy input!
movwf PORTA ; Move to output
GOTO Start ; Start again
END

Thinking about it, if I clock with two instructions, eg:

; Set output pins for char 1
; Clock digit 1
; Clock digit 1 off
; Set output pins for char 2
; Clock digit 2
; Clock digit 2 off

But my worry was, if after your first insutrction (which was RB5 is
high), the driving pic sends RB5 low and then gears the outputs for the
next character. By the time you get to the next instruction (moving
PORTB to W) I might've changed the data. It's what we like to call
"random failure"!

Since it may take two instructions to change the output, it's not a
problem, *BUT* since the 4 "shift registers" are running on internal
clocks, I don't know how accurate they are, and the driving pic could
potentially clock RB5 and change the 7 output pins in between - ?

In cases like this, it's ok to just check the port pin without making a
shadow copy of the whole register. It's output pins that you need to be
concerned about the read-modify-write issues.

What I don't like, is the reading a value, satisfying a condition, then
using a "new" copy of the data, which might not satisfy the criteria.
It's assuming that the data doesn't change between instructions, which,
given the data is provided externally, is entirely possible!

--
Danny

 

[Danny T]

Anthony Fremont wrote:

I'm bad about not finishing my projects all the way. I breadboard them
up, tinker with them till they work and then get bored and move on to
something else. I'm going to solder up my clock listening project since
I actually have some use for that. ;-)

What's that do?

I'm the same with software... I've written about 30,000 "personal"
websites, and none of them ever make it to the web, because by the time
I've finished, I've thought of a better way to do it... It's good for
learning, but gets me a reputation!! I've decided if I can do this clock
properly (replace these 4 pics with cheap shift registers or something)
with alarm, I might start using it - just because I can!

For parallel data, I needed 7 outputs (7 segments) and 8 inputs (7
segments plus clock/latch (what's the right word?))

On your slave PICs you might consider it to be a "chip enable" pin, or
even a "read".

I meant in a more general sense. From looking at shift registers, they
seemed to have clock and latch - clock seemed to be to set data (for
serial use), and latch was to move the collected input to the output
pins... I guess mine's a combi!

The reason I ask is that the RA4 pin is an open collector when used as
output. This means it needs a pullup resistor when used as an output
pin. Therefore, you'll see allot of it being used as an input pin
whenever possible. It's also useful for talking to Dallas 1-wire
devices. ;-)

Hmmm, I wasn't aware of this - and everything seems to work without a
resistor. What are the implications - what difference would I see in
high/low with and without an external resistor?

You have to give time for the slave PIC to "see" the data. If your
slave PIC has a worst case timing of say 10 cycles to recognize its
"enable" pin and retreive the data, then the master PIC has to allow at
least that much time every time it presents a digit. Then you wont have
random failures.

I'm not sure what you mean by "new" copy of the data.

As well as holding the "enable" pin for 10 cycles, to be safe (if it
where 10), I'd also have to hold the "enable" pin low while maintaining
the same data to be "safe". Imagine if I hold the enable pin high for
100 cycles, we know my chip has read the data successfully, so I then
drop *all* pins down to 0. Since my "shift register" is running very
quickly, all it takes is for this moment (when all pins go low) to be
between the "is enable pin high" and "move input to output" and 0h would
be copied to my output!

Does that make sense?

--
Danny

 

[Danny T]

Anthony Fremont wrote:

Don't forget the caps to ground, or it wont start. It's only recently
that I started using the internal osc. It's actually getting to be
fairly usable as the new parts come along. A 16F628 I'm playing with
right now is only fast by about 3.5% according to my 15 year old
frequency counter. This is actually convenient for me since I can use
Timer0 with a prescaler of 4 and get interrupts at almost exactly 1mS
intervals (instead of 1.024mS) without having to reload it every
interrupt.

Yep, I just popped out to get caps, realising I didn't have any small
enough... Those I came back with (a lucky bag!) include 10pF and some
that I believe are 15pF (they're brown, unlike most of my small blue
ones!) and have "15J" written on them. The datasheet says 15pF are fine,
though that's not optimised, and I've seen other quotes of 10pF. If the
datasheet isn't clear, how am I supposed to know which is best?

And while we're on the subject, can someone please explain capacitors to
me... I've been reading The Art of Electronics, and gotten confused. As
I understood (before and after reading), caps hold charge (like a
buffer?)... I guessed that the cap recommended across Vdd and Vss on my
pic just "swallowed" up any little spikes, and sent them back to ground,
rather than through the pic. What would a cap on each leg of the crystal
do - to me, it looks like the whole thing would just go to ground
(They're very very small caps!) and the pin would see hardly anything?
Do I misunderstand?

Well, it's not quite that straightforward. You usually count a bunch of
short intervals (like milliseconds) and then do something important when
1000 have gone by. A common housekeeping interrupt loop time is 10mS.
Every 100 interrupts you could add one to a seconds counter. Timer2 is
real good at this kind of stuff, but I like to use it for other things.
Timer0 is kinda weak (only 8 bits), but it's handy. ;-)

Sounds fair enough - my only worry now, is getting into the realms of
"threading"... Like the "random" failure I described before - not having
anything in my code assuming a register x instructions further up holds
the same value, since an interrupt may have fired in between and changed
it!!

Btw, is 4Mhz 4 million instructions per second? Guess I need to make

No, it's 1 million instructions per second. The clock is divided by 4
as every instruction cycle consists of 4 Q states. 4MHz is a nice clock
speed because every (single cycle) instruction takes 1uS to execute.

Right, even easier to remember!

When an interrupt occurs, the GIE flag is cleared. This prevents the
scenario you described. When the ISR returns, it uses a retfie
instruction which sets the GIE bit again so that another interrupt can
occur. If you forget to clear the flag for the interrupt that you just
processed, then you'll be processing it again as soon as you execute the
retfie. ;-) This is a common mistake for newbies.

I read about that... I'm sure I won't make that mistake...
(well, I won't post it here when I do, at least ;-))

--
Danny

 

[Anthony Fremont]

"Danny T" <danny@nospam.oops> wrote in message
news:41ea6be5$0$73995$ed2619ec@ptn-nntp-reader03.plus.net...

Anthony Fremont wrote:

I'm bad about not finishing my projects all the way. I breadboard
them
up, tinker with them till they work and then get bored and move on
to
something else. I'm going to solder up my clock listening project
since
I actually have some use for that. ;-)

What's that do?

It listens to a pendulum clock ticking and measures the time between the
ticks and tocks. I've got it working pretty well right now. It's got
two LEDs that ping-pong in sync with the tick-tock for a visual
reference that it's working. It also prints the time between beats to
an LCD for balancing the beat. I'm going to have it calculate the
number of beats per hour to help speed up pendulum length adjustments.
I have one old clock that keeps time with an accuracy of a few seconds
per week. Not bad for something on the order of 125 years old, huh?

I'm going to solder it up and add support for an optical detector or
two. I'm basically making something similar to this: (not for sale,
just for me ;-)
http://www.bmumford.com/microset.html
I collect old clocks, most of which don't work when I get them,
otherwise I couldn't afford them. Proper tools are hard to come by and
usually quite expensive. Brian's device is quite sophisticated and well
worth what he wants for it, but it's too expensive and too much of a
luxury for my blood. I don't need all the features, just a couple would
be nice. The ability to count the beats in one revolution of the minute
hand would be a huge timesaver for fitting a new pendulum, that's where
the optical sensor comes in. You just let the clock tick off an hour
(takes about 5 minutes with no pendulum attached) while you count the
number of ticks (optically or acoustically). This gives you the beats
per hour for that particular movement (timepiece). You then fit a
pendulum and adjust it in real time while looking at a real time beats
per hour display. Finally, adjust the length until it's right on with
what was calculated earlier. A job that used to consume days of trial
and error tinkering can now be done way less than two hours.

You should check out the rest of his website as he has some interesting
information about timekeeping in general, including studies he did of AC
mains frequency accuracy.

I'm the same with software... I've written about 30,000 "personal"
websites, and none of them ever make it to the web, because by the
time
I've finished, I've thought of a better way to do it... It's good for
learning, but gets me a reputation!! I've decided if I can do this
clock
properly (replace these 4 pics with cheap shift registers or
something)
with alarm, I might start using it - just because I can!

Yeah, it's kinda neat to actually be able to use your projects.

For parallel data, I needed 7 outputs (7 segments) and 8 inputs (7
segments plus clock/latch (what's the right word?))

On your slave PICs you might consider it to be a "chip enable" pin,
or
even a "read".

I meant in a more general sense. From looking at shift registers, they
seemed to have clock and latch - clock seemed to be to set data (for
serial use), and latch was to move the collected input to the output
pins... I guess mine's a combi!

From the receiving point of view, CLOCK tells you when to look at the
data line for valid information. You could think of your RB5 pin as a
latch pin since it tells the slave pick when to capture the information.

The reason I ask is that the RA4 pin is an open collector when used
as
output. This means it needs a pullup resistor when used as an
output
pin. Therefore, you'll see allot of it being used as an input pin
whenever possible. It's also useful for talking to Dallas 1-wire
devices. ;-)

Hmmm, I wasn't aware of this - and everything seems to work without a
resistor. What are the implications - what difference would I see in
high/low with and without an external resistor?

Without the pull-up resistor, the pin can't actively drive anything.
IOW, it can't put out +5V. It can only act as a current sink. It may
be that the segment you have it connected to doesn't draw any
significant current (very likely) and that the pin floats high enough to
make it happy. It would never be able to supply enough +5V juice to
turn on an LED.

You have to give time for the slave PIC to "see" the data. If your
slave PIC has a worst case timing of say 10 cycles to recognize its
"enable" pin and retreive the data, then the master PIC has to allow
at
least that much time every time it presents a digit. Then you wont
have
random failures.

I'm not sure what you mean by "new" copy of the data.

As well as holding the "enable" pin for 10 cycles, to be safe (if it
where 10), I'd also have to hold the "enable" pin low while
maintaining
the same data to be "safe". Imagine if I hold the enable pin high for
100 cycles, we know my chip has read the data successfully, so I then
drop *all* pins down to 0. Since my "shift register" is running very
quickly, all it takes is for this moment (when all pins go low) to be
between the "is enable pin high" and "move input to output" and 0h
would
be copied to my output!

Does that make sense?

Yes, that's why you need a data hold time. This is the time spent
continuing to present valid data on the port even after you bring the
enable pin low. As long as it's a predictable value, the slave PIC can
safely accept data from the master without worry. You'll see this value
specified in applicable datasheets where data is being exchanged via
I2C, SPI, etc...

 

[Danny T]

Anthony Fremont wrote:

It listens to a pendulum clock ticking and measures the time between the
ticks and tocks. I've got it working pretty well right now. It's got
two LEDs that ping-pong in sync with the tick-tock for a visual
reference that it's working. It also prints the time between beats to
an LCD for balancing the beat. I'm going to have it calculate the
number of beats per hour to help speed up pendulum length adjustments.
I have one old clock that keeps time with an accuracy of a few seconds
per week. Not bad for something on the order of 125 years old, huh?
snip

Sounds interesting, though I'm an 80s child, so I'd probably rig the
clock to be controlled by something digital and leave the pendulum for
show ;-)

Without the pull-up resistor, the pin can't actively drive anything.
IOW, it can't put out +5V. It can only act as a current sink. It may
be that the segment you have it connected to doesn't draw any
significant current (very likely) and that the pin floats high enough to
make it happy. It would never be able to supply enough +5V juice to
turn on an LED.

I see - so if I noticed the segments attached to those pins didn't
light, putting a resistor between 5V and the pins would correct it?

What would be the correct (or possible) ways to attach an LED to this
port? Would it just a resistor from +5V to the pin, connected to the
LED, or would it make more sense to attach the LED from +5V to the pin,
and let it sink? Does the chip need to be told if it's sinking or
sourcing, since I imagine they'd need to be hooked up rather differently?

Does that make sense?


Yes, that's why you need a data hold time. This is the time spent
continuing to present valid data on the port even after you bring the
enable pin low. As long as it's a predictable value, the slave PIC can
safely accept data from the master without worry. You'll see this value
specified in applicable datasheets where data is being exchanged via
I2C, SPI, etc...

Excellent, I was worried the electronics world was pumping out dodgey
electronics for a while then! Though I do find it strange this value is
specified, rather than the "reading" component reading data off into a
buffer, then processing from there - this way it's always perfect. We
only update *if* the clock is on, with the data we *know* was present
with the clock

--
Danny

 

[Anthony Fremont]

"Danny T" <danny@nospam.oops> wrote in message
news:41ea6de1$0$47684$ed2619ec@ptn-nntp-reader02.plus.net...

Anthony Fremont wrote:

Don't forget the caps to ground, or it wont start. It's only
recently
that I started using the internal osc. It's actually getting to be
fairly usable as the new parts come along. A 16F628 I'm playing
with
right now is only fast by about 3.5% according to my 15 year old
frequency counter. This is actually convenient for me since I can
use
Timer0 with a prescaler of 4 and get interrupts at almost exactly
1mS
intervals (instead of 1.024mS) without having to reload it every
interrupt.

Yep, I just popped out to get caps, realising I didn't have any small
enough... Those I came back with (a lucky bag!) include 10pF and some
that I believe are 15pF (they're brown, unlike most of my small blue
ones!) and have "15J" written on them. The datasheet says 15pF are
fine,
though that's not optimised, and I've seen other quotes of 10pF. If
the
datasheet isn't clear, how am I supposed to know which is best?

The ones that are best will be the ones that make your crystal oscillate
at exactly the right frequency, and start-up every time you apply power.
;-) You will probably want to use two 22pF ceramic caps.

And while we're on the subject, can someone please explain capacitors
to
me... I've been reading The Art of Electronics, and gotten confused.
As
I understood (before and after reading), caps hold charge (like a
buffer?)... I guessed that the cap recommended across Vdd and Vss on
my
pic just "swallowed" up any little spikes, and sent them back to
ground,
rather than through the pic. What would a cap on each leg of the
crystal
do - to me, it looks like the whole thing would just go to ground
(They're very very small caps!) and the pin would see hardly anything?
Do I misunderstand?

Very small caps are best at passing thru only the highest freqencies.
Glitches on the power line are usually at quite high frequencies. And
yes some of your oscillator is being leaked to ground. It's ok,
otherwise the crystal might fracture under the stress of too much
feedback.

Well, it's not quite that straightforward. You usually count a
bunch of
short intervals (like milliseconds) and then do something important
when
1000 have gone by. A common housekeeping interrupt loop time is
10mS.
Every 100 interrupts you could add one to a seconds counter. Timer2
is
real good at this kind of stuff, but I like to use it for other
things.
Timer0 is kinda weak (only 8 bits), but it's handy. ;-)

Sounds fair enough - my only worry now, is getting into the realms of
"threading"... Like the "random" failure I described before - not
having
anything in my code assuming a register x instructions further up
holds
the same value, since an interrupt may have fired in between and
changed
it!!

Well, the interrupt routine must not save and restore the W, STATUS and
possibly FSR and PCLATH when it executes. Otherwise things go to pieces
in a big hurry. Preventing "collisions" between the ISR and main level
is not that hard.

Btw, is 4Mhz 4 million instructions per second? Guess I need to make

No, it's 1 million instructions per second. The clock is divided by
4
as every instruction cycle consists of 4 Q states. 4MHz is a nice
clock
speed because every (single cycle) instruction takes 1uS to execute.

Right, even easier to remember!


When an interrupt occurs, the GIE flag is cleared. This prevents
the
scenario you described. When the ISR returns, it uses a retfie
instruction which sets the GIE bit again so that another interrupt
can
occur. If you forget to clear the flag for the interrupt that you
just
processed, then you'll be processing it again as soon as you execute
the
retfie. ;-) This is a common mistake for newbies.

I read about that... I'm sure I won't make that mistake...
(well, I won't post it here when I do, at least ;-))

Yeah you will, you just won't know that's what's happening. You will be
certain that the processor is not executing instructions properly. ;-)

 

[Danny T]

Anthony Fremont wrote:

The ones that are best will be the ones that make your crystal oscillate
at exactly the right frequency, and start-up every time you apply power.
;-) You will probably want to use two 22pF ceramic caps.

Grrr...!

*looks in bag*

Why the hell can't they label caps properly?! My 100n caps are labelled
"10", and the 1u are labelled "105"... Is there a nice big table
somewhere that'll tell me all the possible things 22pF caps could be
labelled as? (and why did you say 22?)

Very small caps are best at passing thru only the highest freqencies.
Glitches on the power line are usually at quite high frequencies. And
yes some of your oscillator is being leaked to ground. It's ok,
otherwise the crystal might fracture under the stress of too much
feedback.

Right

Well, the interrupt routine must not save and restore the W, STATUS and
possibly FSR and PCLATH when it executes. Otherwise things go to pieces
in a big hurry. Preventing "collisions" between the ISR and main level
is not that hard.

Check my code in a.m.8bit - doesn't seem to work :-(

I read about that... I'm sure I won't make that mistake...
(well, I won't post it here when I do, at least ;-))

Yeah you will, you just won't know that's what's happening. You will be
certain that the processor is not executing instructions properly. ;-)

I'm certain it's not, but I am using RETFIE and clearing my interrupt
flag first

--
Danny

 

[Danny T]

Danny T wrote:

The ones that are best will be the ones that make your crystal oscillate
at exactly the right frequency, and start-up every time you apply power.
;-) You will probably want to use two 22pF ceramic caps.

Grrr...!

*looks in bag*

Why the hell can't they label caps properly?! My 100n caps are labelled
"10", and the 1u are labelled "105"... Is there a nice big table
somewhere that'll tell me all the possible things 22pF caps could be
labelled as? (and why did you say 22?)

I was wrong, they're 104 (100n) and 105 (1u). Those marked 10 are 10pF.
I *think* those marked 15J are 15pF. I've also got them marked...

102J COG63
6n8S
8
33n
33n
47nS 32V
n56
68j
8.2

Nice and consistant

Btw, you said the best ones makr my crystal accurate - does this mean if
my clock loses time, I need to change the caps? Can you tell which
direction? (eg. if my clock loses a minute a day, what do I do?)

--
Danny

 

[Anthony Fremont]

"Danny T" <danny@nospam.oops> wrote in message
news:41ea841e$0$45524$ed2e19e4@ptn-nntp-reader04.plus.net...

Anthony Fremont wrote:

It listens to a pendulum clock ticking and measures the time between
the
ticks and tocks. I've got it working pretty well right now. It's
got
two LEDs that ping-pong in sync with the tick-tock for a visual
reference that it's working. It also prints the time between beats
to
an LCD for balancing the beat. I'm going to have it calculate the
number of beats per hour to help speed up pendulum length
adjustments.
I have one old clock that keeps time with an accuracy of a few
seconds
per week. Not bad for something on the order of 125 years old, huh?
snip

Sounds interesting, though I'm an 80s child, so I'd probably rig the
clock to be controlled by something digital and leave the pendulum for
show ;-)

I always wanted to put a pic, a lithium battery, a hall sensor (or MEMS
accelerometer to be really cool) and a column of LEDs into a pendulum
bob. Then the swinging column of LEDs could strobe out the date/time in
a format suitable for people that have problems with analog dials and
hands. ;-) I really have to get this done.

Without the pull-up resistor, the pin can't actively drive anything.
IOW, it can't put out +5V. It can only act as a current sink. It
may
be that the segment you have it connected to doesn't draw any
significant current (very likely) and that the pin floats high
enough to
make it happy. It would never be able to supply enough +5V juice to
turn on an LED.

I see - so if I noticed the segments attached to those pins didn't
light, putting a resistor between 5V and the pins would correct it?

Yes, you would pick your resistor size so that enough current could be
supplied to the device being switched on and off.

What would be the correct (or possible) ways to attach an LED to this
port? Would it just a resistor from +5V to the pin, connected to the
LED, or would it make more sense to attach the LED from +5V to the
pin,
and let it sink? Does the chip need to be told if it's sinking or
sourcing, since I imagine they'd need to be hooked up rather
differently?

You can do it either way you prefer. Many CMOS parts are better at
sinking current than sourcing it, but the PICs have the same limit
either way (usually 25mA per pin)

When the PIC is outputing a 0, then it is actively driving the pin low
and can sink current. When it is outputing a 1, it is actively driving
the pin high (except RA4) and can source current. If you hook two PICs
together and try to have a dualing outputs contest, one of the pins will
not survive. Always use a current limiting resistor between pins that
might try to do this.

Does that make sense?


Yes, that's why you need a data hold time. This is the time spent
continuing to present valid data on the port even after you bring
the
enable pin low. As long as it's a predictable value, the slave PIC
can
safely accept data from the master without worry. You'll see this
value
specified in applicable datasheets where data is being exchanged via
I2C, SPI, etc...

Excellent, I was worried the electronics world was pumping out dodgey
electronics for a while then! Though I do find it strange this value
is
specified, rather than the "reading" component reading data off into a
buffer, then processing from there - this way it's always perfect. We
only update *if* the clock is on, with the data we *know* was present
with the clock

The hold time is just to give the receiving device enough time to detect
the clock and get the data. The data is held on the output device for a
small (but specified) period of time so that the window of opportunity
that you are concerned about gets closed.

 

[Anthony Fremont]

Danny wrote:

I was wrong, they're 104 (100n) and 105 (1u). Those marked 10 are
10pF.
I *think* those marked 15J are 15pF. I've also got them marked...

102J COG63
6n8S
8
33n
33n
47nS 32V
n56
68j
8.2

Nice and consistant

Btw, you said the best ones makr my crystal accurate - does this mean
if
my clock loses time, I need to change the caps? Can you tell which
direction? (eg. if my clock loses a minute a day, what do I do?)

If your clock was losing a minute per day, then you would likely need to
fix the bug in your code. ;-) If, however, the crystal was running
slow and you were losing a few seconds per day, that would mean you have
too much capacitance. IOW, the bigger the caps the slower the crystal
will run (to a point).

 

[Danny T]

Anthony Fremont wrote:

It wouldn't hurt for you to do that (1k should work fine), but it's
important when you have pins that flip from being input to output on the
fly when trying to communicate bidirectionally. Eventually something
leads to things being out of sync and then you have battling outputs.
When one pin is *outputting* a 1 and the the other is *outputting* a 0,
it's a short circuit.

I see. I'll leave bi-directional stuff for now ;-)

--
Danny

 

[Danny T]

Anthony Fremont wrote:

They usually have the cryptic value of "22" printed on them, plus the
size is kind of a giveaway. ;-) I said 22, because that's what I've
always used and it works. But a better reason would be that the
datasheet calls for 15 to 33pF of capactance for each cap. The real
determining factor is whatever the crystal manufacturer calls for to
bring the crystal to the right frequency. 22pF works pretty well in
practice. It's only really critical when you are trying to keep
precision time over a long period.

That's fine then... If, over a year, I start getting into work later and
later, I think I can live with that

What did you say - bigger caps mean work later?

Check my reply, you need to make changes. ;-)

Thanks, but I've managed to still do it wrong 0

I'm certain it's not, but I am using RETFIE and clearing my interrupt
flag first

Your code looks ok in this respect.

You're likely reading it wrong ;-)

--
Danny

 

[John Fields]

On Sun, 16 Jan 2005 10:09:24 +0000, Danny T <danny@nospam.oops> wrote:

John Fields wrote:

You have what's called a "static" display, and the pins marked "com"
are connected to the backplane, which is the transparent electrode
which forms one side of the capacitor comprising each segment and the
backplane. MOST static LCD displays aren't designed to be driven by
DC, and what will happen is that the ITO will plate out of either the
backplane or the segment and migrate to the opposite electrode, with
the eventual result that the capacitor will be destroyed and the digit
will become unreadable. The proper way to drive static LCDs is with
square wave AC; the backplane and the segment being driven in phase
when the segment isn't supposed to be displayed, and out of phase when
it is, like this for the segment to be off:

__ __ __ __ __ __
SEGOFF__| |__| |__| |__| |__| |__|

__ __ __ __ __ __
BP __| |__| |__| |__| |__| |__|


and like this for it to be on:

__ __ __ __ __ __
SEGON |__| |__| |__| |__| |__| |__

__ __ __ __ __ __
BP __| |__| |__| |__| |__| |__|


This task _can_ be accomplished with a ľC and a longish shift register
By EXORring the backplane and the segments at about 30Hz., but it's
often done with a device like a National MM5483 so all you have to do
is shift data into it and strobe the output registers without any
extra software overhead.

http://cache.national.com/ds/MM/MM5483.pdf

If you've got a 3-1/2 digit seven-segment display, that's 23 segments,
and the 5483 can drive 32 segments and a backplane, so that leaves you
with nine extra segment drivers for decimal points, annunciators, or
the colon if you're doing a clock. Best of all, Digi-Key's got them
in 40-pin DIP packages for about five bucks.

I see (oops)... What I don't understand though, if "com" is for the
backplane - what about ground? :-\

---
There _is_ no hard ground required, it's like this:

INn------------------------------------------+
|
INb----------------------+ |
| |
INa---+ | |
| | |
+--A +--A +--A
EXOR Y------+ EXOR Y------+ EXOR Y------+
INBP>-+--B | +--B | +--B |
| | | | | |
+------------|-----+------------|------+ |
|COM a| b| n|
+-|------------|------------------|-------------------|----+
| | | | | |
| | [SEGa] [SEGb] [SEGn] |
| | | | | |
| +------------+------------------+---------//--------+ |
| DISPLAY GLASS |
+----------------------------------------------------------+

Where the EXORs are part of the external drive circuitry, the "DISPLAY
GLASS" is the display itself, and SEGa, SEGb, and SEGn represent the
inherent capacitances between the various segment electrodes and the
backplane.

--
John Fields