Author Topic: "DIY instrumentation bus" (or DIB)  (Read 41690 times)

0 Members and 1 Guest are viewing this topic.

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: "DIY instrumentation bus" (or DIB)
« Reply #100 on: February 20, 2018, 01:28:54 pm »
Hobbyist with 50MHz scope wont be able to debug 100Mbit LVDS very well either so pretty much any high-speed option would be hard for most hobbyists to debug

Right. I don't understand where's point to invent next bus. Hi-speed LVDS for hobbyists is straight road to failure because you can't hope to receive wide acceptance, there will be not that many hobbyists who will develop their modules for obscure "standard" coming from eevblog forum.

Why don't simply use USB? HUB ic's are cheap as sand, microcontrollers with USB peripherals as well. USB would allow stand-alone use and development of modules as well. Win win win solution. IMHO.
« Last Edit: February 20, 2018, 01:32:56 pm by ogden »
 

Offline prasimixTopic starter

  • Supporter
  • ****
  • Posts: 2022
  • Country: hr
    • EEZ
Re: "DIY instrumentation bus" (or DIB)
« Reply #101 on: February 20, 2018, 01:44:37 pm »
Thanks to all recent posts. I got the message, in the meantime if some of USB-proponents find a nice way how to isolate USB bus that is faster then full speed (i.e. USB 2.0 or later) please let us know.

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: "DIY instrumentation bus" (or DIB)
« Reply #102 on: February 20, 2018, 02:03:14 pm »
Thanks to all recent posts. I got the message, in the meantime if some of USB-proponents find a nice way how to isolate USB bus that is faster then full speed (i.e. USB 2.0 or later) please let us know.

If isolation at communication end of the module is *requirement*, then obviously Ethernet is next thing in the list. Some would like to use just single module w/o backplane (with lo-cost adapter board) and using USB/Ethernet/both is elegant way to allow it. Not to mention much higher chances of acceptance compared to proprietary LVDS BUS "standard out of nowhere". USB for lo-speed modules and Ethernet - for hi-speed. I would put USB on the backplane and Ethernet socket on the front panel of the hi-speed modules. This could require Ethernet switch module, and obviously external wiring but why not? After all it's DIY which supposedly is "low cost" as well, right? Also I would put isolators on backplane so there could be two versions of backplane - isolated and low-cost nonisolated.

 

Offline prasimixTopic starter

  • Supporter
  • ****
  • Posts: 2022
  • Country: hr
    • EEZ
Re: "DIY instrumentation bus" (or DIB)
« Reply #103 on: February 20, 2018, 02:09:34 pm »
If isolation at communication end of the module is *requirement*

Yes it is, already mentioned few times and that is for practical reasons because I don't know how to control from single place multiple e.g. floating power supply or el. load modules without introducing isolation.

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: "DIY instrumentation bus" (or DIB)
« Reply #104 on: February 20, 2018, 02:14:09 pm »
If isolation at communication end of the module is *requirement*

I don't know how to control from single place multiple e.g. floating power supply or el. load modules without introducing isolation.

Well, look at the existing bench instruments then :) They all have non-isolated comms & control with floating measurement part.

[edit] If some module will require buttons, rotary encoders and so on - do you really want them to be connected to point of measurement? - I don't.
« Last Edit: February 20, 2018, 02:15:43 pm by ogden »
 

Offline xani

  • Frequent Contributor
  • **
  • Posts: 400
Re: "DIY instrumentation bus" (or DIB)
« Reply #105 on: February 21, 2018, 02:18:59 pm »
Multimeters sure, but scopes and sig gens generally have gnd tied to ground. So it is definitely not "all"

Thanks to all recent posts. I got the message, in the meantime if some of USB-proponents find a nice way how to isolate USB bus that is faster then full speed (i.e. USB 2.0 or later) please let us know.
Probably easiest way would be isolating other side (between micro and ADC, ~100-150Mbit isolators are pretty cheap). Chips doing isolation at 480Mbit do seem to exist http://www.prweb.com/releases/2015/10/prweb12995871.htm just not buyable at hobbyist quantity

Thanks to all recent posts. I got the message, in the meantime if some of USB-proponents find a nice way how to isolate USB bus that is faster then full speed (i.e. USB 2.0 or later) please let us know.

If isolation at communication end of the module is *requirement*, then obviously Ethernet is next thing in the list. Some would like to use just single module w/o backplane (with lo-cost adapter board) and using USB/Ethernet/both is elegant way to allow it. Not to mention much higher chances of acceptance compared to proprietary LVDS BUS "standard out of nowhere". USB for lo-speed modules and Ethernet - for hi-speed. I would put USB on the backplane and Ethernet socket on the front panel of the hi-speed modules. This could require Ethernet switch module, and obviously external wiring but why not? After all it's DIY which supposedly is "low cost" as well, right? Also I would put isolators on backplane so there could be two versions of backplane - isolated and low-cost nonisolated.

Sure ethernet is one option but if you have ethernet then... why the fuck even bother with anything else ? Just have a box with ethernet and power connector and nothing else.
Like only thing you really gain is maybe sharing clock/trigger (and if you just need us resolution, just send a broadcast packet)

Like, really, you have Gbit of transfer rate (and ethernet goes way above that if you really need to), well supported standards and if you really hate connecting more than one cable to the box, PoE can supply from ~12 to 50W
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: "DIY instrumentation bus" (or DIB)
« Reply #106 on: February 21, 2018, 04:02:58 pm »
Multimeters sure, but scopes and sig gens generally have gnd tied to ground. So it is definitely not "all"

Good point to think about :)

Quote
Like, really, you have Gbit of transfer rate (and ethernet goes way above that if you really need to), well supported standards and if you really hate connecting more than one cable to the box, PoE can supply from ~12 to 50W

Ethernet will increase complexity and price of low speed modules that can happily run SCPI over USB. Everybody most likely can find free USB ports on their computer right now, but will struggle finding Ethernet switch ports around.
 

Offline xani

  • Frequent Contributor
  • **
  • Posts: 400
Re: "DIY instrumentation bus" (or DIB)
« Reply #107 on: February 21, 2018, 05:39:44 pm »
Multimeters sure, but scopes and sig gens generally have gnd tied to ground. So it is definitely not "all"

Good point to think about :)

Quote
Like, really, you have Gbit of transfer rate (and ethernet goes way above that if you really need to), well supported standards and if you really hate connecting more than one cable to the box, PoE can supply from ~12 to 50W

Ethernet will increase complexity and price of low speed modules that can happily run SCPI over USB. Everybody most likely can find free USB ports on their computer right now, but will struggle finding Ethernet switch ports around.


Sure, I know, just that my point was that once you have ethernet you don't really need remaining signals and requiring chassis becomes a drawback, as you can't just separate the module and use it somewhere else easily.

But I guess exactly same thing can be said about USB, maybe expect speed. It is relatively cheap to get 10Gbit NIC and 1Gbit switch that has 10Gbit upstream port, while in case of USB it is one upstream port shared between all nodes.

And now I'm considering how hybrid approach would work, like having low-speed-only (well, single digit of Msps, not hundreds) chassis that just shares devices inside with outside using ethernet and high speed stuff delegated to standalone modules with ethernet (with maybe some tiny connector with clock/sync to the chassis)

 

Offline welterde

  • Contributor
  • Posts: 19
Re: "DIY instrumentation bus" (or DIB)
« Reply #108 on: March 06, 2018, 05:36:58 am »
I would prefer to avoid complex protocols such as Ethernet or USB, since I was hoping to use this to build many rather simple modules and combining those to do what I want (divide and conquer), instead of building one module that does everything I want (then why really bother with DIB again?).

My proposal would be to have a shared SPI bus for slow control with 3 per-module chip-select signals.
One CS signal would be used for an SPI EEPROM that contains information about the module and the other 7 possible combinations can be used for other SPI devices on the module (similar to what has been suggested before).
One can easily generate the actual CS signals with an 3-to-8 decoder IC - or directly use the three lines if it's less than four devices.
This would cover most simple modules that have no large data bandwidth requirements (like power supplies, slow DAQ, etc.).
And there are more or less easy to use SPI to I2C/UART/1wire/.. chips if one doesn't want to deal with SPI directly or wants to hook something else up.

And for slightly higher bandwidth applications one could use an per-module LVDS SPI bus, which is still easy enough to implement on the modules (one <3€ LVDS transceiver IC).
Or is that overkill for an SPI bus that's maybe 50cm in length running at maybe 60Mhz (or however far people want to push it)?

Adding various power supplies, master clocks and some trigger signals pretty much fills up the 48 pins for the modules already.
Even higer bandwidths, analog busses, etc. I would put on a (optional) second connector (or use cables between modules).
 

Offline xani

  • Frequent Contributor
  • **
  • Posts: 400
Re: "DIY instrumentation bus" (or DIB)
« Reply #109 on: March 06, 2018, 08:24:47 am »
SPI vs serial is an interesting case in itself.

On one side SPI allows card itself to be very simple and don't even have a micro, and generally be faster than UART, also easier to daisy chain and drive few chips without need for additional switching. On other, to program it you pretty much have to exactly know beforehand what are you communicating with. Which means either:

* enter it by hand in controller, and re-enter every time you move something around
* have an additional bus with EEPROM that IDs the board. And at that point, if you have programmable device then why not just put micro there ?
* have additional SPI chip on bus that only purpose is to send a bunch of ID bytes

In case of serial you can *basically* just implement some basic protocol or even just SCPI directly (and get benefits of using pre-made software to control it) but:

* you pretty much require one micro per module
* speeds are generally lower
* master card needs either a bunch of UARTs or some multiplexing

 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: "DIY instrumentation bus" (or DIB)
« Reply #110 on: March 06, 2018, 11:44:01 am »
SPI vs serial is an interesting case in itself.

On one side SPI allows card itself to be very simple and don't even have a micro

"Does not need micro" is danger territory. This means that there is no hardware abstraction - control software must know what kind of IC's are on the card and how they shall be driven, what are properties of the card. What's worse - where do you put all the (gain/offset/e.t.c.) calibration data? On the controller or on the board? If on the board then additional EEPROM needed which basically costs as much as micro, not to mention that EEPROM needs to be somehow communicated to. If someone wants to design own power supply, he must develop part of controller sofware as well! Come on! - It's 21st century. Today everything that runs on electricity, have micro.

I would add RS485 or RS422 to the list:

+ common bus, does not need mux
+ still async serial
+ speeds are not that slow, you can reach even 10Mbit - obviously if UART peripheral of MCU supports such :)
+ signal integrity much better than CMOS signals (SPI or UART)
+ longer runs possible. you can control whole 19" rack full of cards through single bus
- needs bus driver and micro with UART
« Last Edit: March 06, 2018, 11:49:39 am by ogden »
 

Offline welterde

  • Contributor
  • Posts: 19
Re: "DIY instrumentation bus" (or DIB)
« Reply #111 on: March 06, 2018, 05:00:34 pm »
You will need an EEPROM or microcontroller on each module anyway for the module to identify itself towards the controller (which I also mentioned in my proposal).
EEPROM vs. micro is not really about cost, but about simplicity.
And if you want serial communication with the module, adding a SPI-to-UART chip is easy enough.
You are of course right that RS485 or so would be able to run at a higher speed, but is that really needed for the slow control bus?

As for the HAL.. I would put that into the controller instead of the module - at least for simple modules.
Sure - a power supply might expose a higher level protocol, but I really don't want to write boilerplate code just so I can control a few DACs (and nothing else) on a module.
And unless we want to specify a (complex) common protocol for all modules to use, we'll end up with different protocols for each module anyway.
At which point the controller needs per-module-type logic again..
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: "DIY instrumentation bus" (or DIB)
« Reply #112 on: March 06, 2018, 09:59:54 pm »
Sure - a power supply might expose a higher level protocol, but I really don't want to write boilerplate code just so I can control a few DACs (and nothing else) on a module.

Right. Good power supply needs just few DACs to be controlled. No readouts of in/out current/voltage needed, LEDs that indicate PSU stale like CV/CC and so on, are not needed as well. Right. Only simple module I can imagine is relay card, yet it most likely needs not only relay control, but some indication as well.

Whatever... do as you want. Just my two cents.
 

Offline jbb

  • Super Contributor
  • ***
  • Posts: 1128
  • Country: nz
Re: "DIY instrumentation bus" (or DIB)
« Reply #113 on: March 06, 2018, 10:47:45 pm »
I think Prasimix is proposing I2C for module ID (and calibration etc.) plus a cunning pre-addressing trick for the SPI lines to support multiple slave devices per board.

They have also said that they want star connections where reasonable to reduce bus contention and also allow some modules to go faster than others. This makes sense to me because it means higher data rate modules (e.g. data acquistion) shouldn’t get choked by something with a slow SPI clock.

It should be reasonable to use SPI devices direct or SPI to UART converters or even slave SPI ports on micro controllers.
 

Offline welterde

  • Contributor
  • Posts: 19
Re: "DIY instrumentation bus" (or DIB)
« Reply #114 on: March 06, 2018, 11:57:23 pm »
Sure - a power supply might expose a higher level protocol, but I really don't want to write boilerplate code just so I can control a few DACs (and nothing else) on a module.

Right. Good power supply needs just few DACs to be controlled. No readouts of in/out current/voltage needed, LEDs that indicate PSU stale like CV/CC and so on, are not needed as well. Right. Only simple module I can imagine is relay card, yet it most likely needs not only relay control, but some indication as well.

Whatever... do as you want. Just my two cents.

I have a few modules in mind to construct a CCD controller that will each be very simple.
And I am not arguing that a complete power supply *should* be built up just with a few SPI devices, but if people want to do that why not? You don't have to use those modules if you don't want to... Nothing prevents you from implementing a higher level protocol on top of SPI or SPI-UART..

For example for the DC bias module I really do want to just have two SPI DAC's (and a bunch of fixed opamps, etc.), since for example readback, etc. will happen on another module.
I don't really see the point of adding another micro there, which does nothing other than wrapping the DAC commands in a slightly different protocol.

I think Prasimix is proposing I2C for module ID (and calibration etc.) plus a cunning pre-addressing trick for the SPI lines to support multiple slave devices per board.

I was first thinking about just using three pins on the module connector to encode the module slot ID towards the I2C EEPROM as well, but then I thought that instead of using three pins  to encode an I2C address I could use three pins (and 7*3 pins on the cpu-connector; or shift register on the backplane) to encode 8 SPI devices one of which just happens to be the SPI EEPROM.

But if we can get multiple I2C devices per board that would also work for me.

They have also said that they want star connections where reasonable to reduce bus contention and also allow some modules to go faster than others. This makes sense to me because it means higher data rate modules (e.g. data acquistion) shouldn’t get choked by something with a slow SPI clock.

Hence my suggestion to have a per-module LVDS SPI bus separate from the slow shared SPI bus (still not sure if using LVDS is really neccessary).
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: "DIY instrumentation bus" (or DIB)
« Reply #115 on: March 07, 2018, 10:22:43 am »
And I am not arguing that a complete power supply *should* be built up just with a few SPI devices, but if people want to do that why not?

How many SPI select lines will you dedicate for each slot? Two? Four? That number cannot be "fluid". Then there comes SPI data/clk line load problem - because you shall design whole thing for worst possible case - when every resource of the chassis is used. It means either SPI mux or multiple SPI masters.

Quote
You don't have to use those modules if you don't want to... Nothing prevents you from implementing a higher level protocol on top of SPI or SPI-UART..

Me? I will not use any modules or your chassis :)  Why? - Because when building own module like power supply, I need skills to build electronics of module and also need skills to code control software. Basically I have to do everything. Your chassis seemingly have no added value then. Then why I need your chassis? :-DD

[edit] - Just because you defined backplane electrical signalling?  - I can do it myself as well. Note that BUS is more than just socket pinout definition and some kind of data transfer interface choice. Also - successful and widely accepted modular system is more than just backplane bus.

Quote
Hence my suggestion to have a per-module LVDS SPI bus separate from the slow shared SPI bus (still not sure if using LVDS is really neccessary).

Sure. LVDS SPI. Complexity will be very appealing for 3rd party module designers.  :-DD
« Last Edit: March 07, 2018, 12:25:38 pm by ogden »
 

Offline welterde

  • Contributor
  • Posts: 19
Re: "DIY instrumentation bus" (or DIB)
« Reply #116 on: March 07, 2018, 01:27:20 pm »
And I am not arguing that a complete power supply *should* be built up just with a few SPI devices, but if people want to do that why not?

How many SPI select lines will you dedicate for each slot? Two? Four? That number cannot be "fluid". Then there comes SPI data/clk line load problem - because you shall design whole thing for worst possible case - when every resource of the chassis is used. It means either SPI mux or multiple SPI masters.

Well my suggestion was to use 3, since <=7 devices sounds quite reasonable for small modules.

The alternative suggestion was to have 1 and using a sort of addressing logic over SPI to address a potentially much larger number of SPI devices if I understood correctly.
And also have a shared I2C bus instead of a shared SPI bus.

Quote
You don't have to use those modules if you don't want to... Nothing prevents you from implementing a higher level protocol on top of SPI or SPI-UART..

Me? I will not use any modules or your chassis :)  Why? - Because when building own module like power supply, I need skills to build electronics of module and also need skills to code control software. Basically I have to do everything. Your chassis seemingly have no added value then. Then why I need your chassis? :-DD

Didn't you argue you for having a HAL above the module layer earlier..? Wouldn't that mean that *any* chassis would be useless to you?

What would a chassis have to bring to the table to be useful for you?

For me power and some easy slow-control bus would already be quite useful. Anything else I need (~30 trigger signals, analog routing, fast LVDS connections) is probably outside the scope of this project and best handled with some extra cables between modules..
« Last Edit: March 07, 2018, 02:01:56 pm by welterde »
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: "DIY instrumentation bus" (or DIB)
« Reply #117 on: March 07, 2018, 09:27:42 pm »
Didn't you argue you for having a HAL above the module layer earlier..? Wouldn't that mean that *any* chassis would be useless to you?

It's you who suggested that card creator can create HAL himself over SPI bus, suggesting that DIB is nothing more than just physical and electrical definition of backplane. Bus is more than that. W/o higher level API and good software indeed it is more or less useless.

I did not say anything about HAL, I said - you have to abstract hardware. Control software shall not directly write into ADC or DAC registers. No matter - such function lives in the HAL layer of controller or not. It shall control voltage of power supply, not DAC counts. Module itself shall apply all the compensation and calibration. Those who write control software shall be freed from reading ADC or DAC chip datasheets and those who are good doing electronics, shall be freed from coding anything else than MCU they know.

Quote
What would a chassis have to bring to the table to be useful for you?

Chassis appealing to me could be cost-optimized Keysight U2781A. Definitely with low-speed USB-less card support we are talking here for a while. It shall have quick & easy learning curve for those creating new/own cards. Like Arduino of instrumentation :) Chassis alone will not work, it shall be whole ecosystem of affordable, easy DIY instrumentation.

Reference hw/sw design of few typical cards shall be available, as well as "card SDK". Would be supercool if AVR or even Arduino-based cards are shown as examples. I would like stm32-series, but do not insist on that. No need to create very complex instrumentation API. It's enough to create communication API for instruments. Host communications could be very simplified like sendvariable(char *name, double value); senddataarray(char *name, double *pdata, int size). Receive functions - just typical function callbacks, registered by variable name. Obviously card can have other (optional) modes of communication such as SCPI.

Quote
Anything else I need (~30 trigger signals, analog routing, fast LVDS connections) is probably outside the scope of this project

What about extension bus for hi-end features? Cards are wide enough. You can put Two connectors on advanced cards, one on standard version cards.
 

Offline welterde

  • Contributor
  • Posts: 19
Re: "DIY instrumentation bus" (or DIB)
« Reply #118 on: March 08, 2018, 02:34:41 am »
It's you who suggested that card creator can create HAL himself over SPI bus, suggesting that DIB is nothing more than just physical and electrical definition of backplane. Bus is more than that. W/o higher level API and good software indeed it is more or less useless.

I did not say anything about HAL, I said - you have to abstract hardware. Control software shall not directly write into ADC or DAC registers. No matter - such function lives in the HAL layer of controller or not. It shall control voltage of power supply, not DAC counts. Module itself shall apply all the compensation and calibration. Those who write control software shall be freed from reading ADC or DAC chip datasheets and those who are good doing electronics, shall be freed from coding anything else than MCU they know.

Ah.. I misunderstood you then. When I read control software I thought you meant the software controlling the internals of the power supply not something that might control multiple power supplies, etc.

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

Quote
Anything else I need (~30 trigger signals, analog routing, fast LVDS connections) is probably outside the scope of this project

What about extension bus for hi-end features? Cards are wide enough. You can put Two connectors on advanced cards, one on standard version cards.

Yes, this has been proposed before. But I don't really think it's useful for what I have in mind. For more general purpose stuff I am all for it.

 

Offline prasimixTopic starter

  • Supporter
  • ****
  • Posts: 2022
  • Country: hr
    • EEZ
Re: "DIY instrumentation bus" (or DIB)
« Reply #119 on: March 08, 2018, 07:36:56 am »
My proposal would be to have a shared SPI bus for slow control with 3 per-module chip-select signals.
One CS signal would be used for an SPI EEPROM that contains information about the module and the other 7 possible combinations can be used for other SPI devices on the module (similar to what has been suggested before).
One can easily generate the actual CS signals with an 3-to-8 decoder IC - or directly use the three lines if it's less than four devices.

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

Quote
Hence my suggestion to have a per-module LVDS SPI bus separate from the slow shared SPI bus (still not sure if using LVDS is really neccessary).

Sure. LVDS SPI. Complexity will be very appealing for 3rd party module designers.  :-DD

Please let me know how "LVDS SPI" is different then "RS485 SPI" that you proposed? Both require line drivers, but in both case it's completely irrelevant what type of higher layer signaling (i.e. SPI) is used for communication. Do you want to say that LVDS presume more challenging PCB routing?


Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: "DIY instrumentation bus" (or DIB)
« Reply #120 on: March 08, 2018, 10:06:01 am »
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).

Oh, I see. Additional SIPO register for chip selects, then EEPROM for module info, unusual SPI clocking. All this mess for what? To me it seems like MCU-phobia rather than rational & farsighted design.

Please let me know how "LVDS SPI" is different then "RS485 SPI" that you proposed?

For a record I did not propose RS485 SPI:

I would add RS485 or RS422 to the list:
+ common bus, does not need mux
+ still async serial

Most commonly used and known LVDS topology is point-to-point. RS485 including it's transceivers is multidrop by design. That's the difference.

IMHO problem of multidrop LVDS SPI is slave SOMI output. Only way I imagine LVDS SPI is: point-point lines for each SOMI->MISO connection which are mux'ed on the master side. That obviously I consider as much more complex than rs485 which have both transmit and receive as multidrop topology.
« Last Edit: March 08, 2018, 11:30:54 am by ogden »
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: "DIY instrumentation bus" (or DIB)
« Reply #121 on: March 08, 2018, 10:25:02 am »
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).
 

Offline prasimixTopic starter

  • Supporter
  • ****
  • Posts: 2022
  • Country: hr
    • EEZ
Re: "DIY instrumentation bus" (or DIB)
« Reply #122 on: March 08, 2018, 11:27:43 am »
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).

Oh, I see. Additional SIPO register for chip selects, then EEPROM for module info, unusual SPI clocking. All this mess for what? To me it seems like MCU-phobia rather than rational & farsighted design.

Not really, such irrational design is based on an attempt to provide support for at least 6 peripheral modules while on the MCU/CPU/Master/#0 module only 96-pin connector is utilized (as basic/mandatory connector). You can try an exercise for yourself and see how fast you will run out of available pins.
If you can recommend connector with higher pin count that does not cost a fortune and is easily to obtain, please let me know.

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: "DIY instrumentation bus" (or DIB)
« Reply #123 on: March 08, 2018, 11:39:54 am »
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.
 

Offline void_error

  • Frequent Contributor
  • **
  • Posts: 673
  • Country: ro
  • I can transistor...
Re: "DIY instrumentation bus" (or DIB)
« Reply #124 on: March 08, 2018, 12:05:33 pm »
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.

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...
Trust me, I'm NOT an engineer.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf