S-40/20 An 8/16 Bit Parallel Bus Concept for Teensy/Arduino/Pi

BrendaEM

Active member
I had this strange but fun idea: to create a parallel bus for small micro-controllers and devices.

There would be a host micro-controller, on a motherboard that could host up to 8 other assorted devices, which could either be other devices or even other micro-controllers.
Background: I like Teensies. I've been enamored with 74LS245 type devices, as a mainstay of old 8-bit retro computers and breadboard computers alike. I also like seeing the old Hewitt Packard computers with slots meant for various electronics duties.

Why?
Well, because it seems like a fun project. It would be interesting to see what the throughput would be.

Why not use IC2?
Because common I2C have speeds are only comparable to an old parallel bus, but mostly it's the quagmire of hardcoded ID's they wanted to auction off to people, and the issues involved with multiplexing them, if you want to use more than one of the same device.

As for the implementation...

The bus itself could operate as either 8-bit mode using a 40-pin connector, or 16-bit mode using an additional 20-pin connector, just like 16-bit ISA was. The connectors would have a gap between them. A 8-bit card would fit into a 16-bit slot, just like old times.

Physical: I had thought that female PC-board mount 40-pin header connectors should still be easy to source. They are durable. The pins are gold. They will hold a card firmer than a card-edge connector. In a pinch, an short length of IDC cable may be used for device development.
The maximum bus or cable length is obviously a trade-off. The shorter the length, the faster it could go. Grabbing a figure, I put 300mm down, but perhaps it could be a little longer at 500mm, so that devices could be tested/designed. I would be against it being over a meter, as the spec is supposed to be an internal bus. It's not SCSI, which at one time had a 12 meter cable length.

Layout:

I wanted to supply 5 volts to the bus. For 3.3V a linear voltage regulator or a VRM could be used. The bus transceivers handle level conversion, very well.

Each slot/device would have its own slot/device select line.
Each slot/device would have its own hardware interrupt line. These can be used to trigger an interrupt routine in the host micro-controller, as in: Hey! Look at me!

Although this is just a parallel bus, I've tried to put some thought to signal integrity...

There would be a return/GND path along each data line. Without resorting to fragile 80-pin cables or differential pairs that require exotic chips, this should help a bit. On the 40-pin connector, the returns would be along the signal path, something like PATA Ultra DMA cables.
The Clock (CLK) would have its own return (ground) line.
The BUS data lines would each have their own return (ground) line.
I had thought that control lines such as SELECT which enables a card for transfer, and DIR which sets the data direction, and RESET would operate with longer pulses and settling time, so the signal integrity would demands would not be as great as the data.

My guess as to the throughput of the bus, would be just that. Untra DMA parallel buses were quite refined, and pulled over from 3 to 167KB/Sec. The parity bit may allow observation for specific speed tuning, as in: run it until it errors, and then back it back down to a safe margin. That's how overclockers do it.

In this first design, each 8 bits swath of data has a parity line. This may help characterize the bus for speed, and offer some measure of data integrity in electrically noisy environments.
Perhaps also, the parity bits could be ignored if you don't want to implement them, just in the way that ECC memory can be configured in processors.

Bus.jpg
Note: in the screenshot, the extra 1s on the side were just for tallying my pins.

Software-wise...
I imagine that with a library, the bus would work like many other devices. It would be initiated, and then you would either send or receive data from a particular slot/device.
You could also have interrupt routines to warn you of events, such as: Fire! or Explosion Imminent!

Going further, perhaps a 2nd accessory connector could be added, bringing the total to 80, for analogue lines.

Uses and Possibilities:
There could be a standard for Teensy or Arduino...video cards. Change from a LCD panel to video monitor, by swapping the card, and loading the library.
This could be used for building 8-machine mini clusters.
This could be used for larger scale data acquisition, to get 8 Teensies with 8 devices on each?
This could be used to make a Frankenstein machine with 2 Teensie's, 2 Arduino's, and 2 Pi's in the same box, all working together. A daughter card could be used to adapt each type of micro-controller. You snap an Teensy or Arduino, or Pi on a small card, and slide it in the bus. Generally, the adapter card would have power conversion, if necessary and a few bus transceivers, the latter of which are about $1 each.
This could be used for either mass storage devices.
This could be used for memory expansion, albeit in a 8 or 16-bit packet-type scheme. Although the bus lacks addressing, the memory could be written and read the same way that IC2 EPROM chips is used.

Maybe this isn't a great idea, or the implementation needs work, but this is indeed a forum, so if you have ideas to make it better, please share them.
 
Last edited:
Why not 3.3V and the 16 bit wide 74LVC16245? Are you intending chips like the 74LVC4245 for the level shifting?

My feeling is that parallel is rarely needed these days unless you have a very high throughput datapath (perhaps implementing a logic aalyzer?) - fast SPI can push a lot of data around with fewer signals, and there's quad SPI if you need more bandwidth.

Also a high speed bus at 5V pulls a lot of power charging capacitances, lower voltages are much less power-hungry.
 
Well, the 74LVC16245 price looks good. Thank you.

I haven't read the sheet yet to see if it's the same as the 74LVC4245, but the latter works well as a bus transceiver.
As far as usage, I do want that swap'able video card, and a no-brainer setup for 8 cards.

I think that the connectors can take at most 2A. It might be easier to pull electrons at 5V. But mostly, I want the bus to also support and source 5V. It's easier to step down than up.

Thank you for your reply.
 
An interesting idea. Are you planning to manufacture and sell hardware?

Have to agree with MarkT on signal voltage. 5V is so 1900s...
 
An interesting idea. Are you planning to manufacture and sell hardware?

Have to agree with MarkT on signal voltage. 5V is so 1900s...

I agree the 5v thing is old, but, one of the goals for the ehem bus is to be able to handle 5v devices, such as Arduinos Nanos. Some 5v Pi's may be able to be bus powered at 5v. Even the Teensy is 5v powered. The signal voltage on the card can be 3.3 volt, as the bus transceiver will do the level shifting. I have been using the bus transceivers for level shifting for stepper motors and a Teensy 4.1, for months--and to drive 6-8 foot lines, too.

So, we are talking about supplied power. The stubborn fact remains: it's easier to step down than up. Is a circuit such as this really hellish?
https://www.amazon.com/Supply-AMS1117-Automatic-Adjustable-Voltage/dp/B09WTVGJL3
Although, at 3.3 volts, the peak power might be more than 2A, per device. The host motherboard should offer 2A per card/device, max.

My friend, am SI engineer was kind enough to show me a way to use fewer return lines for more pins--so now, the interrupt pins and perhaps select lines can share a return line. The layout will be changing, for the better.

Thank you Alan H.
 
Last edited:
Well, Alan and I talked about retaining a good return on a cable, as well. Unfortunately, that was not to be. With a 40-pin connector, there's just not enough pins.

BUT, when it was laid out with a pattern for a PC board-bus, which it primarily is, there is enough pins AND enough for 3.3v Available on the header, by two pins. No, removing the parity line would not cinch it.

So, I tried laying it out again.
Where does that get it?
Well, there is a return/GND line next to every: SELECT, INT, and DATA pin.

Also there are a few pins currently remaining in the 16-bit version. Originally, I had wanted analog pins, but for 3.3v or 5v? Perhaps there should be two pins shorted as a key to check if 16-bit is available on the host or card.
Bus2.jpg

"BUS" line names will be changed to "DATA"
 
Before moving forward, I want to also explore a single 60-pin version. Oddly, it comes down to connector price, but if it wasn't down to connector price, then 60-pin might be easier because everything-about-it could be done with only one size connector in two sexes. For 8-Bit you just don't toggle the 16BIT pin.
This design also features 3.3v as well as 5v.
Also, it has a 16BIT pin to signal fat transfers, an ERR pin. There are SPDx pins so that slower devices could be identified on a faster host. Then the CLK speed could be set.
There are two reserved pins.
This looks like it would do the job.
I will check on 60 pin connector availability.

Bus3.jpg

A connector would be about 84mm long, which seems reasonable.
Cable connectors are cheap. Let's see how much PC board and right-angle connectors with 60 positions are....

Male, $.50 : https://www.digikey.com/en/products/detail/oupiin/2011-2X30G00SB/13251514
 
Bus interrupt lines are usually active low, designed to be pulled down using open-drain drivers. If you did that they effectively wouldn't need ground return lines, and they're less prone to being triggered erroneously when a device isn't connected.

Note that you seem to be missing signal 0 for both the interrupt and data lines, meaning there's only 7 and 15 lines respectively...
 
Last edited:
In a ribbon its best to stick to one ground every 2 or 3 pins, then each signal wire is next to a ground. With ground every 4 pins you increase the amount of crosstalk, but if you have to live with it you have to. Supply pins can serve the same purpose if that helps, since they are decoupled to ground and are equally low impedance. Its not uncommon to see this sort of sequence in pinnings:

Gnd-sig-sig-Vcc-sig-sig-Gnd-sig-sig-Vdd-sig-sig-Gnd.

Note the ground at each end of the ribbon
 
Mark and Jmarsh,

Thank you for your comments. Okay, I will try to rework it again for having a return-guard on the ends.

Thank you for noticing my omission.

Unfortunately, a (fairly) high-speed cable capability may not work out, so, instead, I decided to go a different route: change the clock speed on the bus for cable use. That is what the SPD pins are about. There may still be hope if there is some kind of ATA connector. Because this is meant really meant to be an internal , inside-the-box bus, and while I want to encourage board develpment, perhaps lowering the speed for a temporary usage--would be better than compromising the higher-speed operation.

I don't think that the connector would be too hard on the boards. And I do want to avoid making boards that have to gold-plated, finely beveled edges. Also, I would rather have a female connector on the daughter boards rather than the motherboard--just in case something becomes bent.
(I researched 60- (2x30) pin connectors, and their cost doesn't seem prohibitive. I would like (3x20), but that would likely diminish the choices.)

What I hope to do: help culture a standard, where for instance a Teensy, Arduino, PI, and a Beaglebone--could all communicate on the same bus, along with a video card or sound card.
 
This seems to solve things, but there is one extra GND pin. I will look at it some more.

There is not a guard GND on the 3.3 edge.
The missing pin is used.
Parity-bit moved nearer to first 8-bits for easier 8-bit usage. For 8-bit, usage they 16-bit line could be checked, and then just use the first 8-bits.
Meh, more colorful.

Comments, criticism?
BUS 7.jpg
 
This seems to solve things, but there is one extra GND pin. I will look at it some more.
There is now a guard GND on the 3.3 edge.
The missing pin is fixed.
Meh, more colorful.

It looks like it would take 15 pins for 8-bit minimal use.

Comments, criticism?

View attachment 31784
 
The parity lines would be used just like are used for memory. There is one bit for 8-bit, and/or a second one for 16-bit operation. Given that ECC can run pretty fast, it is my hope that a micro-controller could handle it in only a few instructions.

I thought that it would be beneficial to be able to characterize the bus--both the host and the device. Given that there are basically 3 speed classes for the bus, perhaps the speed could be adjusted to suit the hardware and environment. I wanted some quick and dirty data integrity solution--without resorting to CRCs, which I like, but would be top slow for this application.

It was my hope that if the actual could be characterized--it could be ran as fast as possible, within a safe margin. In other words, keep cranking up the clock until there's and error, and then lower it, ala overclocking. The parity bits allow the hosted device to also detect and report an ERROR. The data integrity might help with electrically noisy environments.

Though, I wanted the ehem bus to support it, but that doesn't make it mandatory, just as ECC memory operation is not mandatory on many processors.
Okay, In ASM it's a little longer than I hoped, longer than dividing by two and checking the modulus, but...https://gist.github.com/killuhwhale/4b6e58472fc3c176ca41154f59e041c1

~

@PaulStoffregen, is an honor for even giving this a look. Thank you for making the Teensy, and for working on libraries which also helped Arduinos.
It was my hope that this could even be used to make interchangeable and standard graphic and sound cards for devices like the Teensy. : )
And yes, I am comfortable with the Retro Computing take on this.
 
Last edited:
By ECC, do you mean Error Correcting Code?

Or will you merely detect an error but not be able to correct it? And if so, what action would you take for uncorrectable errors?

I know you're really focused right now on pinouts and signals, but perhaps some thought about the actual usage and ECC algorithm might be a good idea before finalizing the number of bits dedicated to those functions?
 
Yes, I meant Error Correcting Code, though my thoughts as such are, that if at least it can detect an parity error, the entire byte/word could be resent and/or if the problem is chronic, we can lower the bus speed.

As for the implementation, I just want to provide a parity pin for each 8 bits, as in it works quickly for memory, and it might even be implementable in logic hardware, for fun. I do want this bus to be workable for small 8-bit controllers, too, though I am concerned about the Arduino's ~5us pin rate. You can software switch it to 2us, but the oscilloscope says, "No..." For comparability and lazyness, I don't usually manual work the ports, but it might help in this use-case. I saw somewhere that the Teensies toggle a pin much faster.

Doing some more research is a good suggestion. I will look into it more. Thank you.

I just wanted to throw down some ideas, not get too attached to them yet, and get some feedback. The feedback I have received has been helpful. I have no problem with turning into "Stone Soup" : )

It's looking like lately, the name would be more like S-60 8/16 bus. Named after the S-100 bus. Nice and retro.

If a motherboard was done with a host micro-controller and bus transceivers, the it could be populated with cards. Just slide cards in, load some libraries, tell the host where it is, and walla! It would seem that even a Teensy could be the heart of a video card for another Teeensy. Perhaps another card could have D/A A/D, two channel audio. I see the cards as being simpler and more rudimentary than even old IBM ISA cards, with the idea that most of them would be cheap like Arduino shield, which I never liked, as I do a lot of bread-boarding, and most of the shields are hard-coded for a particular pin. The whole thing could be about the size and shape of a common brick.

[I like CRCs, but they will hit the 8-bit controllers a bit hard for this purpose. If ever I think I know anything about CRC's, I visit the CRC Zoo, and it sets me straight. LOL! I've implemented Billhowl's the table-less version to save parameters on the pseudo-EEPROM on the Teensy 4.1 for my 5-axis CNC camera controller project. I do wish we had real EEPROM on the Teensy, but I haven't worn out mine yet.
No-Lookup CRC-32 Calculation by Billhowl https://forum.arduino.cc/count.php?topic=342371.0
CRC Zoo: https://users.ece.cmu.edu/~koopman/crc/index.html ]

I2C could have really been something, but the standard is/was: sell the addresses to the highest bidder, and now, you generally still don't choices with addresses, maybe you get a solder-blob or two, if you are lucky.

I am impressed with the Teensie's expansion options. I had never seen PSRAM before that. I had to look it up. I taunt friends: Even the Teensy has a RTC, not the PI. : )
I'm not a big IOT person. I would not like to see default Linux Epoch dates and times on any file.
 
Last edited:
I had been thinking about the bus again. Perhaps it could be more useful, if it also supported memory addressing and transfers.

My first thought was, "What good would 256 bytes, or 65535 bytes be ...

....But what if the memory address could be specified in either 2 to 4 bus cycles (depending whether or not the bus is being used in 8-bit mode or a 16-bit mode.) And then the data byte would follow in the next clock, such as: address0, address1, address2, address3, data-byte

Or with 16-bit addressing, setting the address would be done in 2 cycles: address0, address2, data-byte

In other words, ADDR 0 through 3 would specify either it is not accessing memory, or which part of up to: a 32-bit address, that the current 8 or 16 data is. On the down side, it would take a bit of kit on the card to decode the address--and it would take up to 4 bus cycles to do it, BUT this would allow the micro-controller or old computer to access any byte in a 4GB memory card, in nearly random fashion. Perhaps some sic "sketch" could be made to allow various memory storage schemes, perhaps even expanding to multiple slots, which would allow the micro-controller to access 32GB of memory. LOL!

[Once again, the idea of this thing is be able to plug, Teensy's, Arduino's, Beagle-bones, and Raspberry Pi's on the same bus. Perhaps plug in in a C64, An Apple IIe, a CoCo 3, or whaever you have around, too. Of course I am imagining using a Teensy for the processor on the : ) motherboard. The bus would allow interchangable user plugable video and sound DACs. Mostly, the motherboard would have a host CPU, and some bus transcivers such as the 74HC245 or line drivers to buffer the I/O.]

Anyway, the error line was moved to the connector edge. This is indeed a compromise not having a guard ground (though it has a signal return path near), but my thinking, as such was, that an error signal would be of longer duration than any of the others. So, perhaps it is forgivable.

I am just beginning learning Arduino-style Assembly, noticing that sending the bytes to the PORTB or whatnot port, would be fairly fast, well, except for using the memory functions. Which would take 5 bus cycles to read/write one byte.

I was thinking about the bus again. Perhaps it could be called "RetroBus."

If I was smart, and I'm not, I would think of some kind foolproof bus anti-contention logic circuit, such if any two cards are selected, the error is also raised. Perhaps with an 8-way AND-gate, and something to latch the error. This would live on the motherboard, and be cleared by the RESET.

The Teensy 4.1 apparently can work its ports much faster than the Arduino, which is specifiable to 1 microsecond, but can only go down to 3-5 us, though C. It has nice square edges, though.

1705730112440.png
 
Last edited:
I'm curious, have you actually used Teensy 4.1?
[Yes, I really like them, own, 2, but I wish the EEPROM was real, instead of a flash area. They stay crunchy in milk!

I am from more of a mechanical background, but I am have a prototype 5-Axis CNC camera controller project, which using a Teensy 4.1, using roughly 3130 lines of code (including comments). The prototype works, as did the 3-channel unit I made for a friend. I working on a 4-layer board for the 5-channel, but money is tight, and I cannot afford to make mistakes.

It was lightly based from my RDL single axis controller serial interpreter code, which was made for: doing science experiments, a 4th axis on a manual mill, and for winding coils, and of-coarse characterizing stepper motors. https://forum.arduino.cc/t/rdl-v2-stepper-motor-serial-command-line-utility/451062
...Though, I the camera controller has a smoothing algorithm better than the sinusoidal used in RDL. : )

I made a CNC machine from old wafer handling machine parts:

Ironically, my tomography scanned, 2-pinhole interference demonstration is still on Wikipedia: https://en.wikipedia.org/wiki/Wave_interference

I hold a General Ham license, which can be found here, without my address: https://hamcall.net/reports/fccdaily/20210618.htm
....which would suggest some measure of electronic competency. There is only one Brenda in that list, which can be traced to the FCC page.

Communication is a two-way thing, but it appears that this is the 2nd time you have questioned me, in one thread. : )
I am curious, why did you ask if I have used a Teensy 4.1? ]

As for the bus, I think it would be helpful to experimenters and retro-computer people, it's target audience. Given the implementation, I think it would be cheap to implement as it only requires bus-transceivers/line-drivers and connectors.

My SI friend had pointed out that if there was a more dense connector, there would a lesser impedance discontinuity for better performance. Though, header pins are probably easier for the experimenter to implement than an edge-card. I think bus would fill some gaps left by I2C and SPI.
 
Last edited:
I had messed up. (I guess being hit by a car didn't help my cognitive process.)

So, I mixed up the two ideas: what pins would the card use, which will the host use. I had thoughts that any card could the bus equally, but perhaps that would be the minority of cases.

Anyway, if a Teensy 4.1 was socketed to a mother-board, it would take 8 of each INT and SEL, but only one on each card connector.

Still this is set up for Header/Pins, with GNDs between each signal for a return path. If it were edge connector, I would likely run all the grounds on the back. With 8/16-bit support, this incarnation won't fit in 34 pins, such as an old PATA IDE connector. I am not sure which connector would be cheap and popular. I don't want to spend $9 per connector. If the bus was relegated to 8-bit transfers, the surplus of a 34-pin PATA connector would be fine, as pins below the row DAT07/DATPAR0, and then the 16-bit line would not be used.

I like the idea of auto characterizing the bus after configuration, and then setting the CLK speed. Likely they host could clock it. In the spirit of overclocking, data could be sent round-robin until errors appear, and then the bus could stepped down to a lower clock speed. (The parity bits would be for normal operation, the card could either use them or not, like ECC RAM, but really, I just want to know if there are problems)

If I had an idea of the speed that such a bus could run at, perhaps with a uninteruppted ground plane under the signal lines, then it would be easier to decide about the 8/16 bit data width. As my SI friend pointed out, the connector would be the bottleneck. There are little antenna-like pins--and with 2.5mm spacing they are likely too far apart for a good return path. I looked at edgecard connectors; an 44 pin PC board connector is about $3.50 on Amazon, but the cards wouldn't need a connector, but must be sanded. Also, the alternating GND scheme would be invalid for edge-cards.

Presently, the ADDRess would work that if there is no lines selected, then it's just a 8-bit byte/or 16-bit word transfer. If any ADDRess lines are high, then it specifies one of the either one of the two 16-bit addresses segments or the 4 8-bit address segments which form up to a 32-bit address, which may then be read or written to, which would allow 4GB or addressing.

I am not fond of DMA on mission critical things. It's complicated, it really makes a system vulrnable. It doesn't seem likely that a microcontroller could have thier addresses mapped in such a way, BUT, am I throwing away an oppertunity to simulate it? Could someone else figure out some relitive address thing--if only there was a pin for it?

[ Jerry Walker did an interesting series on a Z80 single-board computer, from scratch, which shows both the complexity, and explains the DMA speed gain of a floppy controller.
]

That stated, the addressing scheme described above does select addresses on a hosted device. The INT could tell the host that their byte or word is ready, if not on the next clock.

1706243650993.png


This is also interesting, it's a single board Z80 computer, that has a modern ESP32 CPU for handling its video drawing calls.

Perhaps the creation of a standard would not only create a standard for interchangable microcontrollers, but retro-computers as well. Of course, everything would have to be buffered and perhaps protected.
 
Last edited:
If the bus was 8-bit width only, this is what the hosted card connector pins would look like...which would fit on a 34-pin connector, with 4 pins to spare.

1706247762058.png
 
I just don't understand why so much focus on creating new 1980s style connectivity.
What I wanted was cheap and simple connectivity, additionally:
  • Have 8 slots
  • Have decent through-put
  • Allowing multiple of the same kind of device
  • Allow slotted device to (at least) request an interrupt state of some kind.
  • Requiring few support chips, and cheap at that, perhaps just bus transceivers
  • Help create an open interchangeable video card standard for micro-controllers
  • Help create an open interchangeable sound card standard for micro-controllers
This is a bit different than spinning a dedicated board for every device application.

~

Perhaps if the micro-controller was in the center with 4 ports on each side, them perhaps that would help with performance.
For cost, if the were made with only a 2-layer board, it might be a challenge to make sure the data and clock traces have an uninterrupted ground plane.
 
Last edited:
I just don't understand why so much focus on creating new 1980s style connectivity.
Hiya, haven't posted for a little while, this hobby been back-burned for a bit, but thought you'd be amused at what I'm trying to do - talking about 1980s connectivity.... Idea is for a modular eurocard sized MIDI controller, breaking out the serial ports on the teensy via a din41612 backplane connector, and I just had my first ever pcb made at JLC. Came to around £40 for the minimum 5 boards. Pretty pleased with it as a first attempt, and seems to basically work as envisaged, although I haven't fully tested it. Still a long way to go, though, and can already see ways in which I could improve it. Idea is to have a "master" teensy board, and have "slave" boards into the backplane, that essentially have RX/TX pins crossed over. DIN41612 is a 96 pin connector, fairly readily available, and eurocard rack cages seem reasonably affordable and functional. The PCB was really a rationalisation of things that I will almost always use, but broken out for ease of use -so, MCP23017 for LED button switches to use as selectors, 8 channel level shifter for 5-24v rotary encoders, and ILI9341 pins all in a straight line for ease of attachment. 4 pin JST connectors seemed reasonable for the LED button switches and the rotary encoders, although gotta say they're a PITA to crimp. Wanted to socket the IC's and teensy, in case I'd made errors and could reuse them. Here's a few pics, 1 of the blank PCB, 1 of the pcb with soldered connections and working encoders/LCD/LED switches, 1 of the card cage and a front panel I made, and the schematic from Kicad. Haven't used all the pins on the DIN41612, of course, and I posted a while back looking for suggestions on pin assignments. Not too much came back on that, so I came up with the one I used in the schematic. The suggestions in this post on using more GND pins between signal pins is one I'll certainly think more about. Be horrified, I'm old enough to remember the 80s :)

PH
eurocard pcb1_1.JPG
eurocard pcb1_2.jpg
eurocard pcb1_3.jpg
eurocard pcb1_4.JPG
 
Hiya, haven't posted for a little while, this hobby been back-burned for a bit, but thought you'd be amused at what I'm trying to do - talking about 1980s connectivity.... Idea is for a modular eurocard sized MIDI controller, breaking out the serial ports on the teensy via a din41612 backplane connector, and I just had my first ever pcb made at JLC. Came to around £40 for the minimum 5 boards. Pretty pleased with it as a first attempt, and seems to basically work as envisaged, although I haven't fully tested it. Still a long way to go, though, and can already see ways in which I could improve it. Idea is to have a "master" teensy board, and have "slave" boards into the backplane, that essentially have RX/TX pins crossed over. DIN41612 is a 96 pin connector, fairly readily available, and eurocard rack cages seem reasonably affordable and functional. The PCB was really a rationalisation of things that I will almost always use, but broken out for ease of use -so, MCP23017 for LED button switches to use as selectors, 8 channel level shifter for 5-24v rotary encoders, and ILI9341 pins all in a straight line for ease of attachment. 4 pin JST connectors seemed reasonable for the LED button switches and the rotary encoders, although gotta say they're a PITA to crimp. Wanted to socket the IC's and teensy, in case I'd made errors and could reuse them. Here's a few pics, 1 of the blank PCB, 1 of the pcb with soldered connections and working encoders/LCD/LED switches, 1 of the card cage and a front panel I made, and the schematic from Kicad. Haven't used all the pins on the DIN41612, of course, and I posted a while back looking for suggestions on pin assignments. Not too much came back on that, so I came up with the one I used in the schematic. The suggestions in this post on using more GND pins between signal pins is one I'll certainly think more about. Be horrified, I'm old enough to remember the 80s :)

PHView attachment 33100View attachment 33101View attachment 33102View attachment 33103
That looks really cool. The build looks instrument-grade, like it should say NASA somewhere on it.
Were card guides added later? Those connectors look a bit pricey, though.

[I had wanted to create the "Matrix" sequencer as seen in Reason--in hardware. I also wished I could think of some crosspoint switch kind of thing to connect synth modules on a bus, so their would be blessed knobs--but no wires, and the patch could saved, but all analog.
The first synth I used...was a Paia Gnome : ) ]
 
Last edited:
Back
Top