"DIY instrumentation bus" (or DIB)

[void_error]

@prasimix & everyone else: Sorry for flooding this thread with useless posts...
@ogden: Please review your post before making accusations.

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. 

[khs]

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.

Hmm..

I would reserve the first 16 bytes of the first (optional) SPI EEPROM to store a GUID to identify the 'manufacturer'.

Not more, not less.

After the GUID additional information can be stored - depending on the requirements of the board.

[jbb]

Data structures for the ID information would be an issue, yes.

At a bare minimum: manufacturer, model, serial #, HW version, FW version.

Then communications settings (type, speed, use of external trigger bus etc.). And maybe calibration data.

As you can see, it gets quite complicated.

[technix]

For the ID information it might be a good idea to design some kind of interface description language that can be parsed by the host to extract information about the interface type, protocol, format, unit of measurement and calibration curve.

The interface type, protocol and format description language can take inspiration from the USB HID Report Descriptor language, since it already describes fields and formats in a bit by bit fashion.

The unit of measurement can be expressed using a 4-byte identifier: first 7 nibbles are each a 4-bit signed integer representing the exponent above each of the SI base unit in the order of meter-kilogram-second-ampere-kelvin-mole-candela, and the last nibble representing a variant of the same base unit expansion (like joule as energy versus newton•meter as torque, which have an otherwise identical identifier.) For example newton is 0x11e00000, volt is 0x21df0000.

The calibration curve describes the relationship between raw data and the measured value in that unit using a polynomial approximation, expressed using the coefficients of increasing order in 16-bit IEEE 754 half precision floating point numbers.

[xani]

The unit of measurement can be expressed using a 4-byte identifier: first 7 nibbles are each a 4-bit signed integer representing the exponent above each of the SI base unit in the order of meter-kilogram-second-ampere-kelvin-mole-candela, and the last nibble representing a variant of the same base unit expansion (like joule as energy versus newton•meter as torque, which have an otherwise identical identifier.) For example newton is 0x11e00000, volt is 0x21df0000.

Considering that most units would just... fit as 4 bytes of ascii characters or less, that seems like needless complication. Just (standarized) textual representation of unit would be enough. Would also be more flexible

[Blinkenlights]

@Technix: Your "unit of measurement" statement is worth following up - do you have any more information?  Can you point me towards a specification that uses this approach, or a prior implementation, or - if your own concept - could you put a little more description behind it?

The unit of measurement can be expressed using a 4-byte identifier: first 7 nibbles are each a 4-bit signed integer representing the exponent above each of the SI base unit in the order of meter-kilogram-second-ampere-kelvin-mole-candela, and the last nibble representing a variant of the same base unit expansion (like joule as energy versus newton•meter as torque, which have an otherwise identical identifier.) For example newton is 0x11e00000, volt is 0x21df0000.

[technix]

The unit of measurement can be expressed using a 4-byte identifier: first 7 nibbles are each a 4-bit signed integer representing the exponent above each of the SI base unit in the order of meter-kilogram-second-ampere-kelvin-mole-candela, and the last nibble representing a variant of the same base unit expansion (like joule as energy versus newton•meter as torque, which have an otherwise identical identifier.) For example newton is 0x11e00000, volt is 0x21df0000.

Considering that most units would just... fit as 4 bytes of ascii characters or less, that seems like needless complication. Just (standarized) textual representation of unit would be enough. Would also be more flexible

Try describe the unit of Newtonian constant of gravity... That is 0x3fe00000 here. Also this produces a uniformly lengthed representation of all units regardless of its textual representation and is easy to manipulate in code.

[xani]

The unit of measurement can be expressed using a 4-byte identifier: first 7 nibbles are each a 4-bit signed integer representing the exponent above each of the SI base unit in the order of meter-kilogram-second-ampere-kelvin-mole-candela, and the last nibble representing a variant of the same base unit expansion (like joule as energy versus newton•meter as torque, which have an otherwise identical identifier.) For example newton is 0x11e00000, volt is 0x21df0000.

Considering that most units would just... fit as 4 bytes of ascii characters or less, that seems like needless complication. Just (standarized) textual representation of unit would be enough. Would also be more flexible

Try describe the unit of Newtonian constant of gravity... That is 0x3fe00000 here. Also this produces a uniformly lengthed representation of all units regardless of its textual representation and is easy to manipulate in code.

I'm not a physicist so pardon my ignorance but... G? I don't know what you exactly mean by "unit of Newtonian constant of gravity.", do you mean constant itself?

Aside from that, is that some kind of standard of representing units ? Are there libs for it ? Because writing "if unit == "V"' is a pretty low barrier to entry compared to "here are those magical numbers that mean Volt, just trust me on it"

[technix]

The unit of measurement can be expressed using a 4-byte identifier: first 7 nibbles are each a 4-bit signed integer representing the exponent above each of the SI base unit in the order of meter-kilogram-second-ampere-kelvin-mole-candela, and the last nibble representing a variant of the same base unit expansion (like joule as energy versus newton•meter as torque, which have an otherwise identical identifier.) For example newton is 0x11e00000, volt is 0x21df0000.

Considering that most units would just... fit as 4 bytes of ascii characters or less, that seems like needless complication. Just (standarized) textual representation of unit would be enough. Would also be more flexible

Try describe the unit of Newtonian constant of gravity... That is 0x3fe00000 here. Also this produces a uniformly lengthed representation of all units regardless of its textual representation and is easy to manipulate in code.

I'm not a physicist so pardon my ignorance but... G? I don't know what you exactly mean by "unit of Newtonian constant of gravity.", do you mean constant itself?

Aside from that, is that some kind of standard of representing units ? Are there libs for it ? Because writing "if unit == "V"' is a pretty low barrier to entry compared to "here are those magical numbers that mean Volt, just trust me on it"

Yes, that constant G. It has a unit. Try describe that in a FourCC.

Indeed you can say that if (unit == UNIT_VOLTAGE) is low barrier. However when you need to track a lot of different measurements with different units, you can get lost very fast. This representation of units is intended to provide a fixed length and easy manipulation regardless of the complexity of the unit, allowing for a uniform representation of values.

[Kleinstein]

The idea of bringing the units back to the basic Si units is a logic idea.  The Si connected units are usually just a combination of powers of the 7  basic units. In most cases a power up to 4 should be enough, so that one can also cover cases where a square root appears. However this already limits the the power to a +4 to -3.5 range, if only 4 bits are used.  So there might be a few odd SI units that do not fit the pattern. The square roots are rare, but they sometimes come up, like in spectral noise voltage often given as nV/Sqrt(Hz). One night get around this most of the time by having a extra Bit to have the square root on the whole unit.

Another complication is that even the same combination of basic SI units might represent a different unit. For example torque is measured in Nm while energy is measured in Joule, with 1 J = 1 N * 1 m, but one should not use Joule for a torque and Nm for an energy is kind of misleading.  A similar problem appears with the Hz, that is reserved to be used for the frequency of a periodic process. So one should not use Hz for something like a count rate or the circular frequency or rate of angular change.

Not all units are directly SI derived. A prominent example are the logarithmic parts like dB with all the different reference levels. Color metric is another example not covered by SI.

[xani]

The unit of measurement can be expressed using a 4-byte identifier: first 7 nibbles are each a 4-bit signed integer representing the exponent above each of the SI base unit in the order of meter-kilogram-second-ampere-kelvin-mole-candela, and the last nibble representing a variant of the same base unit expansion (like joule as energy versus newton•meter as torque, which have an otherwise identical identifier.) For example newton is 0x11e00000, volt is 0x21df0000.

Considering that most units would just... fit as 4 bytes of ascii characters or less, that seems like needless complication. Just (standarized) textual representation of unit would be enough. Would also be more flexible

Try describe the unit of Newtonian constant of gravity... That is 0x3fe00000 here. Also this produces a uniformly lengthed representation of all units regardless of its textual representation and is easy to manipulate in code.

I'm not a physicist so pardon my ignorance but... G? I don't know what you exactly mean by "unit of Newtonian constant of gravity.", do you mean constant itself?

Aside from that, is that some kind of standard of representing units ? Are there libs for it ? Because writing "if unit == "V"' is a pretty low barrier to entry compared to "here are those magical numbers that mean Volt, just trust me on it"

Yes, that constant G. It has a unit. Try describe that in a FourCC.

As I already said, I do not know that unit so I can't even try to do it. But I imagine there would be edge cases requiring more than 4 characters.
I don't think it really is a  big problem, If I wanted to have binary protocol I'd just use TLV (type,length,value)-type encoding for fields (or just go lazy way and use Protobuf) instead of trying to keep everything same length.

Indeed you can say that if (unit == UNIT_VOLTAGE) is low barrier. However when you need to track a lot of different measurements with different units, you can get lost very fast. This representation of units is intended to provide a fixed length and easy manipulation regardless of the complexity of the unit, allowing for a uniform representation of values.

Well there is always a chance someone mistypes and instead of just using "A" they use "mA", or even "ma".

But on other side you can represent units that are not SI without having internally convert it before sending (and probably also converting it back before displaying, if you are measuring kcal for example you probably do not want result in joules).

I think you also skipped a few units, because I think representing angular speed is impossible too

And there are units that can just not be converted, at least not easily representable in 4 bytes

Like take humidity for example. The absolute unit is grams of water vapor per cubic meter volume of air.  The relative unit is usually represented as %, which for unit type is too vague.

In your proposed representation AFAIK it is impossible to write any of them.

In text representation it is still really awkward but possible (like Rhum/Ahum or RH/AH ).

Of course, there is another way, just a big list of ID -> unit type, but while that does not allow any wiggle room for mistakes and takes least space, it is awkward to manage when everyone have to have same list of magic numbers

Same with other measurements like pH.

[technix]

Indeed you can say that if (unit == UNIT_VOLTAGE) is low barrier. However when you need to track a lot of different measurements with different units, you can get lost very fast. This representation of units is intended to provide a fixed length and easy manipulation regardless of the complexity of the unit, allowing for a uniform representation of values.

Well there is always a chance someone mistypes and instead of just using "A" they use "mA", or even "ma".

There is one and only one unit for each measurement, so only the input parsing front end have to deal with the mistypes.

But on other side you can represent units that are not SI without having internally convert it before sending (and probably also converting it back before displaying, if you are measuring kcal for example you probably do not want result in joules).

I do intend to rely on internal data conversions. In most cases since SI is a metric system floating point numbers work perfectly.

I think you also skipped a few units, because I think representing angular speed is impossible too

Give me an example of a unit not representable as either dimensionless or a combination of the seven SI base units. Angular speed is expressed as rotational frequency in hertz.

This is an example of the related units exclusion principle: for physical quantities that have a one to one correspondence, only the one with the simplest SI base unit expansion of the set is defined, and every other quantity is represented by converting to the defined one. In this case angular speed is 2 * pi * frequency establishing a linear one to one correspondence, and since frequency (in hertz = 1/s) is simpler than angular speed (in rad/s) frequency is defined and angular speed is represented using frequency.

And there are units that can just not be converted, at least not easily representable in 4 bytes

Again, give me an example of a unit not representable as either dimensionless or a combination of the seven SI base units.

Like take humidity for example. The absolute unit is grams of water vapor per cubic meter volume of air.  The relative unit is usually represented as %, which for unit type is too vague.

Absolute humidity is a mass per volume concentration. Relative unit is dimensionless (pressure over pressure). Percentage just means a dimensionless number.

In your proposed representation AFAIK it is impossible to write any of them.

I just did.

In text representation it is still really awkward but possible (like Rhum/Ahum or RH/AH ).

It is possible although it takes a bit of thinking, keeping the related unit exclusion rule in mind.

Of course, there is another way, just a big list of ID -> unit type, but while that does not allow any wiggle room for mistakes and takes least space, it is awkward to manage when everyone have to have same list of magic numbers

You can treat it this way. Being logically allocated, at least those ID's are easy to understand. Still keep in mind that this unit representation allows you to manipulate it using an algorithm, instead of relying on either parsing the text or non-structured identifiers (requiring a new software revision when BIPM folks came up with a new name for a unit.)

Same with other measurements like pH.

pH is another case of related units exclusion principle: it is the negative logarithm of the molar concentration of hydrogen (or hydronium) ions. The logarithm actually messed the units representation up, so it is treated as more complex than molar concentration. Thus, pH is expressed in term of molar concentration.

[Blinkenlights]

While keen to find to find the best ID system for a product such as this, I am reminded that such systems are frequently ignored. Many years ago I worked with a quite brilliant, methodical engineer who informed me that the company guesstimated the maximum current for its PCI cards at design time, and wrote it into the ID settings PROM. I had a minor double take, considering the respect I had for this mans prior work. But perhaps I just had to add pragmatic to list of abilities - is someone paying them to do a second (albeit quick) round of engineering evaluation to gather final production engineering parameters and write them into the ID settings? No. Are they a commercial company? Yes. Does the value written into the ID settings make the product less functional? Not really, because compliance was not widespread.

My take on this: Highly ethical or "perfectionist" (I do not use that label myself) individuals/companies will do the right thing by all the ID fields. Others may not. The most useful thing would be a system which the worst of us cannot ignore - something simple like Country of Manufacture, Manufacturer, Model name, Date of manufacture (or at least the year) and ideally revision level, and ideally serial number.  There may be several Manufacturers with the same name - but country law usually means just one with each name in a country.  This probably gives enough info for a clever software module in the host to be able to track down and workaround some horrible short coming in a common shipped PCB - perhaps only present on boards made before 2018 (etc). 

That is going to make your whole ID system worthwhile - even if SI units are not included - or even if they are. Make the bar to entry quite low.

[xani]

In text representation it is still really awkward but possible (like Rhum/Ahum or RH/AH ).

It is possible although it takes a bit of thinking, keeping the related unit exclusion rule in mind.

In 4 bytes ? I'd think that after converting to base SI units you'd run out of space for some of the more complex ones...

And that's not the point, I want a system that gets me values and then I do stuff with it, if code to decode "what the hell is that value in normal units" is longer and more complex than rest of the code... well most would probably just write few lines that do "if that magic number is there, multiply by X to get the result in useful units" and call it a day

Of course, there is another way, just a big list of ID -> unit type, but while that does not allow any wiggle room for mistakes and takes least space, it is awkward to manage when everyone have to have same list of magic numbers

You can treat it this way. Being logically allocated, at least those ID's are easy to understand. Still keep in mind that this unit representation allows you to manipulate it using an algorithm, instead of relying on either parsing the text or non-structured identifiers (requiring a new software revision when BIPM folks came up with a new name for a unit.)

You could just use you idea as a base for generating IDs.

But I think that "just a list" of base units + maybe exponent if for some reason using very small or very big numbers is undesirable (I can imagine the case when someone wants to use cheapo 8 bit micro and just use integer math for measurements) would be good enough.

[technix]

In text representation it is still really awkward but possible (like Rhum/Ahum or RH/AH ).

It is possible although it takes a bit of thinking, keeping the related unit exclusion rule in mind.

In 4 bytes ? I'd think that after converting to base SI units you'd run out of space for some of the more complex ones...

I am only storing the exponents of the 7 base units, each using a 4-bit signed integer. The last nibble is used for distincting between different units with the same dimension. Here is why this uses exactly 4 bytes for all units.

And that's not the point, I want a system that gets me values and then I do stuff with it, if code to decode "what the hell is that value in normal units" is longer and more complex than rest of the code... well most would probably just write few lines that do "if that magic number is there, multiply by X to get the result in useful units" and call it a day

Conversion between units is almost always applying one polynomial to the number. It would be surprising to me if you need more than one line of code for this (except when using assembler.)

Of course, there is another way, just a big list of ID -> unit type, but while that does not allow any wiggle room for mistakes and takes least space, it is awkward to manage when everyone have to have same list of magic numbers

You can treat it this way. Being logically allocated, at least those ID's are easy to understand. Still keep in mind that this unit representation allows you to manipulate it using an algorithm, instead of relying on either parsing the text or non-structured identifiers (requiring a new software revision when BIPM folks came up with a new name for a unit.)

You could just use you idea as a base for generating IDs.

But I think that "just a list" of base units + maybe exponent if for some reason using very small or very big numbers is undesirable (I can imagine the case when someone wants to use cheapo 8 bit micro and just use integer math for measurements) would be good enough.

If you really need to use a 8-bit micro or the like, you can convert units only at ingress or egress of data, and use whatever internal representation you like as long as it is not leaked onto the bus. I made a point to force a fixed length on this unit representation, exactly because it have data exchange in mind, and data ingress and egress algorithms can be a lot more complicated (as you need to match data formats. Fixed length data is a lot easier to capture and check.)

[prasimix]

Last few weeks I spent working on new pin mapping together with @jbb. It continues to be based on serial star topology (point-to-point) between master/CPU/#0 module and peripheral modules since neither many times mentioned here USB and Ethernet unfortunatelly don't fit for purpose. The max. number of periperal modules drops from 7 to 6 (to stay within single 96-pin connector for #0 module), but four general-purpose lines are available for all modules (multipoint) and well as reference clock of 10 MHz and 100 MHz, and SYNC and TRIG lines. Routing differential lines with minimum or no vias was quite chalenging, and I succeed to do that for up to 4 periperal modules. For 5th and 6th modules their point-to-point lines require only one via between top and bottom layer.
New pin mappings looks like this:



As we can see each module has dedicated full-duplex, hi-speed SPI (SCLK, MOSI, MISO i CS) and low-speed (single-ended) IRQ. Depending of module capability two of SPI lines can be used as UART. That of course require that MCU/CPU on the #0 has flexible pins or sort of muxing is implemented. For general purpose signals MLVDS lanes are used (multipoint), where CLK10, CLK100 and SYNC are multidrop. TRIG could be multipoint or multidrop. All of that lanes reqire termination on both ends. One I2C channel is shared between all modules. Additionally NRST (master reset, active low) and NFAULT (active low) are available to all modules.
It's recommended (but still optional) that each module has its own EEPROM connected via shared I2C (SSCL, SSDA) where ifo about module ID, capabilities, usage of bus lines, calibration data, working hours, required firmware/driver, etc. can be stored.
Module's I2C slave address is set with three address pins A0, A1, and A2.
Basic power rails are +5V and +12V, and +Vaux (5V too) is used as backup/standby power that can be sourced via backplane power connector (X5 in schematic below) or from e.g. #0 module. Two pins are assigned for low voltage AC/switched power source that can be used for generating isolated power when module require such thing (e.g. floating power supply module, el. load, etc.). PE (Protective Earth) is also available to each module. Currently using two pins on #0 module and single for other modules. For increased safety/security maybe another one should be added on peripheral modules, too (e.g. A15). PE and GND could be tied together on backplane with an RC element (C5, R20).

Schematic for backplane with 5 modules (CPU/MCU + four peripheral) what I use as an example for PCB routing:









Although backplane should be passive, I decided to put two things on it that is optional but convenient: backplane EEPROM and fan controllers. First one can be used to store some info that is related to chassis (not even #0 module), and second remove needs for extra (and longer) fan cables (that means higher EMI figure) from any of the connected modules. Chosen (AMC6821) works with two temp. sensors (internal/on-chip and external) and support tacho input on 3-wire DC fan. External sensors are placed on the top edge of the backplane (Q2, Q3).

[prasimix]

4-layer PCB for 5 module backplane:

Top:



L1:



L2:



Bottom:



All diff. pairs are routed in accordance with the following calculation:



... using the following rules prescribed by ALLPCB.com:



Therefore all traces are 6 mils wide with 6 mils space inbetween and groundplane spaced 7 mils (~0.18 mm) that is good for ~99 Ohms that is within +/-2.5% tolerance.

[prasimix]

Here is a proposal for enclosure for above mentioned backplane. As you can see I gave up from horizontally placed backplane to vertical one. The enclosure is 4 U tall with module width of 8 HP (~40 mm). MCU #0 module is 120 mm (24 HP) wide that is enough to host a 4.3" TFT touch-screen display (480 x 272). For an extra 10 mm it is possible to host even 5" display for higher resolution (800 x 480). On #0 module front panel is now enough space to place two encoders with 30 mm knobs, few additional I/O connectors, SD card, possibly an USB-A as host. Ethernet and USB-B sockets should go on the the rear panel.

[ogden]

Those connectors are rather expensive, they does not allow reflow soldering as well. Have you considered PCI Express card edge connectors?

[welterde]

I noticed that the 48pin connector is actually slightly more expensive than the 96pin one.. so why not use 96-pin connectors for the non-cpu modules as well? Maybe in a slightly different variant if we don't want the slots to be compatible (although there are other methods to ensure that as well).
That way we also have some more pins available for some more voltage rails (like +/- 15V for analog stuff, etc.), grounds or internal busses (which aren't connected to the CPU module).

And I am glad you switched to a vertical backplane - that way one can pile stuff on top of the enclosure 

[prasimix]

Those connectors are rather expensive, they does not allow reflow soldering as well. Have you considered PCI Express card edge connectors?

PCIe looks interesting due to low connector price and fact that only one connector per module is needed. On the other side that increase a little bit a cost of PCB (due to gold plating). Main obstacle could be routing diff. pairs without going to 6 or more PCB layers (e.g. take a look how diff. pairs are currently routed between two pins). I don't know what is possible, I should try to do that.

I noticed that the 48pin connector is actually slightly more expensive than the 96pin one.. so why not use 96-pin connectors for the non-cpu modules as well? Maybe in a slightly different variant if we don't want the slots to be compatible (although there are other methods to ensure that as well).
That way we also have some more pins available for some more voltage rails (like +/- 15V for analog stuff, etc.), grounds or internal busses (which aren't connected to the CPU module).

Ok, from current experience I can say that one thing is thinking about what to put in pin mappings spreadsheet that is at the beginning empty and allows you to put anything, and another thing is to try to implement that on the PCB layout (and stay within targeted 4 layers) . Adding just one new signal line could ask for rearranging of almost complete existing layout, a real nightmare. Still, if you'd can articulate your wishes in more details please let me know and we'll see if something like that is doable within set limits (i.e. dimension, 4-layer PCB).

[prasimix]

Finally I came into position to test SPI devices select using '595 shift register as announced in #43. It works fine for device selection but doesn't work with some device deselection (e.g. I/O expander MCP23S17-E/SS). The problem is that for changing the target SPI device you have to send 0xFF code over MOSI to instruct '595 to deselect last selected device. But that code received last selected SPI device too (before it being deselected) and that can confuse it. The similar thing can be expected with sending other device CS code to the '595. Therefore idea with just over CS line per peripheral board (or SPI bus) is not "bullet-proof" and at least one more line has to be introduced to separate addressing of '595 from other SPI devices. But with two CS lines and 2-to-4 decoder it's possible to address directly up to 4 devices per board, and whole idea of saving DIB connector lines with '595 doesn't make a lot of sense in many cases. Question is what to do if more then 4 devices is needed. Anyway, whatever is a case I have to revisit latest DIB pin mappings. 

[jbb]

Ah, good thing you tested that and found the problem.

If you go for 2x CS lines you can access 2 chips easily, or 3 with a decoder.
11: not selected
10: device A
01: device B
00: device C

For more chips, you could do some expansion, e.g:
11: not selected
10: end point device selected
01: address pointer selected
00: not allowed

If one chip needs to be extra fast, you could really go crazy:
11: not selected
10: end point device selected
01: address pointer selected
00: fast slave (always acceptable)

[prasimix]

If dedicated SPI channel is used per board, I think that with 2-to-4 decoder its possible to select 4 not just 3 devices, i.e. one (default) will be always selected without interference with SPI channels assigned to other peripheral boards, or not?

[jbb]

In principle, it's posisble to do 4 chips.  But as a practical matter, I would be worried about the following challenges:

• Some master controllers may leave the clock running
• Some master controllers may gang together multiple SPI busses and expect cards to work together even if the bus is operating
• Switching between SPI modes (clock phase and clock polarity) may generate stray clock edges
• Some SPI slaves may have timing limits on their nCS input

Unfortunately, I think the open nature of the DIB means that some 'optimisations' have to be thrown out in the name of reliability and predictability.