Why on earth do you want a micro with over 70 I/O pins ? You are much
better off using multiplexer chips (many different ones to choose from) that
can encode 1 to 16 lines (or more) into BCD or even serial/I2C over just two
wires to the micro, reducing the port count requirement on your micro very
dramatically. This is nearly always how I/O expansion is done on any micro.
These devices can be cascaded to provide many more than 70 I/O ports if
required.
Building imbedded design solutions of any real significance usually involves
using more chips than just the micro ;)
> could you suggest me a micro featuring over 70 I/O, uart, with decent
> delevopment tools? (easy uh?)
> always for my "MIDI thing" project
Um.... How 'bout a Xilinx 9575 and an 8051 (or family thereof)?
-->Neil
-------------------------------------------------------------------------------
Neil Bradley In the land of the blind, the one eyed man is not
Synthcom Systems, Inc. king - he's a prisoner.
ICQ #29402898
> -----Original Message-----
> From: Ian McLean [SMTP:ianmcleanKILLspamOPTUSHOME.COM.AU]
> Sent: Wednesday, March 12, 2003 10:27 AM
> To: .....PICLISTKILLspam.....MITVMA.MIT.EDU
> Subject: Re: [a bit OT]: suggestions for a huge I/O capabilities
> microcontroller?
>
> Why on earth do you want a micro with over 70 I/O pins ? You are much
> better off using multiplexer chips (many different ones to choose from)
> that
> can encode 1 to 16 lines (or more) into BCD or even serial/I2C over just
> two
> wires to the micro, reducing the port count requirement on your micro
> very
> dramatically. This is nearly always how I/O expansion is done on any
> micro.
> These devices can be cascaded to provide many more than 70 I/O ports if
> required.
>
> Building imbedded design solutions of any real significance usually
> involves
> using more chips than just the micro ;)
>
> Rgs
> Ian.
>
When you say multiplexer are you talking about a priority encoder? are
pretty useless for port expansion IMHO,
=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to EraseMEpostmasterspam_OUTTakeThisOuTbookham.com.
> -----Original Message-----
> From: Michael Rigby-Jones [SMTP:@spam@Michael.Rigby-JonesKILLspamBOOKHAM.COM]
> Sent: Wednesday, March 12, 2003 10:45 AM
> To: KILLspamPICLISTKILLspamMITVMA.MIT.EDU
> Subject: Re: [a bit OT]: suggestions for a huge I/O capabilities
> microcont roller?
>
> > -----Original Message-----
> > From: Ian McLean [SMTP:RemoveMEianmcleanTakeThisOuTOPTUSHOME.COM.AU]
> > Sent: Wednesday, March 12, 2003 10:27 AM
> > To: spamBeGonePICLISTspamBeGoneMITVMA.MIT.EDU
> > Subject: Re: [a bit OT]: suggestions for a huge I/O capabilities
> > microcontroller?
> >
> > Why on earth do you want a micro with over 70 I/O pins ? You are much
> > better off using multiplexer chips (many different ones to choose from)
> > that
> > can encode 1 to 16 lines (or more) into BCD or even serial/I2C over just
> > two
> > wires to the micro, reducing the port count requirement on your micro
> > very
> > dramatically. This is nearly always how I/O expansion is done on any
> > micro.
> > These devices can be cascaded to provide many more than 70 I/O ports if
> > required.
> >
> > Building imbedded design solutions of any real significance usually
> > involves
> > using more chips than just the micro ;)
> >
> > Rgs
> > Ian.
> >
> When you say multiplexer are you talking about a priority encoder? are
> pretty useless for port expansion IMHO,
>
Please ignore!!! When I read your description of encoding 16 lines into BCD
I immediately assumed you meant a priority encoder. A multiplexer dosn't
really encode 16 lines into BCD, it uses address lines to select 1 of x
number of inputs, but I see where you are comming from! Unfortunately I
went to close my reply and hit send...
Regards
Mike
=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to TakeThisOuTpostmasterEraseMEspam_OUTbookham.com.
>> could you suggest me a micro featuring over 70 I/O, uart, with decent
>> delevopment tools? (easy uh?)
>> always for my "MIDI thing" project
There is a reason you only see lots of I/O on large, expensive chips. The cost of a chip is mostly dependent on die size, and this in turn depends on 2 things - the
amount of circuitry, and the space required for the bond-out pads, which are usually around the
edge. If you have a relatively small amount of circuitry, e.g. a low end PIC or small FPGA, but lots of
I/O, the size of the chip becomes determined by the number of bond pads, and you end up with wasted
space at the centre of the chip, so the extra I/Os add a disproportionate cost due to the die size
required to bond them out.
There is also the issue of the cost of bonding and testing large numbers of pins. You can clearly see this on FPGAs, where pin count increases with gate count and cost.
So the bottom line is if you want a low to mid-range micro and zillions of I/Os, the most
cost-effective way to do it is with external latches etc. for I/O expansion.
-- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestEraseME.....mitvma.mit.edu>
I am not really talking about priority encoders in general. But a note on
chips of this sort - I do partially agree with you Michael - but it is a
fact that this is the way it has usually been done in the past. FOr
example, how many micro's have you NOT seen that DON'T use 74138's (HC or
LS), 4028 or 4511 etc. etc., and the like for demuxing a BCD to either
single or latched outputs, or conversely, chips such as the 74151 etc., for
line to BCD input multiplexing. Standard muxes and demuxes such as these
have been used for port expansion on micros this way for many years now, but
I agree that this imposes limitations, including the need to multiplex your
inputs/outputs in code if more than 1 line is to be encoded/decoded at a
time.
Our modern PC's hide all of this inside a BIG PLD, but it is still
essentially the same thing.
OTOH, there are much better examples available today - in fact one was
mentioned on the list just recently, the Maxim I2C port expander (MCP23016)
which communicates with the micro using I2C, and has 3 address lines for
cascading. It is fully programmable to assign each of it's 16 lines as
input or output.
I for one would much prefer to solder a few 14 or 16 pin IC's or even a
couple of the 28pin Maxim chips as a solution for prototyping than to
tangle with some micro with 100+ pins with 0.1mm pitch, probably 16bit at
this size, more complicated in it's architecture, (maybe the PIC18F4720 is
an exception here), much harder to program and get working, more support
components, etc, etc, just to get 70 I/O lines, unless the design absolutely
called for it.
>could you suggest me a micro featuring over 70 I/O, uart,
>with decent delevopment tools? (easy uh?)
>
>always for my "MIDI thing" project
I take it you are looking to build a keyboard, and wanting to get the key
inputs into the chip.
Two ways, someone has already suggested using an FPGA, which is probably the
sensible way, as you can select one with a suitable number of I/O lines, and
encode/decode as appropriate.
Second way is to use a micro such as a PIC, with serial/parallel chips such
as 74HC164/165 and an SPI port on the PIC. This can be run at sufficient
speed that any latency in the serial transfer will be minimal, and may allow
you to do what you want.
>I am not really talking about priority encoders in general. But a note on
>chips of this sort - I do partially agree with you Michael - but it is a
>fact that this is the way it has usually been done in the past. FOr
>example, how many micro's have you NOT seen that DON'T use 74138's (HC or
>LS), 4028 or 4511 etc. etc., and the like for demuxing a BCD to either
>single or latched outputs, or conversely, chips such as the 74151 etc., for
>line to BCD input multiplexing. Standard muxes and demuxes such as these
>have been used for port expansion on micros this way for many years now, but
>I agree that this imposes limitations, including the need to multiplex your
>inputs/outputs in code if more than 1 line is to be encoded/decoded at a
>time.
>
>Our modern PC's hide all of this inside a BIG PLD, but it is still
>essentially the same thing.
>
>OTOH, there are much better examples available today - in fact one was
>mentioned on the list just recently, the Maxim I2C port expander (MCP23016)
>which communicates with the micro using I2C, and has 3 address lines for
>cascading. It is fully programmable to assign each of it's 16 lines as
>input or output.
>
>I for one would much prefer to solder a few 14 or 16 pin IC's or even a
>couple of the 28pin Maxim chips as a solution for prototyping than to
>tangle with some micro with 100+ pins with 0.1mm pitch, probably 16bit at
>this size, more complicated in it's architecture, (maybe the PIC18F4720 is
>an exception here), much harder to program and get working, more support
>components, etc, etc, just to get 70 I/O lines, unless the design absolutely
>called for it.
>
>Rgs
>Ian.
>
Absolutely, but you need different chips for demuxing than you do for
muxing, unless you go with something like the Maxim chip MCP23016 solution I
suggested which is programmable.
The only issue with chips such as this or the serial/parallel ones described
by Mike, is you will need to tackle SPI or I2C communications. Of the two,
SPI is easier, but there are those on this list (such as Olin) whom are more
than happy to help you out with library code and examples to do either type
of serial communications. There are many previous posts in the archives
that you could mull over on both SPI and I2C communicationas as well. If
all of this still leaves you bewildered - you only need to ask the list for
advice - and someone will surely accomodate you ;). I would suggest reading
over the archives first though.
All else said, it is certainly worth the effort - you will only need two or
maybe four inputs to your micro to control all 70 I/O lines ;)
>
>as i understand by your posts, i could divide in and out ports in
>groups and control them multiplexing
>
>so, does multiplexing work for both inputs and outputs?
Not in the way you are thinking, but lets just have a look at your list for
a moment.
>my needs are:
>
>- 40 switches
Right, use 5 74HC164 to get them into an SPI port.
>- 40 leds
Right use 5 74HC595 as output ports, driven from an SPI port. Note that
these have enough current capability to need only a resistor between the LED
and the chip to limit the LED current.
>- 5 displays (3 digits alfanumeric, not LCD)
Well if not using LCD what sort of display are you using? I would suggest
that if you are looking at an LED starburst or dot matrix, then each display
should have it's own micro to make the display look like a Hitachi 44780
series device to the main micro. The 3 displays can then go on one port, and
the display being updated is selected by an enable line.
>- 4 AD converters
OK, but what accuracy. If 10 bits is OK then we are set.
>- UARTS to send and recieve MIDI data
Fine, now look at what I have written, and see how it fits an 18F252 or
16F876. These both have a UART, SPI interface, 5 A/D channels of 10 bit
accuracy, and enough port lines left over to drive 44780 type LCD displays,
which is why I ask what sort of display you expect to use.
Some further suggestions after carefully reading over your requirements.
a) Use BCD to 7segment decoders for the LED displays (I assume you are
talking about 7 segment LED displays here). These will use 3 outputs from
the PIC. They are cascadable.
b) Use suitable cascaded muxes such as the 74LS165 described by Alan (sorry
for saying Mike earlier) for your 40 switches. These use SPI on two wire
input to your micro. An alternative may be to use a resistor divider ladder
on the switches, and read the voltage output on a single or a few AD lines
(more than one AD line may be required to get voltage resolution for 40
switches) ;0
c) Use suitable demuxes such as 74HC138 or latch chips such as 74HC273 for
your LED outputs.
d) Save 4 AD lines on the PIC for your AD converters.
e) Use the one UART (it is bidirectional) for your MIDI data.
All of this could be done with a PIC16F877 or a PIC18F452 and a handful of
logic chips.
>thanks for your inputs guys
>
>i'm a newbie, and your opinion really matters
>
>my needs are:
>
>- 40 switches
>- 40 leds
Use a matrix - e.g. 8 x 5 - 13 I/O's, les susing an external decoder (e.g. HC138)
You can also use the same matrix (and scanning code) to do the switches, using diodes to prevent
inadvertent shorts. .
-- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu>
>Why on earth do you want a micro with over 70 I/O pins ?
IIRC Atmel sellls a lot of them, as does Hitachi and many others. For a
homebrew design, a one-chip solution might save a lot of time and
headaches. Definitely the atmel would be the way to go for a hobbyist. I
think a lot of these mega-I/O chips end up as LCD drivers and such. Take
apart any toy or mass market appliance with an LCD and you are likely to
find a single chip under a gob of goo with a zillion I/O pins running the
thing.
>Building imbedded design solutions of any real significance usually
involves
using more chips than just the micro ;)
Except in my case, where I have been producing commercial one-chip designs
for many years. ;-) ;-)
Why on earth do you want a micro with over 70 I/O pins ? You are much
better off using multiplexer chips (many different ones to choose from)
that
can encode 1 to 16 lines (or more) into BCD or even serial/I2C over just
two
wires to the micro, reducing the port count requirement on your micro
very
dramatically. This is nearly always how I/O expansion is done on any
micro.
These devices can be cascaded to provide many more than 70 I/O ports if
required.
Building imbedded design solutions of any real significance usually
involves
using more chips than just the micro ;)
I believe it's a balancing act to minimize cost. I recently moved a project from an 18F452 to an 18F6720, giving me more RAM, more ROM, another UART, and eliminating several chips used for I/O expansion.
Not quite "over 70 I/O pins", but close, is the 18F8720 with 68 I/O pins.
Why on earth do you want a micro with over 70 I/O pins ? You are much
better off using multiplexer chips (many different ones to choose from) that
can encode 1 to 16 lines (or more) into BCD or even serial/I2C over just two
wires to the micro, reducing the port count requirement on your micro very
dramatically. This is nearly always how I/O expansion is done on any micro.
These devices can be cascaded to provide many more than 70 I/O ports if
required.
Building imbedded design solutions of any real significance usually involves
using more chips than just the micro ;)
>my needs are:
>
>- 40 switches
Right, use 5 74HC164 to get them into an SPI port.
>- 40 leds
Right use 5 74HC595 as output ports, driven from an SPI port.
Note that "serial" peripherals are popular on PICs, due to the small
packages and the desire to save save as many pins as possible, but you
can also simplify some things using a more traditional parallel I/O:
8 pins for data-in and/or data out.
1 pin for read strobe
1 pin for write strobe
N pins for 2^N "port address" (externally decoded.)
These would be handled "automatically" on a processor like an 8051 with
external address space(s), but you can do it in software on a PIC without
too much difficulty.
>my needs are:
>
>- 40 switches
Right, use 5 74HC164 to get them into an SPI port.
>- 40 leds
Right use 5 74HC595 as output ports, driven from an SPI port.
On the LED side, you might also consider the Allegro 6276 (http://www.allegromicro.com/datafile/6276.pdf) 16 bit serial in parallel out constant current LED driver. 3 of these would give you 48 outputs and elminate the need for current limit resistors.
On the switch side, besides shift registers with pull-ups, another couple possibilities if only one switch is hit at a time include an XY scanned keyboard (scanned in software, 7 rows and 7 columns, using a little under two 8 bit ports could handle 49 keys) and a voltage divider driving an analog input. I've had success reading 16 switches with a voltage divider going into an analog input. Use a SIP package of resistors to get good matching of the resistors. I then "loop" each switch through the NC contacts of the other switches so the pressing of two switches does not short out some of the voltage divider. This provides a prioritized input.
Good luck!
Harold
________________________________________________________________
Sign Up for Juno Platinum Internet Access Today
Only $9.95 per month!
Visit http://www.juno.com
And does it perfectly... on the first try... at zero cost. :)
The ideal CPU/uC/whatver has one instruction and requires no RAM or ROM.
The instruction is 10Gbit wide and is self modifying so it can do anything
from four-function calcualtions to play chess. <-- I didn't think that one
up originally. Although that was 20 yrs ago and the number we used was
1Mbit. LOL!
If it weren't for Bill Gates we'd all be running 500MHz 80286s and
Desqview and be stable as a rock. <-- I -did- say that ~15 yrs ago when
386/40 was the edge of the cut. By today we'd have been up to a couple of
Ts. And still just as stable :/
On Wed, Mar 12, 2003 at 12:29:05PM +0100, faisal moro wrote:
> thanks for your inputs guys
>
> i'm a newbie, and your opinion really matters
>
> as i understand by your posts, i could divide in and out ports in
> groups and control them multiplexing
Correct. That would be the standard way of controlling this much hardware.
It works on the simple principal that microcontrollers are fast enough to
access multiple items individually but simulate as if it's accessing everything
at the same time. It'll cut your I/O requirements by an order of magnitude.
>
> so, does multiplexing work for both inputs and outputs?
Yes. However it will require some additional chips for the I/O expansion.
> my needs are:
>
> - 40 switches
Instead of 40 linear switches, the standard practice is to create a switch
matrix. For example here a 8 output/5 input matrix would cut your requirements
from 40 I/O to 13 instantly. Then if you add a single 74HCT138 decoder, you can
collapse the 8 outputs into 3, where the 3 bits selects choose which row of
the keyboard maxtrix is read. A sample of such an interface can be found here:
So you've changed a 40 pin input to a 8x5 multiplex array that is scanned
using a 74HCT138, dropping your I/O load from 40 to 8.
> - 40 leds
Same game plan here. In fact you can even share the same 74HCT138 you already
are using for the keyboard. Create a 8x5 LED matrix adding a second 74HCT138
to drive the cathodes of the LEDs. A sample is shown in this project:
Note that if you drive the LEDs one at a time, and with 2 74HCT138s you will
have to, that the transistor drivers are not necessary.
So we share 3 I/O with the switches, and we use 3 more I/O to drive the second
74HCT138, so the load for the 40 LEDs has dropped from 40 to 3.
> - 5 displays (3 digits alfanumeric, not LCD)
Multiplex these too. I like using 7445 BCD decoders for driving LED displays
because the 80 ma sinking current usually gives bright results. You have
several options to drive these 35 segments:
* Add another 74HCT138
* Use an 8 bit port driving a 7447 and a 7445
>I've had success reading 16 switches with a voltage divider
>going into an analog input. Use a SIP package of resistors
>to get good matching of the resistors. I then "loop" each
>switch through the NC contacts of the other switches so the
>pressing of two switches does not short out some of the
>voltage divider. This provides a prioritized input.
Could you provide a simple schematic of the circuit, or is it similar to
what Olin posted recently under another thread ?
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
> Hi Harold!
>
> On Wed, 12 Mar 2003, Harold Hallikainen wrote:
>
>> Harold
>> "The ideal design has zero parts."
>
> And does it perfectly... on the first try... at zero cost. :)
>
> The ideal CPU/uC/whatver has one instruction and requires no RAM or
> ROM. The instruction is 10Gbit wide and is self modifying so it can
> do anything from four-function calcualtions to play chess. <-- I
> didn't think that one up originally. Although that was 20 yrs ago and
> the number we used was 1Mbit. LOL!
>
> If it weren't for Bill Gates we'd all be running 500MHz 80286s and
> Desqview and be stable as a rock. <-- I -did- say that ~15 yrs ago
> when 386/40 was the edge of the cut. By today we'd have been up to a
> couple of Ts. And still just as stable :/
>
> Have a :) day!
The only qualm I have with this is that we would need a 386 not a 286,
as the protected mode features of the 286 weren't complete enough.
michael brown
"In the land of the blind, he who has one eye is king"
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
mitvma.mit.edu
