Searching \ for '7 segment display HELP' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=segment+display
Search entire site for: '7 segment display HELP'.

Truncated match.
PICList Thread
'7 segment display HELP'
1998\07\02@105832 by Glendon Turner

flavicon
face
Thank you in advance for reading this and hopefully helping me.

I need to us a 16F84-04 to drive a 3 or 4 digit 7 segment display (common
annode or cathode, doesn't matter).

I need to be able to send a serial number to the chip (9600,8,N,1) in the
range of 0 to 9999 and have it display it. I think interrupts will be
required because the display needs to be multiplexed and at the same time
needs to check for serial data.

Not sure on this one. If you can offer any help, I would be very grateful.


Kind regards
Glendon Turner

1998\07\02@120615 by andre

flavicon
face
Glendon:
you have to be more specific.
do you want to know more about

1. serial routine
2. led display multiplexing
3. interrupt

Andre  Abelian



Glendon Turner wrote:

{Quote hidden}

1998\07\02@121034 by Peter L. Peres

picon face
On Fri, 3 Jul 1998, Glendon Turner wrote:

> Thank you in advance for reading this and hopefully helping me.
>
> I need to us a 16F84-04 to drive a 3 or 4 digit 7 segment display (common
> annode or cathode, doesn't matter).
>
> I need to be able to send a serial number to the chip (9600,8,N,1) in the
> range of 0 to 9999 and have it display it. I think interrupts will be
> required because the display needs to be multiplexed and at the same time
> needs to check for serial data.

At 4 MHz there is enough time available to do 9600 Baud Rx and display
multiplexing by polling only. imho an F84 is overkill for this, it should
be a C54.

Peter

1998\07\02@125616 by STEENKAMP [M.ING E&E]

flavicon
picon face
Hi,

>
> I need to us a 16F84-04 to drive a 3 or 4 digit 7 segment display (common
> annode or cathode, doesn't matter).
>
> I need to be able to send a serial number to the chip (9600,8,N,1) in the
> range of 0 to 9999 and have it display it. I think interrupts will be
> required because the display needs to be multiplexed and at the same time
> needs to check for serial data.
>
> Not sure on this one. If you can offer any help, I would be very grateful.
>

I would recommend doing the serial receive under interrupt control and
the display multiplexing in your main code.  The serial receive code
needs the precise timing that the interrupt can offer while the display
code timing is not that critical.  You could maybe put the display code
in the interrupt section as well, but I always try to make Interrupt
routines as small as possible - If you don't have to do it under
interrupt control, then don't.

I would connect the serial receive line to RB0 and set it up to cause an
interrupt in the falling edge of the line.  This would be used to
indicate the start bit.  I would then setup the timer 0 to cause
interrupts every 1/9600 of a second.  The first timer 0 interrupt would
then be in the first data bit (D7).  The next interrupt will be in D6 and
so on.  After you have received all the data bits you disable the timer 0
interrupt. (You might want to check the stop bit as well).  Graphically
it would look like this:

      A   B                    C  D
--------  ----        ----  ------------
      |  |  |        |  |  |
      |  |D7|D6 D5 D4|D3|D2|D1 D0
      ----  ----------  ----

A - Falling edge causes external interrupt.  Disable external interrupt
and enable timer 0 interrupts.  Set timer 0 to cause interrupt in the
middle of next bit (D7).
B - First timer 0 interrupt.  Sample the receive line.
C - Last (or second last if you want to check the stop bit) timer 0
interrupt.  Sample the receive line.  Now you have the complete byte.
D - If you want to check the stop bit, this will be the last timer 0
interrupt. Make sure the receive line is high.

Now disable the timer 0 interrupt and re-enable the external interrupt.
You are ready now for the next byte.

Note: The bits should be sampled in the middle of the bit time for best
drift and jitter immunity.  Using a 3.6864MHz Xtal, you can get the
correct period by using no prescaler and setting bits 5 and 7 of the
timer 0 each interrupt.  This will cause the timer to count from 160 up to
255 and roll over to 0 each time.  This gives a period of 96 instruction
cycles, which is what you need (3686400/4/9600 = 96 = 256-160)


As you receive a new bytes write then into global variables and if you
have reveived a complete number to display, set a flag.  The display
routine in your main program will check the flag and if set, load the new
number into the variables being displayed.

The display routine would simply sit in a loop and display one after the
other digit (keep the update rate above 50Hz for the whole display).  The
interrupts in the back while receiveing characters will influence your
timing a bit, but it should not be noticable.


Hope this helps.
Niki

1998\07\02@150020 by Mike Keitz

picon face
On Fri, 3 Jul 1998 00:43:42 +1000 Glendon Turner
<spam_OUTAussiegliderTakeThisOuTspamBIGPOND.COM> writes:
>Thank you in advance for reading this and hopefully helping me.
>
>I need to us a 16F84-04 to drive a 3 or 4 digit 7 segment display
>(common
>annode or cathode, doesn't matter).
>
>I need to be able to send a serial number to the chip (9600,8,N,1) in
>the
>range of 0 to 9999 and have it display it. I think interrupts will be
>required because the display needs to be multiplexed and at the same
>time
>needs to check for serial data.

There are lots of ways to do this application.  It's very doable without
interrupts, but you'll have to program carefully to keep all the timing
right.  I'd use a timer interrupt at 9600 Hz which samples the serial
input and multiplexes the LEDs.  The main program examines the data
received and formats it for display.  Every time a start bit comes in,
the timer would be reset so the interrupts are in the proper phase to
sample the data bits.  This could be done with a external interrupt or in
the main program.  The main program won't be doing anything while waiting
for a start bit.  Changing the phase rather than starting and stopping
the interrupt will keep the display miltiplexing almost consistent so
incoming data won't make the display flicker.

_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]

1998\07\03@022402 by Dr. Imre Bartfai

flavicon
face
Hi,

I have another idea; I'm not sure it will solve your problem, but maybe it
is a contribution.

I had to develop an universal 4-digit 7-segment terminal for different
applications with the same interface. I did it a following manner:

I took a 16F84 (in some cases it proved as too small; then take a 16C622
or 16C558), and 4 pieces of 74164. The latter are daisy-chained, so I need
only the following wires to communicate with the PIC:

- a CLOCK line
- a DATA line
- a RESET line (not important, can be fixed!)
- and...

If the display changes, it leads to some flicker. If it is undesirable, I
took ONE transistor to control the common cathode of ALL digits, and this
transistor is controlled with PIC. And what is very fine here:
- no multiplexing
- speed is incredible
- the display is done with a single SEROUT command of the PicBasic PRO.

On the receiving side I don't deal with interrupts. Instead, I use
hardware handshake like CTS. Of course, it needed some time to set up the
conversion table.

I built some intelligency in my terminal: it is controlled by escape
sequences, so I can control how to interpret the data, e. g.

1 letter + 3 digit
1 letter + 1 byte to be rescaled to 0..999
all characters
all hex data
etc.

Imre


On Thu, 2 Jul 1998, Mike Keitz wrote:

{Quote hidden}

1998\07\03@122730 by Michael S. Hagberg

flavicon
face
is this all the pic is going to do?
if you are going to do the display mux with the pic, then MOST of the time
the pic will be in delay loops. use these loops to check for the serial data
start bit then go off and receive the data. the amount of time it takes to
receive the data will not effect the display. if you have problems seeing
the start bit and getting to the receive routine you could send a dummy (hex
00) character before the serial number and ignore this character in the pic.

michael

{Original Message removed}

1998\07\03@150408 by Claudio Rachiele IW0DZG

flavicon
face
                  Status Distribution July 02, 1998 18:57:05

The message regarding "Re: 7 segment display HELP" sent on July 02, 1998 18:57:05 was sent by

Status Recipient
         Type                To
         Native Name         PICLISTspamKILLspamMITVMA.MIT.EDU
         Foreign Native Name .....PICLISTKILLspamspam.....MITVMA.MIT.EDU\n\n\nINTERNET



Recipients

Status Reporters
         Type                From
         Initials            CR
         Name Domain         NOTES
         Native Name         CN=Claudio Rachiele IW0DZG/OU=Italy/O=IBM@IBMIT
         Foreign Native Name CN=Claudio Rachiele IW0DZG/OU=Italy/O=IBM\nIBMIT\n\n
         Organization        IBM
         Org Unit 1          Italy
         Last Name           IW0DZG
         First Name          Claudio



Status          769
Explanation     Invalid recipient

X.400 Status    769
Explanation     Router: Unable to open mailbox file D14HUBM1/14/H/IBM mail.box: Server not responding

1998\07\03@225049 by ephen Rothlisberger

picon face
>> >I need to us a 16F84-04 to drive a 3 or 4 digit 7 segment display
>> >(common
>> >annode or cathode, doesn't matter).
>> >
>> >I need to be able to send a serial number to the chip (9600,8,N,1) in
>> >the
>> >range of 0 to 9999 and have it display it. I think interrupts will be
>> >required because the display needs to be multiplexed and at the same
>> >time
>> >needs to check for serial data.

One possibility is to use the Philips SAA1064 chip, a 4-digit LED-driver
with I2C-Bus interface. It's not async serial, but it does give you two
wire (plus ground) comms and it handles all the multiplexing, decoding and
everything.

The Philips website has the datasheet.

Stephen.

1998\07\07@092827 by Pavel Korensky

flavicon
face
At 14:23 4.7.1998 +1200, you wrote:

>One possibility is to use the Philips SAA1064 chip, a 4-digit LED-driver
>with I2C-Bus interface. It's not async serial, but it does give you two
>wire (plus ground) comms and it handles all the multiplexing, decoding and
>everything.
>
>The Philips website has the datasheet.

Yep, I used this chip several times. But there is a problem now, because
Philips stopped the production of these chips and I was not able to find
any equivalent. Finally, I was lucky three weeks ago and I got last 10
SAA1064 chips from one supplier here. But I am affraid that these are the
last one :-((

PavelK

**************************************************************************
* Pavel Korensky                                                         *
* DATOR3 LAN Services spol. s r.o.                                       *
* Modranska 1895/17, 143 00, Prague 4, Czech Republic                    *
*                                                                        *
* PGP Key fingerprint:  F3 E1 AE BC 34 18 CB A6  CC D0 DA 9E 79 03 41 D4 *
*                                                                        *
* SUMMA SCIENTIA - NIHIL SCIRE                                           *
**************************************************************************

1998\07\08@132411 by Marc Heuler

flavicon
face
Hi N (N STEENKAMP [M.ING E&E]), in <EraseMEC06838103Fspam_OUTspamTakeThisOuTfirga.sun.ac.za> on Jul 2 you wro
te:

>        A   B                    C  D
> --------  ----        ----  ------------
>        |  |  |        |  |  |
>        |  |D7|D6 D5 D4|D3|D2|D1 D0
>        ----  ----------  ----

Note that on RS232 the LSB is sent _first_

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...