Maker Pro
Maker Pro

LCD controlling with comparators

D

Danny T

Jan 1, 1970
0
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?
 
A

Anthony Fremont

Jan 1, 1970
0
Danny T said:
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.
 
D

Danny T

Jan 1, 1970
0
CBarn24050 said:
Sounds like your driving your lcd with dc, it wont last long.
Whoops?



An lcd controller chip, find 1 to mach your display.

heh. I meant without using something like that - let's say I'd invented
my own 13 segment display for a petrol gauge on my car or something! :p
 
D

Danny T

Jan 1, 1970
0
Anthony said:
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
 
A

Anthony Fremont

Jan 1, 1970
0
Danny T said:
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.

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.
;-)
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. ;-)
 
R

Robert Monsen

Jan 1, 1970
0
Danny said:
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




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.
 
J

John Fields

Jan 1, 1970
0
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



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?

---
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.
 
D

Danny T

Jan 1, 1970
0
Anthony said:
I found it, but no datasheet.

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

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

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 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!!

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

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

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,
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 ;-)
 
D

Danny T

Jan 1, 1970
0
Robert said:
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.

This is essentially what I did, I've made 4 PICs control the 4 digits (I
don't have any shift registers, and couldn't find any on maplin or Rapid
- am I searching for the wrong thing?!)

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.

I considered this, but it was really just something to keep me busy
until wheels and op-amps come for my robot. It'll be taken apart soon -
I just wanted to check my understanding of assembly programming a little
more, and wanted something to do with the bits I have (Even if you can
buy bits to do this stuff already!) :)

That said... Only my driving chip would need the crystal, and I do have
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?

Ta
 
D

Danny T

Jan 1, 1970
0
John said:
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? :-\
 
A

Anthony Fremont

Jan 1, 1970
0
"Danny T" wrote
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



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. ;-)
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!!




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.
 
A

Anthony Fremont

Jan 1, 1970
0
Danny T said:
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.
 
D

Danny T

Jan 1, 1970
0
Anthony said:
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.

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! :(
 
D

Danny T

Jan 1, 1970
0
Anthony said:
That's right. ;-)

:)

I've not used them before, but I'm sure even I can manage this one...
Connect the crystal to two pins and set the config to use it as per the
datasheet!

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.

That sounds a bit better - so I can get a routine to run every second
accurately, without having to subtract one from my "waitAsecond" routine
every time I add a new instruction? ;-)

Btw, is 4Mhz 4 million instructions per second? Guess I need to make
sure my code (eventually checking for time set buttons, alarm etc.)
doesn't run for more than this time, else my timer interupt will
interupt itself, and then I'll probably get stack overflows (or improper
functioning at least!)
 
A

Anthony Fremont

Jan 1, 1970
0
Danny T said:
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 :)



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 :))

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. ;-)
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".
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.

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. ;-)
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 - ?

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.
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! :(

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

Anthony Fremont

Jan 1, 1970
0
Danny T said:
:)

I've not used them before, but I'm sure even I can manage this one...
Connect the crystal to two pins and set the config to use it as per the
datasheet!

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.
That sounds a bit better - so I can get a routine to run every second
accurately, without having to subtract one from my "waitAsecond" routine
every time I add a new instruction? ;-)

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. ;-)
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.
sure my code (eventually checking for time set buttons, alarm etc.)
doesn't run for more than this time, else my timer interupt will
interupt itself, and then I'll probably get stack overflows (or improper
functioning at least!)

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.
 
D

Danny T

Jan 1, 1970
0
Anthony said:
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! :)

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?
 
D

Danny T

Jan 1, 1970
0
Anthony said:
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!!

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 ;-))
 
Top