4 ms·

I think you should submit your project page [1] as another show HN, I found it to be interesting Some thoughts: - Agreed with not using I2C, I2C has been iden

by minetest2048 2y ago

I think you should submit your project page [1] as another show HN, I found it to be interesting Some thoughts: - Agreed with not using I2C, I2C has been identified as a root cause in several cubesat mission failures: https://pure.tudelft.nl/ws/portalfiles/portal/10531886/art_3A10.1007_2Fs12567_016_0138_0.pdf https://pure.tudelft.nl/ws/portalfiles/portal/10531886/art_3... and https://webapps.unsworks.library.unsw.edu.au/fapi/datastream/unsworks:64091/bin2ba838a3-66f0-4790-8a76-2ab574d77723 https://webapps.unsworks.library.unsw.edu.au/fapi/datastream... (yes clock stretching is evil). I2C should be banned for multi board communication - Classic CAN have very small 8 byte MTU with frame preemption, which is actually useful for its intended purpose of time critical automotive data transfer. If that 4 byte brake packet is blocked by a 1500 byte packet then your car will crash and explode. But the tradeoff is that this makes it very slow for bulk data transfer

RedShift1 2y ago
Wtf, I2C in a satellite!? I am by no means an electrical engineer or know anything about doing stuff in space but it seems absolutely obvious to me if you require any sort of communication, that you use differential signaling. Even on earth you can have interference, in space with all its radiation it's guaranteed. I'm surprised anything worked at all with I2C.
- semi-extrinsic 2y ago
  Yes, I2C is technically meant for intra-board use. But it works surprisingly well over large distances if you avoid daisy chaining and run one cable to each target. If you use multiple identical target chips you need to route everything individually to a central MUX anyways. As an example, the Nintendo Switch used I2C over a ~2m cable to communicate between the controller and nunchuck. Worked fine even in noisy household settings with wifi and microwaves and whatnot. At work we've used sensors for data logging that communicate using I2C over distances more than 20 meters, using plain Cat5 cable.
  - TaylorAlexander 2y ago
    Thanks for this! I recently designed a sensor board that connects to our main board with I2C, and in chatting with an EE about it she mentioned I2C is not intended for intra-board use. I just put a scope on the signals yesterday and they seem okay. The cable is only 15cm long, and it connects to a multi-use port which would be difficult to make work with differential signals in addition to the other things that port can do. I’ll keep an eye on it but maybe it’s okay.
    - kenz0r 2y ago
      If you _must_ use I2C, then look at SMBUS if its an option for the parts. I2C's biggest failing is that there is no protocol level timeout, so one stuck device can block your entire bus unless you have a reset line for all the peripherals on it. https://www.analog.com/en/resources/design-notes/guide-to-comparing-ic-bus-to-the-smbus.html https://www.analog.com/en/resources/design-notes/guide-to-co...
      - fl7305 2y ago
        Classic I2C problem. After your CPU resets, at least clock out a bunch of cycles onto I2C to get interrupted I2C transactions to finish.
      - TaylorAlexander 2y ago
        Ooh this is great to know thank you!
    - crote 2y ago
      I2C doesn't really care about cable length all that much. The thing to keep in mind is the interplay between bus capacitance, pullup strength, and drive strength. A longer cable means more bus capacitance, which means with the same pullup resistor the signal rise time will be higher, which means you need to reduce the bus speed. A stronger pullup will reduce the rise time (allowing a higher bus speed), but each chip's driver has to be able to overpower the pullup too. If the pullup is too strong for the drivers, you end up being unable to send a zero. In practice your cables can be quite long, you just have to run it at a lower speed. If you really want to push it, there's always transceivers like the PCA9615 which turn it into a differential bus.
- wildzzz 2y ago
  You usually don't find I2C in the high end space-rated parts simply due to the added complexity of a simplex protocol but you see tons of single-ended SPI parts. You don't need diff pairs unless it's for high speed or long cable runs. If your controller (FPGA, microcontroller, etc) has the resources, a good idea is to have a single SPI slave per master. Also since SPI is not standardized, vendors may have different signaling requirements which makes it slightly more difficult to put different chips on the same bus. Talking to SPI chips is super easy and can be implemented entirely in 7400-series logic if you want so it's entirely possible to have analog electronics send control signals to SPI devices without a single CPU in sight.
deleted 2y ago
[deleted]

RedShift1 2y ago

Wtf, I2C in a satellite!? I am by no means an electrical engineer or know anything about doing stuff in space but it seems absolutely obvious to me if you require any sort of communication, that you use differential signaling. Even on earth you can have interference, in space with all its radiation it's guaranteed. I'm surprised anything worked at all with I2C.

semi-extrinsic 2y ago
Yes, I2C is technically meant for intra-board use. But it works surprisingly well over large distances if you avoid daisy chaining and run one cable to each target. If you use multiple identical target chips you need to route everything individually to a central MUX anyways. As an example, the Nintendo Switch used I2C over a ~2m cable to communicate between the controller and nunchuck. Worked fine even in noisy household settings with wifi and microwaves and whatnot. At work we've used sensors for data logging that communicate using I2C over distances more than 20 meters, using plain Cat5 cable.
- TaylorAlexander 2y ago
  Thanks for this! I recently designed a sensor board that connects to our main board with I2C, and in chatting with an EE about it she mentioned I2C is not intended for intra-board use. I just put a scope on the signals yesterday and they seem okay. The cable is only 15cm long, and it connects to a multi-use port which would be difficult to make work with differential signals in addition to the other things that port can do. I’ll keep an eye on it but maybe it’s okay.
  - kenz0r 2y ago
    If you _must_ use I2C, then look at SMBUS if its an option for the parts. I2C's biggest failing is that there is no protocol level timeout, so one stuck device can block your entire bus unless you have a reset line for all the peripherals on it. https://www.analog.com/en/resources/design-notes/guide-to-comparing-ic-bus-to-the-smbus.html https://www.analog.com/en/resources/design-notes/guide-to-co...
    - fl7305 2y ago
      Classic I2C problem. After your CPU resets, at least clock out a bunch of cycles onto I2C to get interrupted I2C transactions to finish.
    - TaylorAlexander 2y ago
      Ooh this is great to know thank you!
  - crote 2y ago
    I2C doesn't really care about cable length all that much. The thing to keep in mind is the interplay between bus capacitance, pullup strength, and drive strength. A longer cable means more bus capacitance, which means with the same pullup resistor the signal rise time will be higher, which means you need to reduce the bus speed. A stronger pullup will reduce the rise time (allowing a higher bus speed), but each chip's driver has to be able to overpower the pullup too. If the pullup is too strong for the drivers, you end up being unable to send a zero. In practice your cables can be quite long, you just have to run it at a lower speed. If you really want to push it, there's always transceivers like the PCA9615 which turn it into a differential bus.
wildzzz 2y ago
You usually don't find I2C in the high end space-rated parts simply due to the added complexity of a simplex protocol but you see tons of single-ended SPI parts. You don't need diff pairs unless it's for high speed or long cable runs. If your controller (FPGA, microcontroller, etc) has the resources, a good idea is to have a single SPI slave per master. Also since SPI is not standardized, vendors may have different signaling requirements which makes it slightly more difficult to put different chips on the same bus. Talking to SPI chips is super easy and can be implemented entirely in 7400-series logic if you want so it's entirely possible to have analog electronics send control signals to SPI devices without a single CPU in sight.

deleted 2y ago

[deleted]