LCD controlling with comparators

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

Posted by Danny T on January 16, 2005, 1:06 pm

Please log in for more thread options

Robert Monsen wrote:

> 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

--
Danny

Posted by Anthony Fremont on January 16, 2005, 2:05 pm

Please log in for more thread options

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

Posted by Danny T on January 16, 2005, 2:13 pm

Please log in for more thread options

Anthony Fremont wrote:

>>That said... Only my driving chip would need the crystal

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

Posted by Anthony Fremont on January 16, 2005, 3:19 pm

Please log in for more thread options

> Anthony Fremont wrote:
>

> >>That said... Only my driving chip would need the crystal

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

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.

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

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.

Similar Threads	Posted
LCD controlling with comparators	January 15, 2005, 6:50 pm
Magnitude Comparators	December 7, 2007, 5:40 am
Connect two comparators' output together..	January 23, 2006, 10:58 pm
What is the benefit with comparators that have a Hysteresis pin?	May 18, 2008, 3:20 pm
Controlling 12V from 5V	June 29, 2005, 3:35 pm
controlling	April 10, 2007, 6:25 am
controlling many switches from the PC	December 2, 2004, 6:46 am
op amp controlling a mosfet	July 18, 2006, 1:20 pm
Controlling hundreds of LEDs	December 21, 2004, 8:41 pm
Controlling a motor with a transistor and a PIC	June 7, 2006, 11:14 pm
Re: Controlling a relay via cellular phone.....	July 12, 2006, 6:23 pm
Re: Controlling a relay via cellular phone.....	July 12, 2006, 7:03 pm
Re: Controlling a relay via cellular phone.....	July 12, 2006, 8:50 pm
controlling 2 stepper motors along x and y axis	September 11, 2006, 1:03 pm
controlling dc motor direction (help a newbie, please)	October 28, 2006, 2:09 am

Hobby Electronics Basics LCD controlling with comparators