"DIY instrumentation bus" (or DIB)

[prasimix]

You're right. Addressing just 3 looks more reliable. Anyway, DIB pin mappings (and connector?) has to be changed, Back to drawing board .

[Doctorandus_P]

First post in this thread. My interest was awakened because I'm thinking about similar lines.
But simpler / less performance.

One of my idea's is to define "open space".
For example, if the backbone pcb has connectors of 5 cm high, then define the board height of for example 8cm, and 3cm are left deliberately open and for "user defined" connectors.
This leaves room at the side of the backplane for
- Standard Ethernet connector.
- Standard USB connector
- Custom board to board connector.
- optical fibre stuff.
- Thick power supply connectors for custom power supply or extra isolated power supply.
- other custom implementations.
For this to work, the backside of the backplane board would have to be accesible though.

Some other nice features would be to specify a bolt / hole patern on the side of the box, so another box can be easily mounted to it on the side.
Can for example be used for:
- Additional transformers / power supplies (Laptop power brick + low voltage SMPS).
- Keeping all mains voltages out of this box.
- storage space for USB hub / Ethernet switch.
- Connecting multiple modules together.
- Storage space for weird stuff (Rubidium standard).
- Adapter for mounting in a 19" rack.
- ...
A bit like the 100x100mm VESA wall mounting standard for monitors, projectors, industrial PC's etc.

Another Idea I've made some prototypes with is to glue a lego baseplate on a piece of wood, and lego bricks under a bunch of electronics components.
This works pretty nice to keep (somewhat bigger) temporary projects together, such as:
- several Breadboards.
- Small custom PCB's (for example MOSfet + inductor which is too high current for a breadboard).
- Strips with connectors for off-board connections (much more reliable than Breadboard alone).
- Logic Analyser ("24m 8ch").
- Beaglebone.
- Chinese panel Volt meter modules (with added isolated dc-dc converter).
- Homebrew AVR microcontroller board.

Some other thing I do not like much is the 40.46mm spacing.
Why not a nice round metrical number?
It is also an awful lot of height for a lot of modern electronics.
With a connector spacing of 20mm you still have plenty of height for most electronics. and if more is needed you can build a "double height" module.
Aluminum profile of 20mm is also common. and a frontpanel can be easily made by hobbyists by filing some corners out of such a piece of aluminimum and drilling some holes in it.

Just halving the distance between the connectors on your backplane would give 20.23mm spacing. Very close to standard 20mm aluminimum angle profiles, with a bit of room for mounting them.
Note that adding these connectors does not cost anything. You do not have to populate the connectors on the PCB.

This project is probably way over the budget for what I had in mind for myself.
I was thinking more along the lines of using IDC connectors and a simple ribbon cable as a backplane.
With ribbon cables you can also relatively easy make custom mods such as running separate wires from all boards to the same power supply. For the box itself I was thinking about something that can be easily 3d printed or made on a router.

@prasimix:
Both 10MHz and 100MHz clocks? (10MHz is the most prevalent standard).
I would use at least 2 pins each for the AC_HOT and AC_COLD power.
No UsART / RS485 / CAN?
About 10+ years ago I built an AVR/RS485 based network. which has been controlling things like curtains and lights for quite a while now. I like RS485. It is also much "higher speed" than I2C, but it is "overkill" for short cables.

Most Hobby / diy level users are probably never going to use the LVDS channels, but I do think that some bins reserved for "board to board" connect on the connector can be handy. I think it is a good idea to put that in the specifications.

Galvanic isolation between modules has been mentioned a few times.
A very easy and cheap way to do this would be to use a UART and a few optocouplers.
TxD pin goes through an optocopler to an open emitter single pin databus.
RxD has an optocopler to this same bus (with a resistor).
The TxD optocoupler would have to be able to deliver enough current for multiple RxD lines.
This is only half duplex of course.

[prasimix]

Thanks for your post. There is a lots of food for thought.

"Open space" sounds good, and that is already present in latest proposal and can be seen on PCB prototype for my first candidate for DIB backplane/enclosure here. DIB board connector occupy just a fraction of the PCB side facing rear panel. But, even if it seems that many space left available for other connectors it is not a case if you need cooling and fan could occupy most of them (all of usable 60 mm below DIB connector in my case). I presume that top or bottom placed cooling fan section is not an option.

40.64 mm is not my invention . It correspond with 8 HP (1 HP = 5.08 mm or 200 mils). Having a little bit over rounded 40 mm is a good for accept more tolerance for mechanical parts (i.e. metal front panel). But your suggestion to cut it in half have enough sense even for DIY/maker designs as long as some power management is not in question. Actually, I set 8 HP in accordance with what I need for my first DIB board . Having 4 HP (i.e. 20.32 mm) spacing sounds good. Other possibility is to allocate space for power boards "left" of MCU board (that can placed centrally) and use different spacing and even connector type on the backplane. Low-power boards with e.g. 4 HP spacing can remain on the right side as in the latest proposal.

I still don't have a real idea what to do with 100 MHz clock. That's something that is borrowed from VXI specification, and possibly is a overkill to be distributed to all slots. If two or more advanced boards need it they can be always connected with cable (that could be then even coax for better signal and lower EMI).

The good thing about LVDS is that AFAIK it can be found nowadays on many hi-speed ICs (e.g. ADC, DAC). Therefore hi-speed transfer between two points/boards could be simpler if processing power is centralized that handle many peripherals. If all hi-speed and intense processing jobs are performed on the same board then LVDS or perhaps anything over low-speed serial interface is overkill.
After I realize that "optimized" CS (chip select) with '595 doesn't work as intended and now more CS lines are needed I started again to think about "two connector" approach: basic/mandatory and advanced one where former should be used for low-speed signaling and data transfer and later for hi-speed.
Such approach should nicely address your prediction that most DIY users never going to use LVDS but also suggestion for low-speed galvanic isolation where optocouplers should be an affordable solution.

[prasimix]

Since it's now clear that chosen DIN connectors for both master and peripheral modules doesn't offer enough pins because more then one CS line is needed per module, I'm start to thinking again about PCIe as possible solution which @ogden suggested in #169. I have one question here: since it's possible to get PCIe as both THT and SMT I'd like to know does anyone have any experience or recommendation which one to use? THT variant has holes organized in 4 rows, while SMT has pads in just two rows. Which one is more economical (in number of min. PCB layers e.g. 4 or 6) and/or easier to route?

[jbb]

I like through hole connectors for this sort of thing because they are usually harder to knock off the board.  I see that a 2mm staggered pitch is available.

Size budget:

• 2mm pitch
• 0.7mm hole
• 0.25mm annular ring (times 2 for each side of hole)
• Gap between rings: 2 - 0.7 - 2*0.25 = 0.8mm
• Assuming 0.15mm trace & space, can fit 2 traces between. (Have to check PCB layer stack for controlled impedance.)

I think that you might be able to get a good number of tracks through in 4 layers.

Going to 6 layers gives up to twice the available area, but will really drive up prototyping costs.

• Sig
• Gnd
• Sig
• CORE
• Sig
• Gnd
• Sig

[prasimix]

Yes, it seems that routing diff. traces between two pins is doable in the following manner:

(pad)
(space between pad and trace) 5 mils
(trace width) 6 mils
(space between traces) 6 mils
(trace width) 6 mils
(space between pad and trace) 5 mils
(pad)

That 5 mils spacing can generate additional cost of manufacturing but it's still way cheaper then switching from 4 to 6 layers. With PCIe we could use 64-pin for peripheral modules (increase of 16 pins) and 164-pin for master/CPU module (increase of 68 pins!). That will give us more possibilities for additional CS (chip select) and perhaps also for adding of "slow speed" channels if someone really don't need/like LVDS as only/mandatory way of communication. Also with PCIe connector that has higher pins density we can think again about basic/advanced configuration, i.e. one connector for mandatory system signaling + low-speed communication and another for hi-speed communication between master and peripheral modules and signal switching/distribution between peripheral modules.

[carljrb]

This seems like an interesting but perhaps over-ambitious project. At this point, it seems quite unclear what kind of instruments you expect to be built for it, or who it's designed for.

Most instruments talked about would not be a great fit for such a rack. For example:
-good lab-grade power supplies typically need AC power, generate tons of heat and are very bulky (big transformers and heat sinks)
-loads generate a ton of heat, use a ton of space (large heat sinks and fans) and need a ton of ventilation
-"higher end" instruments like arbitrary signal generators, scopes and logic analyzers (which are better than cheapo ebay logic clones) will most likely be held back by various limitations this design

On one hand, "hobbyist" modules are pretty much guaranteed to misbehave in many ways (buggy software, incompatibilities, conducted and radiated emissions, etc), and those who build "fancier" instruments most likely will object to various design choices and limitations. Then again, it's vastly too complex and pricey for the "arduino crowd", and too limited for serious stuff. That leaves an awkward zone right in the middle for (...not sure what?), which will somehow need to be calibrated against better instruments which most people won't have access to.

There's a bunch of other general factors that will probably stop a lot of people:
-a one man team, which always means that things like support/future development and such is anything but guaranteed. Especially when it's from a hobbyist, because most hobbyists soon find a new exciting project to start and drops the current one before completion...
-no guaranteed backward compatibility in future designs/versions (who wants to spend $500 to make a prototype today which could be obsolete next week?)
-the old catch 22: both the software and hardware guys will wait on each other basically...

Making a backplane is IMO by far the easiest part of this all. The hard parts will be coming up with a good standard, getting other people involved (interest groups? academia perhaps?), seeing what kind of needs those people would have and how that standard will be helpful now (it's got to be very clearly better than the other options somehow) and how it'll expand in the future, getting things documented properly, there's lots of code to write and so on. Adding a few mounting holes and differential traces on a PCB is the quick and easy part.

Meanwhile, there isn't even the most basic 3D design (that'd take perhaps an hour in solidworks or fusion 360) so the PCB shapes and overall placement of things is likely not to work out... And the enclosure design seems like it could be a problem to many. Most people don't have access to milling machines and other similar machinery. It's not like you can build stuff like this (with a good fit and finish) with just a hacksaw and a hand drill. Getting metal plates custom cut to size, with the necessary openings and holes, plus shipping... Plus all the other hardware (again, with cuts and all) and fasteners, with shipping from other/different suppliers... That seems like a lot of time and hassle, and not much cheaper than buying something like a pre-made, modular system. I for one would sooner buy a vectorpak subrack  or the like (and I'm used to getting quotes for custom parts).

Developing for this would be too expensive for a lot of people. Just the PCB prices alone will probably discourage many. The absolute cheapest 194x88mm 4 layer board (the size of the backplane) is ~$65, and the typical daughterboard size (170x145mm) in 4L, with gold fingers (I'm hoping the bevelling is included, and proper hard gold plating, not just an ENIG finish!) starts around $100 per board, with few available manufacturers (basically locking you into the cheapest manufacturer's choice of stackup).

Also, the project seems to ignore all already established protocols and standards (USBTMC, VISA, SCPI, LXI/HiSLIP, etc) which works well with existing instruments and code, which would make the instruments most likely less useful overall. Also, it's unclear how the current choice of interconnect is an improvement over cheap, well-established stuff. 100MHz SPI is kinda slow. USB2 is much faster, as is Ethernet (isolated too), and of course USB3. They're cheaper, vastly faster and also bi-directional (there's a good reason "low end" keysight/NI systems uses USB!)

The choice of XMOS (a fairly non-standard architecture, with a non-standard language, from a minor player) is a deterrent IMO. It's too slow and doesn't have enough memory for a lot of stuff. Here again, there's a reason most systems use a beefy CPU or directly connect to a PC. A dual-core XMOS loses to a Pentium MMX from 1997. A single desktop-class CPU like an AMD 1800X is *literally* a million times faster, and the situation is much worse if you consider things like GPGPU (with mainstream consumer GPUs) or even cheap 2nd hand Workstations with fast Xeons, tens of GB of RAM, tons of fast storage, along multi-monitors and all... Having it also drive an LCD display will only make it more of a limit, for an interface that's so minimalist that it might as well not be there (two encoders for 4 instruments plus a master?) Again, I think there's a good reason there isn't one on such systems from big players... It's just too limited.

Then of course, you need to get everyone to agree on CAD tools, programming languages, coding styles, protocols, licenses, documentation, etc. That's a major undertaking in itself!

Not that I agree with software being the main "limit", or the main thing people need help with. There's tons of that at *every* level of the design, and so far a backplane (or any other type of interconnect or cable of any kind) and enclosure aren't solving that problem either.

Sorry if it sounds harsh. I tried my best at constructive criticism. If anything, I think you should reevaluate what it's trying to accomplish (like: what it does better and why it's a better option) before routing more traces on backplane version N+1.

[prasimix]

Thanks for your lengthly reply. Let's go back to the beginning: this topic was opened to discuss possibility to define "bus" that should address building T&M instruments that belongs somewhere in between existing entry-level/low-cost and commercial solutions (nothing more, nothing less ).
I'm still attracted with idea about modular and well connected instruments as better solution then have many stand-alone, "portable" (and often "naked", i.e. unprotected even with most basic enclosure) instruments on my benchtop while I'm experimenting, measuring or building something. I don't even need to mention open source approach that is mandatory for me.

An idea of what kind of instrument I'd like to have over time one can get from #76. Lots of energy was spent about pro's and con's of speedy USB and Ethernet. I believe that VXI as an example of big guys solution is also mentioned somewhere and that "DIB" should be something less demanding but still useful people who is not interesting in collecting new neat "eBay grade" gadgets. Regarding already established standards, I'm well aware or them, SCPI is already discussed here and when I decide to make an open-source programmable benchtop power supply (aka EEZ H24005) we tried to follow SCPI "way of thinking" and that helped us a lot to structure firmware in the right way. One of the end result is visible here. Also our dedication to the SCPI & Co. is clearly visible in open-source multi-platform EEZ Studio.

So far people did a great job to discourage me to move this forward and to stick for various reason to the existing solutions (either entry-level or commercial one). That's fine, I have no illusion (I'm not delusional, saying in English, right?), nor have ambition (vision?) that DIB can became anything even closer to the most unsuccessful specification/standard.
My call was based on a guess that "DIB" idea could attract people which are experienced in the field of T&M and come out with suggestions that can be used to eventually build something for the common good. Perhaps I'm not a good listener, and cannot spot details, since so many people told me what you've also repeated, that is too big challenge for one person. Indeed, that is true, and everyone is still invited to spend a little bit more time trying to addressing in more detail any part of this concept instead of repetitively let me know how that is not possible, or that is not worth to do. The question is not worth of what? Somebody time and money? But it seems there is an abundance of time and money when you see how people spent their resources. Ok, we have to make a strict distinction about creators and consumers and that former have less resources to spent the later. But this call is not directed to consumers. Its directed to creators (what I'd like to become, since I'm in the best case skilled-enough builder). Ok, if creators are already busy with their own ideas and creation, then lets forget DIB (this "call" for mission impossible). I'll try within my limited resources (knowledge, time and money) to make something out of it with people like @jbb who already assisted me in most constructive way and keep you informed about our progess, mistakes, success, etc.

[prasimix]

It's a time for an update of this topic since Bench Box 3 is progressing well, and helped me to define needed set of functionalites to make connection between MCU and various lo-speed periperal modules.

This specification defines four physical connectors: two mandatory (MCU 40-pin and Peripheral module 28-pin) that are related to DIB backplane and two optional, one (16-pin) that defines power connection when the EEZ DIB AUX Power supply is used for powering MCU and backplane, and another (20-pin) that allows coupling of power sourcing module output terminals such as DCP405 power module.

Connector's pin mappings are presented in the picture that follows. All connectors contain two rows hence pin mappings description is separated in two columns (A and B). Direction (Dir column) when applicable shows unidirectional signal flow referenced from the inserted module, not backplane.



For example, NRESET on the MCU module connector is assigned as an output (O). Therefore the same signal represents an input (I) on the peripheral module connector. Bidirectional signals have the same direction mark (I/O) on both sides (MCU and peripheral module).

MCU module connectivity

A 40-pin (2 x 20-pin) right angled pin header and receptacle with 0.1” pitch are used for making connection between MCU board and DIB backplane. Receptacle is used on the MCU board side while header is on the backplane side. The MCU module provides the following power and signaling lines:

• +5 V pass-thru power output (from the AUX Power Supply)
• +12 V pass-thru power output (from the AUX Power Supply)
• +3.3 V low power output (provided from the MCU board LDO, max. 20 mA per module)
• +3.3 V backup, low power battery backup output
• Reset output (active low) and Fault open-collector signal
• I2C bus (SSCL and SSDA, 3.3 V level) shared between all peripheral modules and AUX Power Supply
• Async UART (RX and TX, 3.3 V level) shared between all peripheral modules that can be used for firmware uploading of the peripheral modules' on-board MCU if it does not support SPI for such operation
• Three dedicated SPI buses (SCLK, MISO and MOSI for CH1, CH2, CH3) and two device select lines (CSA and CSB for CH1, CH2, CH3) that allows addressing of up to four SPI devices on the peripheral module (using 2-to-4 line decoder like SN74LVC1G139)
• Peripheral module interrupt (IRQ for CH1, CH2, CH3)
• SYNC output for synchronizing activities between two or more peripherals, e.g. OE (Output Enable) of power sourcing peripheral modules.

Although only three SPI buses are defined with DIB v1.0, that doesn't limit max. number of peripheral modules to three. The DIB backplane can be designed in a way that two or more peripheral module connectors share the same SPI bus. If more device select (CS) lines are required, a SIPO register (e.g. 74HC595) can be used to address up to eight SPI devices. Addressing more SPI devices can be accomplished by deploying two or more daisy-chained SIPO registers.

Peripheral modules connectivity

Power and signaling lines for the peripheral modules are provided with 28-pin (2 x 14-pin) 0.1” pitch right angled pin header on the side of the peripheral module and receptacle on the backplane side. The peripheral module connection includes the following power and signal lines:

• +5 V input (from the AUX Power Supply)
• +12 V input (from the AUX Power Supply)
• +3.3 V low power input (provided from the MCU board LDO, max. 20 mA per module)
• +3.3 V backup , low power battery backup input for e.g. standby
• Reset input (active low) and Fault open-collector signals
• I2C bus (SSCL and SSDA) shared between all peripheral modules and AUX Power Supply
• SPI bus (SCLK, MISO and MOSI) and two device select lines (CSA and CSB)
• Interrupt output (IRQ)
• SYNC input for synchronizing activities between two or more peripherals initiated by MCU
• Module identification inputs (A0, A1, A2)
• BOOT input
• Shared async UART (optional)

The BOOT input can be used with peripheral modules that comes with on-board MCU and which firmware could be uploaded via SPI or UART. If BOOT input has to be dedicated (i.e. one per module) that only one on-board MCU can be put into bootloader mode after the reset (power up) a DIB backplane can be equipped with I2C I/O expander that could provide one BOOT control signal per module.

The module identification inputs can be used as device selection for I2C peripherals such as on-board EEPROM, temperature sensors, etc. When used for EEPROM addressing the 000 address cannot be used since it's assigned to the I2C EEPROM on the MCU board. Inputs A0-A2 require pull-up resistors connected to +3.3 V (e.g. 10 KΩ) on the peripheral module PCB. Module position on the backplane is defined by “hardcoded” wiring of A0-A2 to GND.
Please note that #0 position should not be used to avoid possible conflict with already mentioned EEPROM on the MCU board and also other devices in the future.

When selecting I2C EEPROM pay close attention on its addressing capabilities even if it provides three address inputs. Many low capacity devices can effectively use only a single input for addressing purposes.

If two or more modules have to be galvanically isolated (e.g. like in case of power modules with floating outputs) use appropriate isolators (e.g. Silabs Si86xx, Maxim MAX14850) for control and data lines.

AUX PS module connectivity

The main purpose of this connection is power delivery for MCU board and peripheral modules. Two voltages are specified with DIB v1.0: +5 V and +12 V. Additionally, two lines are assigned to +3.3 V auxiliary powers: a) +VAUX as (battery) backup and b) +3.3 V that is sourced from the MCU board LDO and can be used to power e.g. an I2C low-power (max. 20 mA) device like fan controller. This connection contains also the following functions:

• Shared I2C bus (SSCL, SSDA) for fan controller or similar devices
• AC Soft-start/Standby control inputs (PWR_SSTART, PWR_DIRECT)
• Reset input (active low) and Fault open-collector signal
• PE (Protective Earth) output
• MBOOT output for define MCU bootloader mode

Power sourcing module connectivity

This connection is optional, but its physical location should be taken into account when peripheral module PCB is designed to leave that area unpopulated to avoid possible issues with inserting peripheral module into the DIB backplane that includes this connectivity (e.g. EEZ DIB BP3C backplane). Therefore it is highly recommended to follow the peripheral module PCB template available on the project's GitHub repository.

A 20-pin (2 x 10-pin) 0.1” pitch right angled receptacle is used on the side of peripheral module and straight pin header on the DIB backplane side. Pinout scheme is rather simple: it provides power terminal inputs and outputs that are assigned on multiple pins for increased current capacity. Allocation of five pins per power lines should be sufficient to carry 5 A continuously.

The idea behind output terminal coupling is to avoid usage of external wiring as it is accomplished on the EEZ H24005's Arduino Shield board by using power relays for reliable connection under MCU control.

If peripheral module such as DCP405 power module is deployed, this connectivity becomes mandatory on the DIB backplane. If no coupling capabilities are provided, a simple pass-thru connection (i.e. IN+ to OUT+ and IN- to OUT-) has to be made to ensure normal operation of such module.

Peripheral module PCB dimensions

The DIB v1.0 specifies only the physical dimensions of the peripheral module and related connectors (i.e. 28-pin peripheral module connector, and optional 20-pin power sourcing module connector) positions. Dimensions of other parts of the system (e.g. MCU board, backplane, power supply module) can differ from project to project depending of e.g. chosen enclosure dictated by builder budget and appearance preferences. Allowed dimension of the peripheral module is shown below.



Thanks to the fact that DIB connectors are located at the bottom end, the PCB width can vary and it could be anything from 90 to 185 mm. In fact it could be even wider, but this is recommended if the EEZ Bench Box 3 design is used. Recommended PCB height is 95 mm but it can also vary in accordance with selected enclosure, and that is a max. height for the EEZ Bench Box 3 design.

Distance (horizontal pitch) between two peripheral module connectors is 35.5 mm (7 HP) and could appear that is somewhat too large for today's standards and components. Such distance is selected to allow mounting of larger heatsink elements on the peripheral module that is beneficial for power sourcing and sinking modules where increased power dissipation is expected. Still, the specified modules distance does not limit builder to design a backplane that combine few DIB v1.0 modules (i.e. 7 HP wide to “comply” with specification) with thinner modules (e.g. 5 HP).

Note that even if peripheral module does not require 20-pin power sourcing module receptacle, related PCB area has to remain unpopulated to avoid issue with inserting peripheral module into DIB backplane which has that connector.

Peripheral module front panel contains two pairs of holes for fixing it on the peripheral module PCB and to the DIB enclosure front panel.

DIB 3-slot backplane example

The DIB backplane shown below is an example of possible DIB v1.0 backplane design. Its design is used for making the BP3C backplane for the EEZ Bench Box 3. It provides connectivity to up to three peripheral modules which can also be a power sourcing modules. Therefore both 28-pin peripheral module connector and 20-pin power sourcing module connector are included for each slot.



Peripheral modules are inserted in this backplane vertically, and this is a mandatory, while MCU board is connected horizontally which is not a mandatory orientation. If a backplane is designed to accept MCU board vertically, and positioned on the far right of the backplane, the same horizontal pitch (7 HP) has to be used for MCU 40-pin connector as for the peripheral module connectors.

It is recommended that PCB with min. two layers is used and filled with huge GND planes.

Your comments are welcome as usual.

[jbb]

Hi prasimix

It's nice to see some hardware on the bench; now you'll really see how well it works.  I hope you get everything finished by your deadline.

In terms of 'Optional' bus signals, it would be nice to see some frequency/timing distribution; maybe a 10MHz ref, a 1 second pulse, an uncommitted 'event' line and another ground?

I assume you're using the existing concept of fitting an I2C EEPROM to each card for ID purposes? Do you have a fully defined table of addresses?

Card Slot	I2C Address
0 (Master)	0x??
1	0x??
2	0x??
...	...
7	0x??

Some time ago we discussed data structures for an I2C EEPROM.  I spent a while drawing complex data structures with Excel but, in hindsight, this wasn't the best use of my time.  As we are looking at a much simpler bus these days (compared to previous efforts), I think that the EEPROM should start off with a simple data structure that contains only a small amount of information.  I suggest:

Address	Field Name	Field Contents	Length (B)	Notes
0	DIBVersion	DIB interface version x.x.x.x	4
4	CardManuf	Manufacturer Name (UTF-8, 32 char max)	129	UTF-8 takes up to 4B per character, length encoded expliticly
133	CardName	Product Name (UTF-8, 32 char max)	129
133	CardVersion	Card HW version x.x.x.x	4
264	CardSerial	Serial # (UTF-8, 32 char max)	129	Set length to 0 for no serial number
395	ExtraDataStart	Extra data field start address	4	Set to 0 for no extra data
399	ExtraDataEnd	Extra data field end address	4	Set to 0 for no extra data
403	HeaderCRC	CRC32 for above record	4

Features:

• Use of strings for manufacturer and product hopefully removes the need for a centralised numbering control body (compare with USB VID, PID)
• There is just enough data to fully-define a card (manufacturer, product, version)
• The use of a fixed-size data structure makes it easy to parse
• Explicit lengths on strings can help parse unicode strings (but use of Unicode strings at all may be overkill)
• CRC is included to detect I2C read errors (which may well occur on this bus!)

The 'extra data field' isn't defined at this point; it's a slice of memory in the EEPROM.  The encoding would be left up to the manufacturer of the card, but I would suggest that whatever is used include a CRC32 protection at the end.  Possible data formats: more predefined tables, a Tag Length Value (TLV) string, XML string or JSON string.

[prasimix]

Hi prasimix

It's nice to see some hardware on the bench; now you'll really see how well it works.  I hope you get everything finished by your deadline.

In terms of 'Optional' bus signals, it would be nice to see some frequency/timing distribution; maybe a 10MHz ref, a 1 second pulse, an uncommitted 'event' line and another ground?

Idea is to expand peripheral module connector with optional signals or even introduce additional connector if needed. But, I'd like to leave that for some future revisions when more complex module come into picture. So, all what we discussed are good candidates for next DIB specification.

I assume you're using the existing concept of fitting an I2C EEPROM to each card for ID purposes? Do you have a fully defined table of addresses?

Card Slot	I2C Address
0 (Master)	0x??
1	0x??
2	0x??
...	...
7	0x??

Yes, and backplane has A0-A2 lines as you proposed that is hardcoded that each slot has different address. I2C EEPROM on MCU board is hardcoded to 000.

Some time ago we discussed data structures for an I2C EEPROM.  I spent a while drawing complex data structures with Excel but, in hindsight, this wasn't the best use of my time.  As we are looking at a much simpler bus these days (compared to previous efforts), I think that the EEPROM should start off with a simple data structure that contains only a small amount of information.  I suggest:

Address	Field Name	Field Contents	Length (B)	Notes
0	DIBVersion	DIB interface version x.x.x.x	4
4	CardManuf	Manufacturer Name (UTF-8, 32 char max)	129	UTF-8 takes up to 4B per character, length encoded expliticly
133	CardName	Product Name (UTF-8, 32 char max)	129
133	CardVersion	Card HW version x.x.x.x	4
264	CardSerial	Serial # (UTF-8, 32 char max)	129	Set length to 0 for no serial number
395	ExtraDataStart	Extra data field start address	4	Set to 0 for no extra data
399	ExtraDataEnd	Extra data field end address	4	Set to 0 for no extra data
403	HeaderCRC	CRC32 for above record	4

Features:

• Use of strings for manufacturer and product hopefully removes the need for a centralised numbering control body (compare with USB VID, PID)
• There is just enough data to fully-define a card (manufacturer, product, version)
• The use of a fixed-size data structure makes it easy to parse
• Explicit lengths on strings can help parse unicode strings (but use of Unicode strings at all may be overkill)
• CRC is included to detect I2C read errors (which may well occur on this bus!)

The 'extra data field' isn't defined at this point; it's a slice of memory in the EEPROM.  The encoding would be left up to the manufacturer of the card, but I would suggest that whatever is used include a CRC32 protection at the end.  Possible data formats: more predefined tables, a Tag Length Value (TLV) string, XML string or JSON string.

Module's EEPROM definitely has to include information similar to what you are mentioned, and we'll have a plenty of room for "extra data fields" for simple reason: the min. EEPROM size has to be 32K. I found that in hard way, starting from 1K and going up, and finally realizing that only EEPROMs starting with 32K could be effectively addressed with all three address lines!

Martin is still working on other issues with STM32 MCU board, and when he starts to work on software parts of DIB concept, I'll post more details about that.

[msat]

The forum software is trying to make me feel guilty for reviving an old thread.

I recently created a thread about a similar project (https://www.eevblog.com/forum/oshw/open-bus-architecture-for-instrumentationcontrol-(vme-vxi)-feedback-wanted/) and was referred to this one. I finally got through this and found numerous aspects of what was discussed here to be similar to what I've been thinking, so perhaps that's a good indication that I'm heading down the right path. It also brought up some potentially important things that I haven't considered, such as:

A) Trigger signal on the bus with the source being either external or internal. Should have been obvious

B) Special power supply requirements for some modules. So I was mainly thinking of sticking in something like an ATX PSU to provide many of the common logic voltages in the instrument rack. For the various things where such a power supply won't suffice, I was thinking that another rack whose primary purpose is to house PSUs could be set on top or underneath of the instrument rack, with the outputs being jumped in the back. So basically each module slot on the instrument rack would have a connector coming through the backplane which would be an external PSU input.

C) The importance of trying to comply with USBTMC and SCPI. From my current design plans, compliance would be partially placed on the module designer, so no guarantees. That said, I'm not entirely dead set on USBTMC.. As I mentioned in my thread, I also like the idea of enumerating the instrument bus as a mass storage device with virtual file(s) representing the modules. SCPI commands or whatever could be written to/read from these files. So in theory, you can possibly test/operate modules with a text editor. It might not be too much work to support both methods.

So I'm more and more trying to avoid the "everything plus the kitchen sink" approach. I don't want to reduce features to the point to where it's useless, but I also don't want to add features that are likely to be useless for all but the edge cases. Also, and I mean no offence, but this won't be a "design by committee". I just want feedback in an effort to avoid any gross oversight on my part.

Pretty much everything is up in the air, but if one thing is for certain it's that this is a module bus <-> host computer via USB interface design. There won't be any intentional support for inter-module comms or a computer-on-bus. Also, all modules are expected to have an MCU/FPGA for command encoding/decoding. The USB transceiver on the bus is intended to be little more than a low-level protocol translator.

Right now, I'm thinking of proceeding one of two ways:
1) As I mentioned in my thread, going with a 16-bit wide and up to 100MHz bus using a Cypress FX3 USB3 peripheral controller, with a theoretical max bandwidth of 1.6Gb/s. Each module will control the bus clock when they communicate with the FX3, so they can run at an arbitrary speed up to 100MHz. Since only one device can communicate on the bus at a time, slow devices can choke up the bus. It might be a good idea to allow prioritizing modules. The other downside is that this requires 16 + some additional pins for control and clock, meaning tiny micros are out of the question. The other thing is that many micros won't have native parallel bus hardware, so the bus would have to be bit-banged (er, word-banged?). That said, I foresee it being a pretty simple bus that's tolerant to significant jitter, so it shouldn't pose a big issue. I don't think.... The FX3 also has an SPI and I2C peripheral - I'm not sure if I want to throw those on the bus.

2) There's a few microcontrollers from ST that supports USB2 hi-speed and 5 SPI ports with 3 @ 50mbit and 2 @ 25 for a total of 200mbit bandwidth - obviously much less than the FX3. The thought here is that all 5 SPI buses run to all module slots. Any module can use multiple SPI ports for bandwidth reasons. Also, multiple devices can be communicating simultaneously, so that way a slow device doesn't eat up all the bandwidth. For best performance, this would require modules to be able to jump to different SPI ports depending on availability, so either the module's mcu would need to support flexible pin mapping for it's SPI port (eating up pins in the process), or either the modules or the bus itself would need to contain a MUX. If the MUX isn't on the bus, it would be worth allowing simple modules to request use of only one SPI port on the bus at the expense of potentially greater latency. The benefit with going SPI is that it has decent bandwidth (for many applications), and is widely supported on even cheap MCUs - meaning there is minimal processing overhead for transceiving. That said, this idea isn't particularly elegant and for best performance can either eat up a bunch of pins or require a MUX. I think I prefer the first method for the most part.

[prasimix]

Thanks for stopping by and sharing some of your thoughts and leaving a link to the topic you opened.

You are right that “design by committee” is not the right path, i.e. it easily leads to nothing. This almost happened with my proposal for DIB, but I continued to work on it myself and some result was eventually achieved: EEZ BB3 about which there is a discussion about the development here, and about the crowdfunding campaign here.

I can also notice that you tend to cover everything from the first try: high-performance hardware and one that couls have a $1 MCU in the core. I started with such ambition myself, but then I cut it by putting the emphasis first on low performance hardware for which one SPI channel per slot should be enough. From the very beginning, I thought of DIB as something that others could benefit from, so as a basis for open T&M hardware. As many have seen so far, open hardware is significantly different from open software because it is not easy to gather more interested people around it because it requires much more than a PC and internet connection. That’s why I think it’s important to lower the entry barrier as much as possible because it’s one thing to try to design something on a gigabit bus and another on an SPI of a couple of Mbps.

I believe that the DIB concept will become successful when the first module appears independently developed, albeit with the support of the EEZ team (i.e. Martin and me ), and the micro community gathered on this forum and on the Discord server.

I don't know anything about the capabilities of today's USB controllers, but somehow it seems to me that the LVDS with a FPGA as a controller/dispatcher is a much more flexible option. This will most likely be in the core of the DIB v2 extension, and the first candidate for this is the integration of the ULX3S project which is currently being worked on.

The detail that distinguishes DIB from your proposal is that from the very beginning I wanted to have local control. For this we have a TFT color touchscreen and I think many have recognized this as an important feature: especially when the device is ready for action in about 3 seconds .
I was guided by the idea of ​​a DVD player (open source if there was one!): You turn it on, insert the media and watch, unlike turning on the PC, clicking on the menus to start the media player and choosing what you want to watch. When all is well it can go very quickly, however we know that this is often not the case for a variety of reasons.
We didn't stop at offering just "play/rec" actions, but we also added MicroPython so that some more complex usage scenarios could be created and had on the device itself, without the need to depend on the PC.

That’s not to say we didn’t think about how to connect to the PC and the rest of the world: the EEZ Studio cross-platform was developed for the PC which has two components: a visual GUI editor and a SCPI controller (for BB3 but also third-party instruments). The GUI editor allowed us to not depend on other tools (as in the case of choosing Nextion or similar HMI). The SCPI controller allows us to communicate with the device without paying expensive licenses for additional software (e.g. LabView, BenchVue, etc.).
Furthermore, we started adding MQTT, so BB3 has become a device that can be integrated into a growing IoT infrastructure.
All of the above is anything but easy to support (we still miss e.g. USBTMC).

[msat]

Oh, wow! The EEZ BB3 and various modules look great! Nice work! It'll take me a while to make it through those threads, but I plan on it and hopefully they inspire me.

I have nothing against integrated computing, and your fast-boot example is compelling. Rather, since I'm looking for something to fulfill my wants and style of workflow, is why I'm going for external compute via USB interface. This is one of those things that has no right or wrong answer 

Last night while lying in bed I realized that if I go with the FX3 controller (which I think I probably will), then I'll put its SPI peripheral on the bus. It would be stupid not to since many module's comm requirements would be perfectly satisfied with the bandwidth it provides, allowing potentially small micros to be used, and also freeing up the parallel bus for modules with high performance requirements.