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.

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.
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.

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: