I really like the idea of having an open-source mainframe style instrumentation architecture, but I really don't foresee it taking off as a decentralized, ad-hoc pseudo-standard as you've laid it out.
In order for a backplane system to be successful it must:
- Have a defined way of managing interconnect resources and resolving conflicts (ie, I2C address collisions, allocation of cross-connect channels).
- Assure that modules do not interfere with each other--the massive switching converter on someone's DIY power supply module shouldn't be allowed to introduce a bunch of noise that will interfere with someone else's precision voltmeter module, for example.
- Have a defined way of managing power budget.
- Have maximum bandwidth, line loading, and voltage level characteristics defined for all bus connections.
- Once you've defined all of the requirements above (and many more), in order to achieve reliable interoperation you must ensure that all developed modules comply with those requirements.
The more complicated the interface is, the less interest there's going to be in developing modules for it, and the harder it's going to be to ensure that those modules are compliant.
Regarding the 'CPU card', I'm wary of this idea. Maybe if it's a raspberry pi, but this is another area where the software support must be developed and behaviors defined...it's also an additional cost and amount of effort that may not be necessary if the instruments can simply be connected to an existing lab PC instead.
The bottom line is, the more complicated this is to implement the less participation you're going to get. The more options and loopholes and behaviors are left undefined, the less interoperability you will get. If you want any chance of this succeeding:
- Fully define the behavior of devices on the bus.
- Minimize the hardware requirements for instrument devices so that defining requirements (and then implementing them) isn't an insurmountable amount of work.
- Provide portable, easy-to-customize libraries for the interface.
- Provide working reference designs for a few basic devices.
If you really want to stick with a backplane/mainframe system, I don't see that being successful until someone designs and makes available for sale a complete mainframe system and several instrument modules that work out of the box (which means doing everything in the list above first!) and doesn't cost an arm and a leg. Unfortunately I think the cost aspect is what really makes the mainframe idea a non-starter. Low volume means it's going to be expensive to manufacture even before you try to recoup the engineering time to do all of the hardware and software development, and no one's going to want to spend $500 on an empty mainframe that they now have to spend hundreds of hours and hundreds of dollars developing hardware to plug into it.
Again, I really like the mainframe idea in principle, I just don't see it being successful as a framework for DIY instruments. I think maybe it makes more sense to consolidate around an existing interface with maybe a thin wrapping that adds one or two really useful features that requires minimal hardware and can be used to link multiple instruments directly to a PC. Build up some nice open source libraries for it and a few reference designs, then focus on developing a nice software suite to run it, and make sure it's easy for people to integrate their own instruments into the software. Maybe require compliance with SCPI standard instruments, and have a nice profile builder tool for custom instruments.
I'd like to make power supply module as first example that use this bus. But this time such module will carry end-to-end functionality, i.e. AC/DC SMPS pre-regulation and linear post-regulation. Therefore 3rd party AC/DC adapter (currently it is Mean Well) and DC-DC SMPS pre-regulator should go out of the picture.
I like the thought of an accessible, (largely) open-source instrument spec, and I'm glad to see someone having a go. I believe that the engineering school at EPFL (Lausanne, Switzerland) did something with ARM host processor and USB rack backplane, but can't seem to find any info on it (maybe died of neglect when critical students finished their PhDs).
Here are some thoughts:
- I expect DIYers like DIYing. So it's important that people feel that they get some benefit from the spec rather than just building whatever.
- People will be tempted to skip 'difficult' or 'annoying' bits of the spec. There may need to be an 'official' test scheme to say that yes, such-and-such is sufficiently compatible (note: this could be a self-test and the developer fills in a report card. No need to spend mega-bucks at a lab.). Writing such test procedures is, unfortunately, difficult and time-consuming.
- Sorting out a connection or racking system is really important. If it's a racking system, the not-at-all simple act of saying 'here are the card dimensions, here's a comprehensive parts list, you can buy them from vendors X Y and Z' is critical. There are probably some good Aliexpress options, but someone needs to research, acquire and check out some samples.
- Great example projects would be important as a springboard for widespread adoption.
On the electronics/communications side, I think that:
- Having some kind of card ID system (e.g. using I2C) with well-defined data structures is a good idea. That way the master can either a) use the right driver or b) complain. Could also store calibration info.
- Facilities for isolation should be available (e.g. 5V/12V DC supply sufficient to run isolator systems) and easy for module designers to use.
- Low bandwidth modules (e.g. DC power supply) don't need much bandwidth, so they should be able to use a cheap connection. (We don't want to pay for an FPGA in a basic DC supply...)
- Medium/high bandwidth modules (e.g. analog capture or DAC) need more bandwidth (and probably clock + trigger distribution), so they will need a more capable connection (and there people might be willing to pay for an FPGA).
- The module designer should be able to choose what goes into their module, so the comms should be fairly generic and vendor-independent.
I would suggest a tiered comms system, where the designer picks the appropriate level:
- Card ID (e.g. I2C or SPI bus) + basic low speed comms
- Clock and trigger distribution
- High bandwidth
I'd like to make power supply module as first example that use this bus. But this time such module will carry end-to-end functionality, i.e. AC/DC SMPS pre-regulation and linear post-regulation. Therefore 3rd party AC/DC adapter (currently it is Mean Well) and DC-DC SMPS pre-regulator should go out of the picture.
Err, I love power electronics, but I'd be a bit nervous about promoting built-it-yourself power supplies with large quantities of 380V DC inside (after PFC stage). If you look through my post history I'm the often saying 'safety safety safety!' to people, 'cause I don't want anyone to get killed. Maybe part of the spec should include an 'external' type connection so the scary power stuff can be put in a separate enclosure?
Also, I'd like to be involved :-)
If you talk about Easy ? it is still around.
Communication between modules
The basic communication between processor and peripheral modules is SPI where for each module a separate SPI channel is dedicated to enable parallel operation, assuming that the CPU/MCU is capable of doing something like this, as in case of the mentioned XMOS xCORE. If other MCU is to be used then it will be necessary on the processor module to merge multiple SPI channels to what the MCU (at least on the physical level or pins) offers separately. Plenty of MCUs have several SPI channels, the other thing is that there is still just one processor core that have to deal sequentially and not in parallel with the connected peripherals.
SPI channels have three signals SCLK, MOSI and MISO. The question remains what about CS (Chip Select) which is also needed if we have more than one SPI device on the same SPI channel. For this purpose, pins #CS1 to #CS7 are foreseen. Now, this would mean that it is possible to have only one SPI device per module. However, with simple trick it become possible to address x peripherals. We have to deploy a SIPO register such as '595 for addressing up to 8 peripherals, of more if they are daisy-chained (16, 24, etc). Of course, the greater the number of SPI peripherals on the module, the access time could be slower. However, since the '595 has access speed that largely exceed the usual SPI speeds, it would in this way greatly or wholly neutralize the delay of such addressing. E.g. if the SPI device with max. speed of 4 MHz is used, and there are up to 8 of them, if the '595 is accessed with more than 30 MHz first, and then proceeds with SPI communication at 4 MHz, the end result should be the same as if '595 is not present at all. Furthermore, I assumed that we could have a very fast SPI devices on the first two slots (closest to the MCU!) and want them to access with, say 20 MHz. In that case, the '595 signaling could also go over 100 MHz. For this reason it is envisaged that CS1 and CS2 can be differential, so we have #CS1 Diff+, #CS1 Diff-, CS2 Diff+ and #CS2 Diff-.
I spent some (but possibly not enough) time to find out what kind of connectors are available with good price/performance. It seems that DIN 41612 are very attractive with price around 2 USD, good pin density and mechanical strength. All your suggestions are highly welcomed.
Ok, I can see here two approach: a very simple reading out 8-bit register that has hard wired ID number (e.g. up to 254 devices, if 00 and FF are reserved/forbidden) and another with on-board cheap EEPROM (started today about 0.25 USD) where ID number and some other data (like calibration that you mentioned below) can be stored. Issue with later is how to program it conveniently for the first time.
I think that specified power lines can remain and we can introduce another one e.g. 12, 15 or 24 V that can be used for supplying module isolated power stage.
At the beginning I was thinking about "mandatory" and "auxiliary" connectors. Now, I tried to put as much as possible on mandatory/primary connector to cover work with different modules/functionalities. For extra ("FPGA-class") stuff maybe we should introduce over the time another connector what is actually viable to do when backplane/connectors are placed at the chassis bottom not rear side.
Maybe using CS (Chip select) label is confusing. It's module (or card) select in the first place. Therefore only one CS line reach each of 7 modules, and if you have more then one SPI device on one module you have to "decode" their chip selects. A star-topology is used (1-to-many) to connect MCU with each module, and due to that peripheral modules needs smaller connector then processor module. In case of xCORE you can simultaneously (in parallel) communicate with all seven boards via dedicated SPI channels at once!
Why number seven? Because it's 8 minus 1 (processor board on slot #0) .
Yeah, connectors are hard. Do they have some pins which are a bit longer than others and engage early?
I was thinking some of the connector pins could be used to encode the backplane slot #, and feed them to address lines on the I2C EEPROM. The EEPROM can be programmed by plugging it into the backplane and using some 'special' master commands (maybe with a removable jumper for write-protection. Reference design material should include the appropriate (low cost but reliable) EEPROM, addressing scheme, scripts (Python?) for generating configuration descriptor etc.
I would suggest a separate power ground return as well to keep power return currents out of the signalling.
Mandatory + auxiliary (or 'Core' + 'Expansion' or whatever) is a good concept. Some people looking at this will be highly cost sensitive.
Also, I suggest starting with the Mandatory part, because you will likely at some point say 'this isn't quite right, I need to make some big changes.' That will probably break some compatibility, and is one of the costs of good engineering. You have to be willing to do a big revision to capture lessons learnt, or you end up with the Arduino pin header offsets.
Arduino probably should have said, 'oh, this is a mistake, we'll change the spec to make sense and redo a few shield designs,' but instead they kept going and now all Arduinos have a funny pin spacing. When people make items like this, the specification is flawed.
Maybe using CS (Chip select) label is confusing. It's module (or card) select in the first place. Therefore only one CS line reach each of 7 modules, and if you have more then one SPI device on one module you have to "decode" their chip selects. A star-topology is used (1-to-many) to connect MCU with each module, and due to that peripheral modules needs smaller connector then processor module. In case of xCORE you can simultaneously (in parallel) communicate with all seven boards via dedicated SPI channels at once!
Why number seven? Because it's 8 minus 1 (processor board on slot #0) .
Maybe the master should spit out 7 Module Select signals (one per module) (or even 7 separate SPI busses) and a few Chip Select signals (maybe 4??, could be shared across all modules). That way some simple cards (e.g. relay output channel / basic ADC / basic DAC) could be built with SPI chips and no micro.
Or maybe a cheap & cheerful bunch-of-UARTs would be the solution? That way developers wouldn't have to make SPI slave firmware, which can be a bit tricky. (But then you would almost always need a micro.)
Do they [connectors] have some pins which are a bit longer than others and engage early?
Not ones that I have/suggested. What do you have in mind a hot-swap capability?
I was thinking some of the connector pins could be used to encode the backplane slot #, and feed them to address lines on the I2C EEPROM. ...
That sounds good.
I would suggest a separate power ground return as well to keep power return currents out of the signalling.
Ok, make sense but I didn't find so far such separation in other specifications (i.e. VXI). Maybe they compensate that with few dozen of evenly placed GND pins?
I believe that mandatory/core specification and connector has to be wisely defined that we don't have a need to change anything there in the future. Further modifications and enhancements should be done by introducing "Expansion/AUX" connector. There is a good chance that we do not come even closer to Arduino situation .
I draw a simple schematic that should help you to visualize proposed pinouts ... signaling ... is almost completely dedicated to that module, i.e. a star-topology is proposed.
I don't see a way how to efficiently share more CS lines between more modules.
Please keep in mind that some of modules should be completely isolated (e.g. power supply, electronic load, etc.) that sharing could make even more difficult (if possible at all).
With current proposal, if signaling isolation is needed for min. functionality one have to implement only one 4-in/2-out digital isolator (or even 4-in/1-out if IRQ is not needed), and has to derive powering from proposed "hi-voltage" source that could be +24 V (or TBA).
(Possible AUX connector: DIN41612 power connection)
I saw a 100MHz clock distribution pencilled in - were you thinking this should come from the master only, or should it allow for the choice a more accurate timing module?
Isn't the usual clock distribution frequency of choice 10 MHz? A lot of cheap micros can't handle 100 MHz.
A synch signal which strobes at a lower rate is also very helpful.
The synch signal could be sourced from the master clock (fixed period strobe), or maybe it could be a bidirectional pin, allowing a (suitably configured) slave to trigger everything.
Yeah, isolation makes things more difficult. From experience, I can say that sometimes you just have to drop a whole lot of channels. Alternatively, you can deploy something like a UART (1 in / 1 out) but that has challenges too, especially with timing.
One little question, is there are reason for 3.3VAUX to be 3.3V? Using 5V there would allow for direct use of ATX power supply (at least to bootstrap it, as they have 5 volt standby voltage), at least for testing as providing +3.3, +5V, +12V and -12V is at least 2 bench power supplies worth of power rails and that's a bit of a pain for testing.