Recent searches
Search options
Thinking about switching my supervisor MCUs to use i2c instead of spi for interfacing to the main CPU.
Rationale: uses two less pins, can be combined with sensors and other system health stuff on 3v3_sb power domain, simpler code with no hard realtime constraints since you can clock stretch if the other side isn't ready, and it doesn't need to be fast at all.
I'm getting increasingly fed up with making SPI peripherals in software because you have unnecessarily tight hard realtime constraints to make the protocol work (if you don't respond within the set time the other side reads garbage).
In gateware you can easily enforce cycle accurate timing and on the host side the timing isn't critical.
SPI plus an extra IO for flow control would work but of course now it's a 5 wire bus competing with 2. So difficult to justify the pin cost in most cases
@azonenberg you could also do it SD/eSPI-style: return all-ones while not ready
@whitequark at least that's not as cursed as eSPI with the weird non-byte-sized fields in some message types...
@azonenberg 2 pins and multidrop is the big one. Otherwise I often go with plain serial. Scales to tens of Mbps, tunnels over everything. Drop RS-485 xcvrs in and you've got 100m differential in industrial environments for less than a dollar.
@AMS This is specifically for on-board management, so range and speed don't really matter.
It's for things like the main CPU querying the temperature of the power supply, or requesting a soft shutdown / warm reboot.
@azonenberg Yeah, best to I2C for that. You can hang PMICs, digipots, and eeproms off it too then.
@AMS The STM32L431 in question *is* the PMIC. It's got GPIOs to EN/PGOOD of every regulator in the board, reset of the FPGA and main CPU, and manages all the rail sequencing.
Depending on the complexity of the design it often does things like fan PWM and temp/voltage sensor tracking too.
@AMS @azonenberg I2C has its own issues. I have seen problems where glitches created by I2C isolator/repeater devices have caused chips hanging off the bus to lock up completely.
@StumpyTheMutt @AMS Not a problem in a point to point system.
@azonenberg @AMS point to point as in one device on each I2C bus? That's what we ended up doing to avoid that sort of problem.