More input and output pins
Dr_Acula
Posts: 5,484
Testing some ideas regarding more propeller pins. Everything is a compromise but there are a number of things that are very useful on a board. Audio (2 pins), I2C (2 pins), keyboard (2 pins), RS232/download (2 pins), VGA/TV (8 pins), SD card (4 pins). So that leaves 12 pins. Using 8 pins for a data bus and 4 for control, this can be expanded with some latches to 72-80 output pins and 16 input pins.
With a control latch, the output pins can be outputs or HiZ, and the input pins can be bidirectional.
I'm not quite sure what this could be used for - I think flexibility is the key. Pasm ought to be fast enough to toggle all the output pins and drive many servos. Or external memory (hence the slightly unusual design using an AND gate on the direction pin for the 245). And I think touchscreens. And external memory using counters for fast cache memory for C and other languages. Or enough pins to talk to old-school 8080 style 8 bit bus chips like many 82C55s.
I have a vague idea this could combine the touchscreen boards and the dracblade Z80 emulation and run C faster than ever, all in one board, plus the ability to have VGA/TV and touchscreen all on one board, plus have lots of pins left over.
I'll see if it fits on a eurocard.
With a control latch, the output pins can be outputs or HiZ, and the input pins can be bidirectional.
I'm not quite sure what this could be used for - I think flexibility is the key. Pasm ought to be fast enough to toggle all the output pins and drive many servos. Or external memory (hence the slightly unusual design using an AND gate on the direction pin for the 245). And I think touchscreens. And external memory using counters for fast cache memory for C and other languages. Or enough pins to talk to old-school 8080 style 8 bit bus chips like many 82C55s.
I have a vague idea this could combine the touchscreen boards and the dracblade Z80 emulation and run C faster than ever, all in one board, plus the ability to have VGA/TV and touchscreen all on one board, plus have lots of pins left over.
I'll see if it fits on a eurocard.
Comments
Please note that on the schematic the outputs of the '138 decoders go to 'CLK' inputs of registers.
When the Prop firmware changes the inputs to the '138 the outputs will glitch since the '138 is purely a combinatorial logic decoder. It is necessary to have a fifth input to the '138 that is used on the enables only. That ways the prop can set the 4-bit value to decode and then after it has settled use a single enable bit to turn the decoders on. That way the outputs will not glitch and the clocked registers will not be falsely loaded.
cheers,
rich
Ok - maybe there is another solution. Use a 137 instead of a 138 as the 137 has an internal latch. Use the prop pins P0-P2 to the first 137 and P3-P5 to the second one. P8 is the latch pin for both 137s and P9 is the output enable for both 137s. Input the data but keep the outputs all high.
I'll draw it up. I think it might save two propeller pins (at the expense of a few extra pasm instructions).
Re the board, it doesn't quite fit, so might have to lose one of the 40 pin headers and the associated 4 chips. I might bring the pins that drive that out to a smaller header (14 pins plus power = 16) and then do the I/O decoding on another board.
Thinking out loud here based on cavelamb's suggestion, I wonder if it might be useful to replicate the true input output 4 state nature of the propeller pins? eg have some control pins, and then for the 8 data bus pins, for each one individually set it as Low, High, HiZ and Input. Maybe some 125 chips could do that? Or a couple of 4066 chips?
It could be useful for creating, say, SPI busses.
At that level, you are probably best to use a CPLD. That can give you bit-level Data Direction control, and some extra flexibility for multiplex/merge, or whatever you decide. ATF1504ASVL covers 3.3V and 5V operation choices.
You can choose serial, or a more 82C55 style interface.
Are you thinking back to back chips - 373/245?
It would take 6 chips to make up an equivalent to an 8255 (plus the gating).
But throughput could be a whole heck of a lot higher.
Use the 259 to enable the 138s and Bob's yer uncle...
But no..
I was thinking of it going to G1 on IC4. That's ok.
But you are already G1 on IC15.
Dunno, Doc.
But it will be interesting to see what you come up with.
As always.
But 8255 - ah, now that is my language. I abandoned a design a while back as I only have 12 pins and with 8 for a data bus, /rd /wr A0 and A1 on a 8255 there is only room for 1.
But - maybe not. Latch A0 and A1 and /CS into a 373. Then control with /rd and /wr and only one 8255 will respond.
Hmm - I'm going to draw that up.
Downside - 8255 is 5V (there are 3V ones out there but harder to find). But no great matter, 2k7 resistors will solve that. 8255 saves board real estate and keeps the flexibility of pins being "4 state".
Is that really a downside?
Seems like most of the real world runs on 5V.
And, as you said, a few resistors to protect the Prop side...
I'm all for latching address and /CS.
It's makes for messy code but it works.
But - check the data sheet again on setup-and-hold times for the control signals.
Writing all that mess at the same time (same write cycle) is asking for trouble?
(I don't remember which was the critical time, but I think it was expecting everything
stable before /CS)
So we're back to masking and writing and masking and writing (and masking and writing and masking and writing)...
(control words, /rd, /wr, /cs, data, et al)
That's where I came to love the '259 so dearly...
All is compromise.
Occasionally even compromise itself.
Sure, all my designs are open source. Only thing is - the design keeps changing!
Ok, this is an 82C55 solution. 96 I/O pins. It fits and autoroutes easily on the board, and there is a propeller pin free.
The other solution to explore is a multi-propeller design.
You have a pin free???
That's a first.
LOL, I think it is... Usually it's one pin short.
I like this design. Keep up the great work!
DIP packages line up well on this type of board, and there is only one CPLD in DIP, the ATF2500C, which has 48 macrocells and 24 Op-connected macrocells. It is thirsty, and needs a full spec device programmer, and costs about the same as a Prop.
ATF1504ASVL comes in PLCC44, which you can socket, and this has JTAG pgm, and lower Icc, so is a better spec.
The Prop-as-Slave idea still appeals, using the tiny SOT23 loader option I suggested in the other thread.
You would fill one COG with IO slave smarts, and clone a 82C55 and why not a few 16C550 Uarts... and some PCF85xx ...
- anything more, like code for the other COGS, would come down the link.
As the link is custom, a larger frame of 32/33/48 bits would be more compact to code, and run faster.
(but you would still keep it compatible with 8 bit hosts )
Two questions:
1) So what would the bit level protocol be if you used another prop for I/O expansion?
2) IF you used an Address Latch Enable (ALE) pin with a read (RD) and write (WR) pins you could emulate a standard microprocessor bus. That is put the address out on eight I/O pins and toggle ALE to latch it then use RD or WR to move data on the same eight I/O pins. That would be a good way to get many, many bits of I/O. However it takes many parts to build. But if it could be build with SMD parts, on a PCB it may not be too big. How about 32 ins and 32 outs. But then maybe just the 16-bit I/O expanders that micochip makes.
What to do, what to do.
I personally think that there should be an I/O expander chip that interfaces with a quad SPI interface.
cheers,
rich
Good idea
Turns out I have a design here called SPIQ8255, that fits (just) in a ATF1504ASVL
- First Nibble is 4 bit Address, and next Nibble is an operation Opcode, has 24 I/O lines, with individual DDR control.
4 pins are Device address, so you can have 16 of these on a QuadSPI bus.
Pinout S S S P P P R S I I I e P d d d C s A I i i i V E e d C G P o o o C N t r L N N c 2 1 0 C 0 N 0 K D C 7 +------------------------------------+ | 6 5 4 3 2 1 44 43 42 41 40 | SPIdio3| 7 39 |Pc6 Adr2| 8 38 |Adr1 Adr3| 9 37 |Pc5 GND| 10 36 |Pc4 Pa0| 11 ATF1504 35 |VCC Pa1| 12 44-Lead PLCC 34 |Pc3 Pa2| 13 33 |Pc2 Pa3| 14 32 |Pc1 VCC| 15 31 |Pc0 Pa4| 16 30 |GND Pa5| 17 29 |Pb7 | 18 19 20 21 22 23 24 25 26 27 28 | +------------------------------------+ P P P P G V P P P P P a a b b N C b b b b b 6 7 0 1 D C 2 3 4 5 6Using the VGA pins in between lines sounds interesting - I'll look into that.
Re the 82C55 chips, these are on ebay for $1-$2 if you buy in qty.
Re using propeller chips instead of 8255 chips, I guess one could think of either a serial bus (1 or 2 pin) or a parallel bus (multiple pins with any number possible, but maybe 12 pins is a starting point). I think the 82C55 works out cheaper though.
An SPI8255 is intriguing. If there are 12 prop pins to drive this could you run two in parallel, and then 4 pins for /cs lines?
Sure, on a very basic cents/pin yardstick, but when you include the PCB area costs, that difference shrinks, and flexibility has the Prop well ahead.
You could, but the Adr0..Adr3 pins allow each device to have an implicit address, so really, only one CSN line is needed for 16 slaves. (32 if you do 2 x 4 bits )
Easy to wire for 2 x QUAD for Byte-wide access, but that would be somewhat split on the PCB, however you could route the headers to re-align.
Pin cost would be SPICLK, CENO, and 8 data lines, for a total of 10
Two pins for /CS - into a '139. That makes 4 /CS signals.
The other half of that 139 can be the missing inverter.
It's strange to see that much going on in a schematic without an inverter in site...
Going right back to the early days of the DracBlade I did ask about the reason for '374s instead of '373s, only because I had a bunch of '373s already. I had wondered if the "transparant passing" would save having to stick in any wait states.
I have found a bunch of EDO DRAMs (which have static in them too!) so the dreaming goes on.
For extra pins I usually stole the upper four of the VGA (greens and reds). Retro shouldn't have pretty colours anyway !!!
Re 82C55 chips they may max out at 8Mhz so there might be some wait states needed.
I'm hoping that this design will merge the dracblade and the touchscreen together somehow. With 96 I/O pins, you could allocate 27 for a 512k ram chip. And you can create an address/data bus, which for the touchscreen would be a 16 bit bus. And can preload counters for faster burst transfer of data. There still should be room in a cog for more clever things, like constant polling for new data while at the same time handling servos and maybe even (slow) RS232 links.
Ideally the aim would be to have all that happening in a cog and then you talk to the cog at a higher level in spin, ie read a byte, move a servo to a new position, send out a picture to a touchscreen.
That 8 MHZ rating was for direct connection to the address and data bus - and probably won't be a
problem for programmed I/O.
But for PASM, and depending on how the driver is written, maybe so?
That sounds a good idea.
Ok, a simple micro bus, 8 address lines, 8 data lines, a /rd line and a /wr line. Make it 5V so it can talk directly to the 8255 chips. That is 255 addressable devices. The 8255 uses A0 and A1 so decode A2 and A3 to talk to one of 4 8255 chips. A4-A7 must be low. So that is address 0-15 which leaves lots free to talk to other things. 74xx latches etc. All you need to do is decode the address. So if a 8255 is too slow this is a way around the problem.
Addresses can be decoded with and/or gates, or with 138 gates, or with a single HC688 chip.
Bring out data and address and /wr and /wr and power to a 20 pin header. This is now a simple bus that anything can attach to.
The touchscreens use the same sort of bus for instance.
Or you can go a bit further and have some 161 counters that you address and load up, and then clock out the data in a ram by toggling the /rd line. So that can do fast burst memory transfers.
Or talk to ram chip(s). An address + data bus is very flexible.
Maybe that spare pin could be used as an interrupt line for the bus, so devices can signal they want to talk?