--- 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.
Reply by Art Burke●November 9, 20052005-11-09
"Snip"
Thanks Mike,
Art
Reply by Mike McCarty●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!
Reply by Art Burke●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
> 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!
Reply by Art Burke●November 9, 20052005-11-09
Hey Mike:
Yes, I have 7 segment digital LED displays.
I used to use data latches and (I think) 7442 TTL driver chips.
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.
Thanks,
Art
Offering Mathematics tutoring from Arithmetic through Calculus, including
the New SAT Math.
home.comcast/~mathtutoring/index.html
<http://home.comcast.net/%7Emathtutoring/index.html>
_____
From: m68HC11@m68H... [mailto:m68HC11@m68H...] On Behalf Of
Mike McCarty
Sent: Wednesday, November 09, 2005 1:16 PM
To: m68HC11@m68H...
Subject: Re: [m68HC11] Hooking up LED segments to a Microcore-11 board
Art Burke wrote: > Hi to all:
> 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?
Sorry, not enough information.
Do you have a 7 segment digital display?
If so, how many digits? Do you plan to multiplex?
What performance requirements do you have? (visual persistence?)
By "serial fashion" do you mean SPI? SCI?
Do you have any power requirements? IOW, do you need to control
brightness by using a duty cycle? (Also relates to visual persistence.)
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!
_____
> Terms of Service.
_____
Reply by Mike McCarty●November 9, 20052005-11-09
Art Burke wrote: > Hi to all:
> 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?
Sorry, not enough information.
Do you have a 7 segment digital display?
If so, how many digits? Do you plan to multiplex?
What performance requirements do you have? (visual persistence?)
By "serial fashion" do you mean SPI? SCI?
Do you have any power requirements? IOW, do you need to control
brightness by using a duty cycle? (Also relates to visual persistence.)
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 Art Burke●November 9, 20052005-11-09
Hi to all:
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?
Thanks for the help,
Art
Reply by Mike McCarty●November 7, 20052005-11-07
Huey Fen wrote: >>This is incorrect. I have a few tens of A
series chips with
>
> BUFFALO in ROM.
>
> Really? But I am talking on A1 family. Isn't it that the internal ROM
for A1 family has been disable? If I enable the ROM through CONFIG register,
will I get the internal ROM enable with Buffalo inside? I think only A8 consists
of 8K ROM.
> As mentioned previously, I am new in this field. Any correction is most
welcome as this will increase my understanding. Thanks a lot.
All A chips are built on the same die. It works like this...
A0 the EEPROM is likely defective. If you enable it, it
will be there, but Motorola does not guarantee that it
works. It may be perfectly usable in hobby applications,
however, just not working at elevated temps. or whatever.
Or it may have been in a batch which really truly didn't
work properly, and has cells which won't program or which
won't retain programming.
A1 the EEPROM is ok, but the ROM is defective in some way.
If you enable it, it will work, but either
(1) the mask was defective, and there is a
useless program in it
(2) the mask was superceded, and the OEM
allowed Motorola to sell off surplus
chips
(3) the ROM may contain BUFFALO.
Several of my A1 chips fall into category 3.
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 Mike McCarty●November 7, 20052005-11-07
Mark Schultz wrote: > --- In m68HC11@m68H..., Mike McCarty
<Mike.McCarty@s...> wrote:
>>>A1 family does not provide internal Buffalo ROM. You need to
>
> download the Buffalo into external memory.
>
>>[snip]
>>
>>This is incorrect. I have a few tens of A series chips with
>>BUFFALO in ROM.
> My recollection is that HC11's that have BUFFALO stored on on-chip
ROM
> are marked as such on the device. The word "BUFFALO" should be
> present on the device, somewhere below the device part number.
>
> Sorry I can't confirm this absolutely, I don't have any of my
HC11
> boards handy :(
The Motorola documentation on this is that there is a "B"
in the device name. However, I know for a fact that I have
several chips with BUFFALO in them which are not so marked.
I have never seen a chip with BUFFALO stamped on it.
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!