We just released new Brick firmwares that fix three important bugs:
- Fix RS485 timing bug. This is a very old bug that we were not able to figure out for many years. Bricklets that use I2C (for example Temperature Bricklet) would somtimes give false values every few 1000 messages if RS485 was used. This was caused by a mix of I2C/RS485 timing constraints. We now use DMA for I2C Messages to fix this.
- The handling of the initial enumeration (the enumerate callback with enumeration type = CONNECTED) has been completely reworked. Double enumerations don't happen anymore and the enumeration also works if a USB cable is connected to an already powered stack. This also fixes some other strange behavior. For example: In a RS485 network, if you restarted the RS485 master stack you had to restart the slave stacks as well, otherwise they wouldn't enumerate again. With the update the RS485 slaves will automatically re-enumerate if the RS485 master re-enumerates itself.
- We will now never do a real hard reset if triggered by USB. USB has reset/suspend/resume messages that triggered a hardware reset (internal messages). There are several possibilities, when a PC can trigger these messages. For example on startup or when the USB hardware detects EMI. So far the Brick firmware simply resets the hardware. With the new firmwares the USB state machine will be properly resetted (as requested by the PC), but everything else will keep on running. So the Bricks/Bricklets will not loose state and for example a stepper motor will keep running until the request is fully processed. From the PC perspective the Brick will disconnect and immediately connect again. A new initial enumeration will be send. If you have problems with unwanted resets (for example if a relay switches an inductive load) this will probably fix this issue! The PC will still reset the USB, but from the user perspective everything will keep running and working, no lost messages or similar.
Especially the last one (relay switching resulting in stack resets) is a problem that we have heard sometimes, but we where never able to reproduce that. A few weeks ago we finally were able to create a setup here where we could reliably reproduce this problem. After many hours of debugging it turned out that the problem is that the PC registeres an EMI event through the USB cable and as a result tells the Brick to reset itself (on Linux this happens if you get the dmesg message "disabled by hub (EMI?), re-enabling ..."). This reset will now not result in a real hardware reset anymore and everything will just keep running even if your USB hub does a reset.
To fix this we had to restructure a lot of code, we used this restructering to improve the hotplug/enumeration functionality a lot.