Art Burke wrote:
> Hey Mike:
>
I prefer you not top-post.
> Yes, I have 7 segment digital LED displays.
>
> I used to use data latches and (I think) 7442 TTL driver chips.
I recall using the 7447 in that application.
> I'm wondering if I should send the data in
serial to a chip and use that to
> drive the LED segments.
> The only reason that I say this is that the board
that I have does not
> provide many outputs and inputs.
>
> I'd like to be able to drive 6 segments.Two for the hex data and four
for
> the hex address.
>
I guess you are building some sort of front panel, similar to
the old KIM had.
Well, lessee...
You say you have PORTA, PORTE, and PORTD available. So I suppose
you are working in expanded multiplex mode.
One possibility is to use parallel output using memory mapped I/O.
You could use 6 seven bit latches and use address decode + R/W
to generate strobes, and be done.
If you want to use I/O ports, then you have these bits available:
PORTA 4 output bits (no use of ICx)
PORTD 6 output bits (no use of SCI or SPI)
That's 10 bits.
If you use the SPI to interface, then you can shift the bits
you want. If you're concerned with flickering, then you can
have another output pin force a load to the actual display
register.
You need to control 7 segments with 6 displays. So you definitely
want to multiplex. With 6 displays, you need either 6 output bits
(too many) or you need a decoder and 3 bits. That selects the
digit to enable. I'd use a 74HC138 and common anode displays.
Now, about the segments, they are 7 and that's that. So you need
10 output bits if you use a parallel I/F to the uC.
So, either parallel I/O connected to address decode and some latches
will work (need 6 seven bit latches), or
parallel I/O using all possible output bits will work (need digit
decoder), or
the SPI will work (several possible configurations).
Take your pick.
You didn't specify whether you needed duty cycle control
either for brightness control or power consumption control,
so I left them out of consideration.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Bootstrap Mode
Started by ●October 31, 2005
Reply by ●November 9, 20052005-11-09
Reply by ●November 9, 20052005-11-09
Thanks Mike:
Don't know what "top posting is though".
Art
_____
From: m68HC11@m68H... [mailto:m68HC11@m68H...] On Behalf Of
Mike McCarty
Sent: Wednesday, November 09, 2005 3:07 PM
To: m68HC11@m68H...
Subject: Re: [m68HC11] Hooking up LED segments to a Microcore-11 board
Art Burke wrote:
> Hey Mike:
>
I prefer you not top-post.
> Yes, I have 7 segment digital LED displays.
>
> I used to use data latches and (I think) 7442 TTL driver chips.
I recall using the 7447 in that application.
> I'm wondering if I should send the data in serial to a chip and use that
to
> drive the LED segments.
> The only reason that I say this is that the board that I have does not
> provide many outputs and inputs.
>
> I'd like to be able to drive 6 segments.Two for the hex data and four for
> the hex address.
>
I guess you are building some sort of front panel, similar to
the old KIM had.
Well, lessee...
You say you have PORTA, PORTE, and PORTD available. So I suppose
you are working in expanded multiplex mode.
One possibility is to use parallel output using memory mapped I/O.
You could use 6 seven bit latches and use address decode + R/W
to generate strobes, and be done.
If you want to use I/O ports, then you have these bits available:
PORTA 4 output bits (no use of ICx)
PORTD 6 output bits (no use of SCI or SPI)
That's 10 bits.
If you use the SPI to interface, then you can shift the bits
you want. If you're concerned with flickering, then you can
have another output pin force a load to the actual display
register.
You need to control 7 segments with 6 displays. So you definitely
want to multiplex. With 6 displays, you need either 6 output bits
(too many) or you need a decoder and 3 bits. That selects the
digit to enable. I'd use a 74HC138 and common anode displays.
Now, about the segments, they are 7 and that's that. So you need
10 output bits if you use a parallel I/F to the uC.
So, either parallel I/O connected to address decode and some latches
will work (need 6 seven bit latches), or
parallel I/O using all possible output bits will work (need digit
decoder), or
the SPI will work (several possible configurations).
Take your pick.
You didn't specify whether you needed duty cycle control
either for brightness control or power consumption control,
so I left them out of consideration.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
SPONSORED LINKS Freescale
<http://groups.yahoo.com/gads?t=ms&k=Freescale+semiconductor+inc&w1=Freescal
e+semiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micr
oprocessor&c=4&s6&.sig=K2HGv-zFlv5OYUv_QxIq_Q> semiconductor inc
Microcontrollers
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Freescale+semicondu
ctor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&
c=4&s6&.sig=SYHwNJjjGQXRvtt_GybT4g>
Pic
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Freescale+semic
onductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microproces
sor&c=4&s6&.sig=umVbbnUwsPzEzKKD_pQfUw> microcontrollers 8051
<http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Freescale+semico
nductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocess
or&c=4&s6&.sig=NO-nSKjHoAlh9XtZ8LB1_A> microprocessor
_____
> Terms of Service.
_____
Reply by ●November 9, 20052005-11-09
Art Burke wrote:
> Thanks Mike:
You are welcome.
> Don't know what "top posting is though".
> Art
Top-posting is putting your response above the quoted
material.
Bottom-posting is putting your response below all
quoted material.
Occasionally, top-posting is reasonable, but usually
it makes things hard to read and understand.
Occasionally, and more often, bottom-posting is reasonable,
but it often also makes things hard to read.
Interspersing responses with the material they are associated
with is usually the best way. This makes things read like
a normal conversation.
Definitely snipping unimportant material is a definite plus.
[snip]
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
> Thanks Mike:
You are welcome.
> Don't know what "top posting is though".
> Art
Top-posting is putting your response above the quoted
material.
Bottom-posting is putting your response below all
quoted material.
Occasionally, top-posting is reasonable, but usually
it makes things hard to read and understand.
Occasionally, and more often, bottom-posting is reasonable,
but it often also makes things hard to read.
Interspersing responses with the material they are associated
with is usually the best way. This makes things read like
a normal conversation.
Definitely snipping unimportant material is a definite plus.
[snip]
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Reply by ●November 9, 20052005-11-09
Reply by ●November 10, 20052005-11-10
--- In m68HC11@m68H..., "Art Burke" <mathtutoring@c...>
wrote:
> I just purchased a MicroCore-11 board, and am wondering if I can do
> the following:
>
> I have PA0 ->PA7, PE0->PE7, PD2->PD5 available.
>
> Should I transfer the data to the LED segments via a parallel bus
> or in a serial fashion?
Based on what you say here and what I've read of your later responses,
I can give you a few "high level" ideas - if any of these appeal to
you, I'd be happy to explain them in further detail.
1. Maxim (http://www.maxim-ic.com) makes a number of very useful,
highly-functional LED display driver devices. Most of the devices I
have in mind are designed to be interfaced with a SPI bus. As you
have ports PD2-PD6 available (the HC11's SPI bus), using an
appropriate Maxim device would do the job with a minimum component
count. I do not recall offhand any specific part numbers, but if this
approach interests you, I can help you with device selection.
2. Non-multiplexed display drive using memory-mapped latches: With a
bit of 74HC-style logic you can memory-map a number of 74HC374 8-bit
latches - one for each display element. You'll also need a sink
driver (such as the ULN2803) for each (common-anode) display element,
as well as 8 current-limiting resistors for each display element.
This approach is very hardware-intensive, but has the virtue of being
extremely easy to update and maintain on the software side (just write
segment data to appropriate memory locations).
3. Multiplexed display drive using memory-mapped latches: The device
count can be considerably reduced over that of approach (2) if you
utilize a display multiplexing technique. This approach would require
two 74HC374 8-bit latches, associated memory-mapping hardware (address
decoding), a single 8-bit sink driver (ULN2803) and one low-medium
current PNP transistor (2N3906 should work) for each display element,
as well as 8 current-limiting resistors. One latch would be used to
select the active display element (turning it on via PNP transistor)
and the other latch would be used to drive the display segments (via
ULN2803 sink driver and current-limiting resistors). A multiplexed
display has to be constantly 'refreshed' by selecting a display
element, turning it on for a brief period of time, driving the
segments as desired, then advancing to the next display element,
repeating the same procedure, at a fairly high rate of speed - fast
enough so all display elements are "refreshed" at a rate faster than
human vision persistence (around 1/30th second).
4. Same as (2), but use latched serial shift registers (such as the
74HC594). A bit less hardware than the memory-mapped approach
(although not by much) but requires more MCU I/Os and a somewhat more
difficult software service due to the need to serially shift the data
out to the serial-to-parallel latches.
5. Same as (3) using latched serial shift registers. Lower device
count, and reasonable I/O ussage, but the most complex software
service of the approaches I've discussed.
My personal preference, were I designing the display, would be to use
approach (1) - an intelligent display driver. I just took a quick
look at Maxim's site using the "parametric search" offered there and
found a number of devices that would meet your needs. One intriguing
candidate is the MAX6950/6951, capable of driving 5 (6950) or 8 (6951)
common-anode 7-segment (+d.p.) LED displays using a clever
multiplexing and pin-driving technique that allows up to 8-element
(digit) displays to be driven from a package with only 16 pins. This
device takes care of display multiplexing, hex decoding if desired,
blinking, intensity control, and current limiting (no external
resistors needed). A single device of this type, and a small
collection of external components (3 caps, a resistor, and LED
displays) will do everything you need. This particular device is
serial-driven and (presumably) SPI-compatible, so it can be controlled
by the MCU using the Port D I/Os (PD2-PD6).
If you would like a more detailed discussion of any of the approaches
I've discussed here, let me know.
> I just purchased a MicroCore-11 board, and am wondering if I can do
> the following:
>
> I have PA0 ->PA7, PE0->PE7, PD2->PD5 available.
>
> Should I transfer the data to the LED segments via a parallel bus
> or in a serial fashion?
Based on what you say here and what I've read of your later responses,
I can give you a few "high level" ideas - if any of these appeal to
you, I'd be happy to explain them in further detail.
1. Maxim (http://www.maxim-ic.com) makes a number of very useful,
highly-functional LED display driver devices. Most of the devices I
have in mind are designed to be interfaced with a SPI bus. As you
have ports PD2-PD6 available (the HC11's SPI bus), using an
appropriate Maxim device would do the job with a minimum component
count. I do not recall offhand any specific part numbers, but if this
approach interests you, I can help you with device selection.
2. Non-multiplexed display drive using memory-mapped latches: With a
bit of 74HC-style logic you can memory-map a number of 74HC374 8-bit
latches - one for each display element. You'll also need a sink
driver (such as the ULN2803) for each (common-anode) display element,
as well as 8 current-limiting resistors for each display element.
This approach is very hardware-intensive, but has the virtue of being
extremely easy to update and maintain on the software side (just write
segment data to appropriate memory locations).
3. Multiplexed display drive using memory-mapped latches: The device
count can be considerably reduced over that of approach (2) if you
utilize a display multiplexing technique. This approach would require
two 74HC374 8-bit latches, associated memory-mapping hardware (address
decoding), a single 8-bit sink driver (ULN2803) and one low-medium
current PNP transistor (2N3906 should work) for each display element,
as well as 8 current-limiting resistors. One latch would be used to
select the active display element (turning it on via PNP transistor)
and the other latch would be used to drive the display segments (via
ULN2803 sink driver and current-limiting resistors). A multiplexed
display has to be constantly 'refreshed' by selecting a display
element, turning it on for a brief period of time, driving the
segments as desired, then advancing to the next display element,
repeating the same procedure, at a fairly high rate of speed - fast
enough so all display elements are "refreshed" at a rate faster than
human vision persistence (around 1/30th second).
4. Same as (2), but use latched serial shift registers (such as the
74HC594). A bit less hardware than the memory-mapped approach
(although not by much) but requires more MCU I/Os and a somewhat more
difficult software service due to the need to serially shift the data
out to the serial-to-parallel latches.
5. Same as (3) using latched serial shift registers. Lower device
count, and reasonable I/O ussage, but the most complex software
service of the approaches I've discussed.
My personal preference, were I designing the display, would be to use
approach (1) - an intelligent display driver. I just took a quick
look at Maxim's site using the "parametric search" offered there and
found a number of devices that would meet your needs. One intriguing
candidate is the MAX6950/6951, capable of driving 5 (6950) or 8 (6951)
common-anode 7-segment (+d.p.) LED displays using a clever
multiplexing and pin-driving technique that allows up to 8-element
(digit) displays to be driven from a package with only 16 pins. This
device takes care of display multiplexing, hex decoding if desired,
blinking, intensity control, and current limiting (no external
resistors needed). A single device of this type, and a small
collection of external components (3 caps, a resistor, and LED
displays) will do everything you need. This particular device is
serial-driven and (presumably) SPI-compatible, so it can be controlled
by the MCU using the Port D I/Os (PD2-PD6).
If you would like a more detailed discussion of any of the approaches
I've discussed here, let me know.
