> Van: David Shoemaker (Comforce/RhoTech) <a-dashoe@MICROSOFT.COM>
> Aan: PICLIST@MITVMA.MIT.EDU
> Onderwerp: Project question: rerouting TTL signals
> Datum: vrijdag 12 juni 1998 4:38
>
> I have a project that I have been working on for the better part of
forever
> trying to find the "Elegant" solution.
>
> Basic problem is rerouting a set of TTL signals into a different
> configuration.
>
> Example
>
> Source          Dest
> A               B
> B               A
> C               F
> D               E
> E               D
> F               C
>
>
> With there being 8 different routings possible.  And 32 (possibly only
16)
> lines being routed at a time.
>
> What I am wondering is if a PIC would be a good candidate for this task.

Any PIC with the number of in/outputs you require !  8 in & 8 Out requires
16 I/O lines.  16 in & out gives 32 lines I/O.  32 In & Out will give a PIC
with at least 64 pins of I/O !  That is ... If you want minimal IC usage
..

> At startup of the pic (or on reset) it would have to find out which of
the 8
> routing maps it was currently using (from a 3 bit mode select which is
then
> no longer used) and load the relevant routing code.
>
> Then I envisioned a buffered input latch on the source side that would be
> polled by the pic as a word or dword then tri-stated.  The values of each
> line would then be bitwise transferred into the appropriate dest value
> (d)word bit.  Once all lines are routed the resulting value would then be
> latched into an output buffer for being read by the dest side of the
system.
>
> Then it would loop back to the read of the source latch etc.

Good thinking !  Use Bytes and you could put the thing into a 16x84 with 4
input buffers, 4 output latches and a 1-of-8 decoder like the 74138.

Read four bytes. Erase result buffer. Get first bit of input. get
destination-bit from look-up table (48 bytes per configuration, maybe outof
EEPROM). set destination bit. Repeat for 32 bits. Send resulting bytes to
output latches.
Ok. I understood the problem.  What was it you wanted ? ;-)

> Timing on the source side is not hyper critical and if I don't care about
> edges of events on that side.  I think I will be clocked on the dest side
> but I am not sure yet.
>
> Ideas / comments welcome.
>
> David

Greetz,
  Rudy Wieser