Subject:
|
Re: Expansion interface status
|
Newsgroups:
|
lugnet.robotics.handyboard
|
Date:
|
Wed, 22 May 1996 17:06:55 GMT
|
Original-From:
|
Chuck McManis <cmcmanis@netcom.com*SayNoToSpam*>
|
Viewed:
|
1370 times
|
| |
|
|
Fred G. Martin wrote:
> Yes. The current status is "on hold" while I rethink the feature set.
>
> I'm considering doing something more like Scott Edward's little servo
> board for HB expansion: that is, a collection of small, physically
> detached boards. For servo's, I don't have to do any work, because
> S.E.'s board is ideal.
>
> If people have any reactions to this, or comments about what features
> they think are needed, post to the list!
To Fred and others, I've been thinking about this off and on for over
a year now, and since I now have parts I'll finally get my HBs into
something more than just board status.
Robots eat I/O pins for lunch. Sensors eat input pins and actuators
eat output pins. Both are essential and you will often need a unique
mix of each. This is the problem, how do you support a wide range
of I/O options without having a huge board that wastes space for
people who don't need them all. The traditional answer has been so
called "mezzanine" boards such as the expansion board on the 6.270
board.
One solution that is postulated a lot is the "serial" I/O bus.
Systems of this form have low impact on the main board (typically
an RS-485 port) and are quite expandable since any number of I/O
"modules" can be built and daisy chained off the serial lines.
Unfortunately these systems are also slow. Consider the typical
function "x = digital(1, 0); /* read bit zero from module 1 */"
This function has to send at least one byte to initiate the action
(say 0x1, for module read) and read one byte of data, then mask
out the undesired bits. The I/O communication time dominates with
20 bit times (2 bytes) at 19.2K (or approximately 1ms). So max
read or update time is 1Khz.
A somewhat more insidious problem is "response" time. Polling 3
bits on 3 I/O ports takes 3mS, or when two I/O modules have data
to report the latency between reads can be quite high. This bus
congestion problem is more common in sensor systems where you have
several overlapping sensors that are all looking at the same things.
Of course the 68HC11 has the SPI which was designed to solve this
exact problem. It is high speed (up to 250Kbps I believe), and it
is supported in hardware in the 6811. The down side is that these
pins can be a bit hard to get to on the Handyboard. Also you are
limited in your bus lengths and there are strict termination
requirements for reliable operation.
Variations are possible and at first glance seem to have the most
hope of working out.
Already the HB uses a mux system to mux analog I/Os into the system
Using the latched shift register trick four I/O pins on the HB
can be turned into as many digital I/O bits as you would like.
However this is more efficient since you can simply "clock in"
the bits without serial setup and overhead. Consider a hypothetical
design that limits itself to a fixed set of 256 I/O bits, of which
0 or more may be installed (in groups of 8 no doubt). Setting any
bit on the system takes 256 bit times (for the shifts) however
the shift registers can run as fast as you'd like. Thus the loop
essentially only needs to set up the bits, toggle the clock pin
256 times, and toggle the latch pin for a complete execution.
Call it 100 eclocks or about 200Khz maximum refresh rate.
Still, its a lot of overhead for reading and writing digital bits.
The ideal solution is to use some of the "wasted" address space in
the top 32K of memory and fully decode the addresses. Bring the
decoded lines out to miniboard like headers of the form:
P0-01 GND P1-1 RD* P2-1 RD* P3 - P9
P0-02 D0 P1-2 WR* P2-2 WR* same as P1,2
P0-03 D1 P1-3 key P2-3 key
P0-04 D2 P1-4 CS* P2-4 CS*
P0-05 D3
P0-06 Key (no pin)
P0-07 D4
P0-08 D5
P0-09 D6
P0-10 D7
P0-11 PE4 (analog input)
P0-12 ICx (can be used as an interrupt input)
P0-13 Vbatt
P0-14 +5v
These connectors would be used as follows, the P0 connector is daisy
chained to all of the I/O boards. Simple IDC ribbon cable is useful
here. Each of P1 - P9 define the control signals for one of 8 I/O
ports. Expanding the system would consist of building a board with
an octal latch at the minimum. Connect the ribbon cable, add a
connection to one of the "port control ports" and you're done. A
small 8 bit input or output port (depending on the latch) with a
small bit of prototyping area could be layed out on a single sided
board. You could almost connect the bus directly to a BASIC Stamp
if you wanted a "smart" (and I use the term loosely :-) I/O processor.
And the final reccomendation for this solution is that the code to
read and write I/O bits could be done with poke(); if you wanted
(no impact to pcoder.s19)
What's the impact on the expansion board? To support this the expansion
board would need two plug areas. One would be the common bus and the
other would look just like one of the 8 position headers of the
miniboard. The expansion board would need a bidirectional latch
buffering the common bus with a fan out of 8 LS loads. The Vbatt
line should probably be fused for 4A (500 mA max per expansion
board if they use on board voltage regulation.) You would need
an address decoder (could be done in a single GAL but you could
also use a couple of discrete TTL chips to do it) and a 3:8 demux
to generate the control signals on the P1-P9 connectors. Resistor
pack to pull input bus high when not in use. You may also want to
pull the CS* lines of the Port pins high. You would probably want
to limit the length of the common ribbon cable to under 12".
I suppose these suggestions are listed in reverse order of preference.
I like the last one best and the first one least.
--
Chuck McManis http://www.professionals.com/~cmcmanis
Director System Software, FreeGate Corp. cmcmanis@netcom.com
All opinions in the non-included text above are those of the author and
not of his employer or avocado plant.
|
|
Message is in Reply To:
 | | Re: Expansion interface status
|
| (...) Yes. The current status is "on hold" while I rethink the feature set. I'm considering doing something more like Scott Edward's little servo board for HB expansion: that is, a collection of small, physically detached boards. For servo's, I (...) (29 years ago, 22-May-96, to lugnet.robotics.handyboard)
|
4 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
