"DIY instrumentation bus" (or DIB)

[ogden]

Hmm... does that mean that every module will have a different MCU from a different manufacturer depending on the designer's preferences or enforce the use of a particular MCU architecture across all the modules? I don't think everyone will agree with any of those.

Give me a break... So your solution is to use "standardized SIPO register and EEPROM"? 

Every "manufacturer" will use same ADC and DAC. Right.

Also, for modules such as bench power supplies you still need dedicated DACs & ADCs if you want anything higher than ~16-bit and a MCU would be a waste of space and money unless you want to implement some kind of PID loop like for an electronic load's constant resistance mode.

MCU would handle offset, calibration and hardware abstraction so every supply in "your instrumentation standard" is controlled same way and it's voltage and current readout is done same way. In your proposal every "manufacturer" can save 2 dollars (huge savings!!!) on MCU and place any kind and number of ADCs and DACs on power suplies, then put some shift registers for LEDs and so on - to make compatibility between various supplies a total mess.

Your joke "MCU would be a waste of space and money" saved my day. 

[xani]

Well, burning 2 pins for serial and just sending configuration via it makes more sense than burning 8 pins just for chip selects.

Have a mandatory serial bus  for


• Configuration
• Identification
• Writing/reading configuration registers - say if only reason you need SPI is to set few config registers then just write it on serial and let micro handle it
• Low speed measurement

And then just use saved pins for whatever else is needed

Hell, I can imagine a case where you could have few shared pins and then

• Tell module A "send ADC data on bus 0"
• Tell module B "send ADC data on bus 1"
• Tell module C "receive data on bus 0,1, send your output to bus 2
• Tell module D "receive data on bus and output it via ADC"

[xani]

If you can recommend connector with higher pin count that does not cost a fortune and is easily to obtain, please let me know.

Thank you, I will not. I would simply put MCU on the module to not have pin count problem.

Hmm... does that mean that every module will have a different MCU from a different manufacturer depending on the designer's preferences or enforce the use of a particular MCU architecture across all the modules? I don't think everyone will agree with any of those.

https://jaycarlson.net/microcontrollers/

Every SINGLE $1 micro has an UART and SPI (altho to be fair in some cases they share same piece of hardware). Most also have I2C (altho I'm not sure how many can work as slave)

So you can pretty much take almost any micro and use it, if it was just a serial bus.

Also, for modules such as bench power supplies you still need dedicated DACs & ADCs if you want anything higher than ~16-bit and a MCU would be a waste of space and money unless you want to implement some kind of PID loop like for an electronic load's constant resistance mode. In other words, if high sampling rate and/or complex calculations are not required I think there's no point in adding a MCU which is going to spend most of its time waiting for the 'read ADC timer' to overflow or get some request to send data...

Okay. Let's say it is just a power supply.

You'd probably still NOT want to drive it directly via SPI because then you'd have to handle all calibration on the controller side and also store all calibration data on controller side. Or add another eeprom somewhere.

And you would want to have calibration because getting higher % shunt resistor is cheaper than having some high precision one just to save $1 on a micro.

And you probably would still want to have a readout of current/voltage.

So at the very minimum you'd have to write to 2 DACs and read from 2 ADCs + 2-4 (depending wheter those would be separate or dual adc/dacs) CS.

That's a minimum. You probably also want

• Actual power on/off (with output disconnect) signal instead of "set DACs to 0 and hope for best"
• Info to controller whether it is in CC/CV mode
• Probably a temperature sensor output so it can alert operator why power supply stopped providing required power
• Any other alert it could generate

And the moment you change ADC/DACs, your controller needs to change its code.

Compare it to "just send what voltage/amperage I want over serial and receive any measurement, and let module's micro deal with it".

Then you can have generic model of "this is a power supply, it accepts this and that command" (and same with ADC/DAC/digital I/O at least at serial-level speed) and anything will work without much/any change in code

[void_error]

Hmm... does that mean that every module will have a different MCU from a different manufacturer depending on the designer's preferences or enforce the use of a particular MCU architecture across all the modules? I don't think everyone will agree with any of those.

Give me a break... So your solution is to use "standardized SIPO register and EEPROM"? 

Every "manufacturer" will use same ADC and DAC. Right.

Let me dumb it down for you:

Bob, Jim and Matt all want to build their own module on the instrumentation bus.
Bob uses a micro from ST on his module, Jim uses a micro from NXP on his module and Matt uses a TI micro on his.

Bob wants to also build the modules that Matt designed, and also the one that Jim designed. He wants to add some features to Jim's firmware and some other features to Matt's firmware but he only has an ST-Link so he can only debug code running on STMs.

Do you see any issues here?

Also, for modules such as bench power supplies you still need dedicated DACs & ADCs if you want anything higher than ~16-bit and a MCU would be a waste of space and money unless you want to implement some kind of PID loop like for an electronic load's constant resistance mode.

MCU would handle offset, calibration and hardware abstraction so every supply in "your instrumentation standard" is controlled same way and it's voltage and current readout is done same way. In your proposal every "manufacturer" can save 2 dollars (huge savings!!!) on MCU and place any kind and number of ADCs and DACs on power suplies, then put some shift registers for LEDs and so on - to make compatibility between various supplies a total mess.

Your joke "MCU would be a waste of space and money" saved my day. 

'manufacturer'... see above.

https://jaycarlson.net/microcontrollers/

Every SINGLE $1 micro has an UART and SPI (altho to be fair in some cases they share same piece of hardware). Most also have I2C (altho I'm not sure how many can work as slave)

So you can pretty much take almost any micro and use it, if it was just a serial bus.

I know that. See my statement above, featuring Bob, Jim and Matt.

 

Do you people actually read what you reply to?

Anyway, I'm out, It's seems I'm not one of those hobbyists with 30+ years of experience in the field and a lot of money and free time. Have fun.

[ogden]

Let me dumb it down for you:

Bob, Jim and Matt all want to build their own module on the instrumentation bus.
Bob uses a micro from ST on his module, Jim uses a micro from NXP on his module and Matt uses a TI micro on his.

Bob wants to also build the modules that Matt designed, and also the one that Jim designed. He wants to add some features to Jim's firmware and some other features to Matt's firmware but he only has an ST-Link so he can only debug code running on STMs.

Do you see any issues here?

Yes. Your argument have serious "issue": in controller-less design nobody you mention can even build anything because they know only their micros. None of them knows how to code controller software

Actually if you believe that what you "dumbed down" for me is serious argument- that  microcontroller on the module is bad thing because there are so many microcontrollers - I have no more comments. Basically we can end our discussion here right now and I am starting to regret my time I invested in this thread.

[welterde]

So something like VME, where you read/write a bunch of addresses to control the modules would be fine I guess?

Kind of. Considering that I don't even know what VME is Not addresses but named variables. During init master enumerates module capabilities including list of the variables that can be written and/or polled. Variable can be either single value or number of values in array, various common data types shall be supported as well (double/float/int8/int16/int32/string).

VME is probably the most popular chassis system (in science) by far.
It was essentially just the (data&address, etc.) busses from the Motorola 68000 put on a backplane (and evolved from there).

And what you are proposing has the downside that it's more difficult to implement in say an FPGA (unlike just some memory-mapped stuff).
But could always implement an address space to variable mapping system on top, which would abstract the lower details away.

No more then one CS signal is needed if you are using '595 (see post #43) that can be clocked much faster then SPI (to compensate 8 clocks needed to shift data for target CS). "Module info" EEPROM could be one of SPI devices (e.g. #0).

Ah, yes. That would also work.
What do you think about using LVDS for the per-module SPI busses?
Not trying to be stubborn about this idea, I just want to figure out if running an single-ended SPI bus quite quickly might be pushing it for the last few modules furthest away from the CPU module?

[ogden]

And what you are proposing has the downside that it's more difficult to implement in say an FPGA (unlike just some memory-mapped stuff).
But could always implement an address space to variable mapping system on top, which would abstract the lower details away.

Indeed processing variables by name compared to memory locations is more difficult. Yes, it can be memory-mapped stuff as well. Agreed. Just additional memory mapping descriptor file for each module needed. That shall not be any problem as long as module type and version matching (to descriptor file) is well-implemented.

[prasimix]

No more then one CS signal is needed if you are using '595 (see post #43) that can be clocked much faster then SPI (to compensate 8 clocks needed to shift data for target CS). "Module info" EEPROM could be one of SPI devices (e.g. #0).

Ah, yes. That would also work.
What do you think about using LVDS for the per-module SPI busses?
Not trying to be stubborn about this idea, I just want to figure out if running an single-ended SPI bus quite quickly might be pushing it for the last few modules furthest away from the CPU module?

Yes, LVDS point-to-point (star) SPI and M-LVDS (or multi-point) for clocks, triggers and sync are in my latest working draft (sketched with massive help from @jbb) that hopefully I'll publish soon for your review. I presume that is also in line with what @ogden mentioned about LVDS, with addition of multi-point (shared between modules, and assigned "on the fly") signals.

[xani]

Hmm... does that mean that every module will have a different MCU from a different manufacturer depending on the designer's preferences or enforce the use of a particular MCU architecture across all the modules? I don't think everyone will agree with any of those.

Give me a break... So your solution is to use "standardized SIPO register and EEPROM"? 

Every "manufacturer" will use same ADC and DAC. Right.

Let me dumb it down for you:

Bob, Jim and Matt all want to build their own module on the instrumentation bus.
Bob uses a micro from ST on his module, Jim uses a micro from NXP on his module and Matt uses a TI micro on his.

Bob wants to also build the modules that Matt designed, and also the one that Jim designed. He wants to add some features to Jim's firmware and some other features to Matt's firmware but he only has an ST-Link so he can only debug code running on STMs.

Do you see any issues here?

Put a serial bootloader on each, trigger it via one line from bus ("set program, then send reset signal to enter bootloader"), done. Really, couldn't you figure out that  ?

Hell, a bunch of micros come with the serial bootloader baked in.

Or you can just provide JTAG connector.

Skipping micro just means that Bob, instead of opening someone's else source code and changing 3 lines, now have to get close and personal with every SPI chip used on on other boards

[prasimix]

Skipping micro just means that Bob, instead of opening someone's else source code and changing 3 lines, now have to get close and personal with every SPI chip used on on other boards

This I believe depends of how well firmware layers are defined. If one has to include support for its SPI devices he/she has to be in position to add that without mingling with code that is addressing devices on other modules.
My current stance regarding single MCU vs. multiple (per-module) MCU approach is that former could lower the complexity for entry level solutions, and should simplify development, debugging and maintenance (e.g. single instead of multiple firmware updates). Later offer better boundaries and sharing of responsibility when multiple "manufacturers" comes into picture. In that case each of them is responsible to provide hardware and firmware that should comply with specification how to communicate with local console (i.e. TFT display + encoders + switches + trigger I/Os, etc.) and outside world (PC application that has e.g. SCPI controller functionality).

[ogden]

This I believe depends of how well firmware layers are defined.

Yes, exactly! In MCU-less architecture firmware layers are blurred all over the system - from card to hi-level controller. It's oposite to well-defined firmware layers/boundaries.

If one has to include support for its SPI devices he/she has to be in position to add that without mingling with code that is addressing devices on other modules.

Funny that you and other proponents of MCU-lesss modules completely ignore argument that "he/she has to be in position to add code to controller part". Electronics engineer who knows just how to program PIC/AVR/whatever microcontroller he is building all his hobby stuff on, is unable to create module because he have to learn "big systems", supposedly Linux (?) programming".

My current stance regarding single MCU vs. multiple (per-module) MCU approach is that former could lower the complexity for entry level solutions

Low complexity, entry level solutions of automated instrumentation chassis? What's that?

Guys, open your minds!

[edit] You are overcomplicating things all over the place yet you say that MCU will add complexity. It does not makes sense. MCU with well-defined host communications boundary will ease everything, not complicate!

[prasimix]

Ok, lets put it in this way: if firmware layering is properly done, i.e. that for beginning lower hardware is abstracted from higher "presentation" layer then no difference should be if all code is executed on one place (i.e. MCU board) or many others. Then it become simply a matter of designer choice. Actually some computing intensive modules will ask for dedicated MCU and more (FPGA, etc.). Module "manufacturer" has to propose lower hardware layer ("driver") for new module alone (using e.g. reference module driver as reference) or with EEZ assistance and/or community.

My previous project (EEZ H24005) already included to the high extent separation (layering) between let's call it "main loop" and underlaying devices (ADC, DAC, I/O expander, etc.) and comes with comprehensive SCPI command set support. I'll continue to go into that direction. My "initial" idea about central processing module and different peripheral modules was based on XMOS MCU that sounds pretty powerful to concurrently drive multiple modules (especially programmable power supplies), but even in that (exotic) scenario, a multi-layer firmware is presumed as basic requirement therefore per-module MCU engagement is possible.

In summary, I don't like idea that multiple MCU setup is mandatory (nor impossible!), and I'm taking software/firmware part of the whole solution very seriously (that is I believe visible from EEZ H24005 project) and hopefully we could make in few iterations a meaningful specification that could make other designers a whole job easier and that they can count over the time with attractive (open source) software components that will be presented as part of this adventure.

[ogden]

I'm taking software/firmware part of the whole solution very seriously (that is I believe visible from EEZ H24005 project)

Your supply project is well-planned and well-done indeed. Thou it is not quite correct to compare that supply to instrumentation chassis. Supply is single & whole device, chassis is set of many devices controlled by single controller. You possibly see card of instrumentation as just FR4 PCB with single SPI ADC on it, I don't.

Did you ever made list of all possible kinds of cards? I would like to see which you think does not need MCU, would like to see what are those cards and how many they are compared to total number of cards.

In summary, I don't like idea that multiple MCU setup is mandatory (nor impossible!)

Ok MCU's are possible. Phew.   Is there any chance for cards that have just single AVR MCU and LDO on them?

[prasimix]

I'm taking software/firmware part of the whole solution very seriously (that is I believe visible from EEZ H24005 project)

Your supply project is well-planned and well-done indeed. Thou it is not quite correct to compare that supply to instrumentation chassis. Supply is single & whole device, chassis is set of many devices controlled by single controller. You possibly see card of instrumentation as just FR4 PCB with single SPI ADC on it, I don't.

Did you ever made list of all possible kinds of cards? I would like to see which you think does not need MCU, would like to see what are those cards and how many they are compared to total number of cards.

I cannot imagine a single card without MCU placed somewhere if I want to benefit from digitally controlled/programmed devices (locally or remotely). I started with idea that all MCU resources could reside on single place, but that is not mandatory (just as MCU per-module shouldn't be), it could simplify design, but also has real limitations.
I see this "instrumentation" chassis as next step from single instrument to multitude of them added in modular fashion (the EEZ H24005 is also modular to one extent, but do not provide flexibility of chassis that we are discussing here).

In summary, I don't like idea that multiple MCU setup is mandatory (nor impossible!)

Ok MCU's are possible. Phew.   Is there any chance for cards that have just single AVR MCU and LDO on them?

Apparently even better: it can be MCU only, if LDO/power comes via backplane from external power module or e.g. "MCU" (slot #0) card

[ogden]

I see this "instrumentation" chassis as next step from single instrument to multitude of them added in modular fashion (the EEZ H24005 is also modular to one extent, but do not provide flexibility of chassis that we are discussing here).

Your approach will lead to cards that are not useable without chassis and master controller.

Example: If somebody will create low cost (< 50$?) card I badly want, let's say programmable 4-quadrant supply with programmable waveforms and it will be based on "save 2$ on MCU" approach, I will be pushed to buy whole chassis and controller which is significant additional expenses! BUT I need just that one 4-quadrant supply! I want to connect it to my PC through USB or UART-USB, run control software on my PC and that's it.

[prasimix]

I see this "instrumentation" chassis as next step from single instrument to multitude of them added in modular fashion (the EEZ H24005 is also modular to one extent, but do not provide flexibility of chassis that we are discussing here).

Your approach will lead to cards that are not useable without chassis and master controller.

Example: If somebody will create low cost (< 50$?) card I badly want, let's say programmable 4-quadrant supply with programmable waveforms and it will be based on "save 2$ on MCU" approach, I will be pushed to buy whole chassis and controller which is significant additional expenses! BUT I need just that one 4-quadrant supply! I want to connect it to my PC through USB or UART-USB, run control software on my PC and that's it.

Hm, maybe your example is not so representative, or maybe it is, but I'd like to learn about 4-qudrant programmable power unit under < 50 USD . But ok, let's pretend that something like that is doable (please excuse me for my ignorance). What if I made anticipated mistake and for people like you make a "piggyback" PCB with MCU, small OLED, encoder and USB that can be then housed together into standalone (possibly off-the-shelf) enclosure? Please note that adding just MCU probably will not be enough for many others, some more stuff is needed to have a decently usable unit, or not?

[technix]

Actually I am in the process of rewriting firmwares to my own DIY instrumentations so everything is standardized. I don't really have a DIB in mind, just some method of transporting data over different channels. I even have devices capable of multiple modes of communication - for example my climate sensor clock supports both Wi-Fi and USB. For something like a DIB, there are four requirements to the system:

• Some mechanism to address the devices,
• Some mechanism to discover the devices,
• Some mechanism to identify the devices, and
• Some standard language all devices should speak.

Currently I have two established transports and is in need for definition of a few more use cases:

• USB HID transport: addressed by host port number, discovered through USB enumeration, identified through USB descriptors and speaks standard HID packets. The HID Report Descriptor is already a full featured high level protocol descriptor language, and I will use that here directly.
• TCP/IP transport: addressed by IP address, discovered and identified through DNS-SD (Bonjour,) speaks HTTPS. Anything that normally carry TCP/IP uses this transport. This transport is actually designed with Apple iPhone support in mind. I am thinking about borrowing USB HID Report Descriptor but not so sure now.
• I2C transport: I need help. Maybe implement Microsoft's I2C HID standard, and speak USB HID again?
• RS232 transport: Uhhh...

[ogden]

What if I made anticipated mistake and for people like you make a "piggyback" PCB with MCU, small OLED, encoder and USB that can be then housed together into standalone (possibly off-the-shelf) enclosure?

Yes, you can try to do such mistake. I do not see any need for display/buttons/encoders. It's automated instrumentation. Just adapter to supply power & connect card to host PC using USB and run controller software on the (preferably windows) PC. Did you check Agilent chassis I mentioned in my post?

[prasimix]

Did you check Agilent chassis I mentioned in my post?

Yes, I did. Thanks for that.

[jbb]

Ok, lets put it in this way: if firmware layering is properly done, i.e. that for beginning lower hardware is abstracted from higher "presentation" layer then no difference should be if all code is executed on one place (i.e. MCU board) or many others. Then it become simply a matter of designer choice.

I've been thinking a lot about this over the last few days.  On the one hand, I like the idea of leaving lots of flexibiilty to the module designer.  On the other hand, forcing the module designer to use a separate micro means that the module driver code must be separated from the master and use a defined interface, which is a good thing in my book.  We also know that designing any module will require some programming, whether it be in the master or in the module.

I'm now doing a thought experiment on 'simple' cards which might be reasonable candidates for no-MCU implementation:

• Basic Digital Input No MCU needed. MCU could be useful for time stamping inputs if desired.
• Relay Driver Could do with simple outputs.  But I would like to have a defined state in the event of a backplane communications failure, which is easier to do with an MCU than logic.
• Relay MUX card  This card is likely to use latching relays* which require set/reset drive and should have cycle counters. Again, easier to do with an MCU.
• Power supply / Electronic Load / Function Generator I would really like an MCU to handle a) calibration b) any mode switching and c) graceful shutdown in the event of a backplane communications failure.
• Multimeter / Power Meter I would like an MCU to do calibration and manage input MUXing.
• Data acquisition card Could be done without MCU

So I'm seeing that a good number of cards should have an MCU.    So my current thinking is that Ogden is right; it's reasonable to require all the modules to have an MCU.  If using an MCU in each module, UART comms make sense. They could start at a well-supported baud rate (e.g. good old-fashioned 9600 baud) to exchange identity information and then negotiate for higher speeds (10 MHz / 16 = 625 kbaud for an MCU, >100 Mbaud for an FPGA!).
 
I would suggest that the backplane keep using LVDS to support those higher data rates.  I would like to keep 2 (maybe 4?) extra LVDS lanes on hand for some slots to support applications where big data transfer is required.  Using a clock distribution system (which we definitely want to have), LVDS can go up to 1000 Mbit/s or so without using crazy expensive FPGAs.  (600 Mbit/s LVDS isolators are available from Analog Devices.)  4x LVDS lanes @ 600 Mbit/s each = 2.4 Gbit/s!

A basic 'connect this DIB module to my computer' interface could be a power supply, UART port and basic enclosure.

* Latching type relays are recommended for low current sealed signal relays to reduce self-heating.  Self-heating can apparently lead to migration of compounds inside the sealed contact compartment and cause sticking or high contact resistance.  Self-heating can also cause thermocouple effects.

[void_error]

Put a serial bootloader on each, trigger it via one line from bus ("set program, then send reset signal to enter bootloader"), done. Really, couldn't you figure out that  ?

Hell, a bunch of micros come with the serial bootloader baked in.

Or you can just provide JTAG connector.

Skipping micro just means that Bob, instead of opening someone's else source code and changing 3 lines, now have to get close and personal with every SPI chip used on on other boards

My apologies for being stupid, I won't post on this forum anymore because it seems if I throw an opinion or idea out fingers are being pointed at me. Also, What's a JTAG? Or a bootloader? Where do you buy one? Sarcasm over.

[ogden]

I'd like to learn about 4-qudrant programmable power unit under < 50 USD

Of course initially it was meant as provocative joke. Then I started to think about it and stumbled on this discussion. Pay attention to http://www.linear.com/solutions/4288 mentioned in the thread. IMHO <50$ in BOM components (including MCU) is possible.

[prasimix]

I'd like to learn about 4-qudrant programmable power unit under < 50 USD

Of course initially it was meant as provocative joke. Then I started to think about it and stumbled on this discussion. Pay attention to http://www.linear.com/solutions/4288 mentioned in the thread. IMHO <50$ in BOM components (including MCU) is possible.

Yes, I'm aware of LT1970. If used alone < 50 USD BOM is probably possible, but if we added output booster stage, two pre-regulator, ADC/DAC/MCU for programming then BOM will be a slightly higher . Anyway, thanks for link to mentioned discussion.

[ogden]

I won't post on this forum anymore because it seems if I throw an opinion or idea out fingers are being pointed at me.

Really? You did say "Let me dumb it down for you" implying that I need such style/kind of explanation - which is insult, not idea. You did throw a rock and now complain that you are receiving some back?

[ogden]

I'm aware of LT1970. If used alone < 50 USD BOM is probably possible, but if we added output booster stage, two pre-regulator, ADC/DAC/MCU for programming then BOM will be a slightly higher

Wow, you said this one will need MCU! I am thrilled

If you specify it for >=150W then you obviously can't squeeze into 50$. Low power PSU will not need anything else but what's in appnote. Output stage mosfet costs 1$/1pc each, LT1970 around 10$, AMC7891 (10bit 4xDAC 8xADC)- around 5$. Whole stm32f103 (USB MCU) "blue pill" board = 2.2$ The rest is just jelly bean components and some electrolyte.