Searching \ for '[PIC]: 16bit-7segment in a time critical app' 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/microchip/time.htm?key=time
Search entire site for: '16bit-7segment in a time critical app'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: 16bit-7segment in a time critical app'
2002\06\14@151400 by Brendan Moran

picon face
I'm trying to decode 2 16-bit hex numbers to BCD then display them on 7-segment displays from a '877.

I only need 3 digits of each, so I can easily drop rest of the data internally, but they do need to be full range i.e. -999 to +999.  So, that means 3 BCD digits and a sign bit externally. (I already have a 16-bit binary - BCD output routine)

I have only PORTB used, and the rest of the ports are free, but the device is in an application where it only might be possible to multiplex the display.  Basically, I could use the tmr0 interrupt which is running at 9600 interrups/second, but it couldn't opperate when one specific other operation (also interrupt driven) was running, but it would be easy to set up a flag for that.

What I'm thinking right now is setting up a few 22v10's to act as combination BCD to 7-segment decoders and latches, and using them to handle everything.

So, what I'm asking is which of those is better, given that I have enough 22v10's handy to do it, and the code written for them to handle the decoding/latching.  Or is there a better method entirely?

Regards,

--Brendan

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2002\06\14@152842 by Dwayne Reid

flavicon
face
At 12:15 PM 6/14/02 -0700, Brendan Moran wrote:
>I'm trying to decode 2 16-bit hex numbers to BCD then display them on
>7-segment displays from a '877.
>
>What I'm thinking right now is setting up a few 22v10's to act as
>combination BCD to 7-segment decoders and latches, and using them to
>handle everything.

Shift registers!  If you want to run the LED displays from the unregulated
supply, use TPIC6595 (1 per digit).  If you can afford to burn power from
your regulated supply, 74hc595.

If I am doing only a few displays, I use the TPIC part and run the displays
from the unregulated supply.  That lets me use a nice small regulator
(LP2950) and spread the power dissipation over a larger area (the segment
resistors for the LEDs).  I almost always wind up using 8 pin SIP resistor
packs for the segment resistors.

On boards that have LOTS of LEDs, I use a NS simple switcher set at 4.0 Vdc
(nice brightness with 100R SIPs) for the LED supply and use 74hc595 shift
registers.

All this takes very little code in your PIC and only 3 output pins.  And
the shift registers cost MUCH less than the 22v10's.

dwayne

--
Dwayne Reid   <.....dwaynerKILLspamspam@spam@planet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 18 years of Engineering Innovation (1984 - 2002)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2002\06\14@154751 by Brendan Moran

picon face
----- Original Message -----
From: "Dwayne Reid" <.....dwaynerKILLspamspam.....PLANET.EON.NET>
To: <EraseMEPICLISTspam_OUTspamTakeThisOuTmitvma.mit.edu>
Sent: Friday, June 14, 2002 12:26 PM
Subject: Re: [PIC]: 16bit-7segment in a time critical app
> Shift registers!  If you want to run the LED displays from the unregulated
> supply, use TPIC6595 (1 per digit).  If you can afford to burn power from
> your regulated supply, 74hc595.

Hey, I could probably use the USART in synchronous mode for that, eh?  That
would *really* reduce the code.  And it could probably even fit inbetween
the other ISRs for loading up successive bytes.

Cool.  Hadn't thought of that.

--Brendan

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2002\06\14@164236 by Brendan Moran

picon face
Ah, the irony, as near as I can tell, I don't have any shift registers
handy... Oh well, I guess I'll just configure a few 22V10's as shift
registers until I find some ;)


--Brendan


{Original Message removed}

2002\06\14@202616 by Byron A Jeff

face picon face
On Fri, Jun 14, 2002 at 12:15:49PM -0700, Brendan Moran wrote:
> I'm trying to decode 2 16-bit hex numbers to BCD then display them on
> 7-segment displays from a '877.

Alright.

>
> I only need 3 digits of each, so I can easily drop rest of the data
> internally, but they do need to be full range i.e. -999 to +999.  So, that
>means 3 BCD digits and a sign bit externally. (I already have a 16-bit binary
>- BCD output routine)

Well the sign bit is somewhat irrelavent. Simply save it and complement if
negative and run the absolute value through the routine.

Are you planning on capping/limiting values above 999 and below -999 to those
max values? Just curious.

> I have only PORTB used, and the rest of the ports are free, but the device
> is in an application where it only might be possible to multiplex the
> display.

That's business as usual on seven segment displays. Multiplexing is almost
always helpful. It saves both I/O and board real estate.

>  Basically, I could use the tmr0 interrupt which is running at 9600
> interrups/second, but it couldn't opperate when one specific other operation
> (also interrupt driven) was running, but it would be easy to set up a flag
> for that.

As long as the other op doesn't take too much time it should be fine. However
if it delays the timer interrupt too long then you'll get uneven brightness on
the digits. In that case the higher interrupt would be responsible for updating
the display when TMR0 rolls over.

>
> What I'm thinking right now is setting up a few 22v10's to act as
> combination BCD to 7-segment decoders and latches, and using them to handle
> everything.

<JOKE MODE>
??????. weird head scratching, mumbled muttering....

What in the HELL are you talking about, Willis!?!?
</JOKE MODE>

Brendan, the whole point of having a high speed microcontroller is so that
you don't have to hang a bunch of hardware to do a task like this. Everything
you need done can be easily handled in software. All it costs is I/O pins.
>
> So, what I'm asking is which of those is better, given that I have enough
> 22v10's handy to do it, and the code written for them to handle the
> decoding/latching.  Or is there a better method entirely?

<JOKE MODE>
Ah I see. The 22V10s are like a nice shiny new multipart power tool set that
you've gotten for Father's Day. Just itching to find a project to use on.
Only problem is that all you really need to do is hammer nails.
</JOKE MODE>

Leave the 22V10s for another project. You don't need them.

You have enough I/O real estate to essentially do it for free. Here's the
I/O cost:

8: Seven sement driver + decimal point*
4: Display drivers for your 3 digits + sign bit.
---
12

* 11 if the decimal point isn't required.

So it's a full port and a half. But as you stated you have that kind of real
estate available. So use it.

Attach PORTD to the display anodes (I'm presuming common cathode displays) via
180 ohm resistors (18 ma through 1.7V forward voltage LED's with 5V Vdd. Adjust
to meet the requirements of you LEDs). Take 4 pins of PORTC or PORTA (whichever
isn't tasked for anything else) and drive 4 NPN drive transistors: collector
connected to the cathode of each display, base connected to the port pin
through a 1K resistor, emitters grounded.

That's it. All the hardware you need. To operate simply drop the display value
on PORTD and raise the required digit drive pin high. Use standard multiplexing
techniques such as blanking the display between digit changes (all 4 drive
lines low). Cycle as fast as you can afford.

No hardware necessary. The PIC can do all the decoding and multiplexing.
There's no need to add any additional hardware unless you want to conserve
I/O pins.

With external hardware 4 pin interfaces are trivial, and with quite a bit of
work, 1 pin interfaces are possible. However the only purpose of using the
external hardware is to save PIC pins.

However if the PIC has enough pins, just use them. That's what they are there
for.

Just my 2 cents.

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2002\06\17@052326 by Alan B. Pearce

face picon face
>Hey, I could probably use the USART in synchronous
>mode for that, eh?  That would *really* reduce the
>code.  And it could probably even fit inbetween
>the other ISRs for loading up successive bytes.

Actually I think you will find it easier to use the SSP in SPI mode to send
data to shift registers.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


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