Njay got the burned bridge rebuilt, tested, and “burned-in” for an hour at 10Amps, so we got together again to finish integrating the system.
This time with the 500 kbps I²C bus between the RasPi and the Power Bridges, so that the link is loud and clear. Njay was afraid that such high speeds would degrade the signal enough to cause trouble, but it looks like our cabling is good enough – even though some curving of the signal edges is visible with the scope, in my testing I’ve never seen a single error at 500kbps. Besides, all chips involved support up to 1Mbps… don’t be a chicken. 🙂
Still, we decided it was past overdue to implement some kind of double-check on the Bridge side for the “PWM Speed” register writing. Njay modified the communication protocol in the Bridge firmware to include a check byte when writing to any register of the bridge; the check byte comes before the data byte, and it must be bitwise inverted relative to the data. I updated my python driver as well, and we lived happily ever after. 🙂
Of course, this took us a couple of hours to do due to all sorts of shenanigans that just keep happening… like the bridges mysteriously refusing to program new code, or me not having a simple unit testing script and hacking around complicated programs to do simple testing, or the USB hub on the Trike malfunctioning and killing the WiFi connection, or… you get the idea. Never a dull moment.
Anyways, the double-check is in place, so if somehow the Trike sends garbage to the Bridge it just gets ignored. These two measures (500kbps bus and Check byte) made the comms quite robust. I’m currently pumping data back and forth between the RasPi and each Bridge 20 times per second, but there is plenty of time left for more if needed – each read/write operation takes less than 1ms. It’s a pleasure to see such a tight system working.
So let’s take a ride, shall we? 🙂
Now we’re working on another safety measure: how to guarantee that, once the communication is lost between the RasPi and one or the two Bridges, both of them will shut down the motors. Ideas are plenty and none of these problems are hard to solve conceptually, but Njay has been fighting continuously the hard limit of 2kB on the Atmel EEPROM. Every time we need to implement something new, we have to eliminate some other code or else it will not fit into the Bridge memory. Never a dull moment.
Njay’s experience with the AVR chips and the C compiler is priceless, he programs in C while thinking how many bytes it is going to occupy in machine code. Guru level. I’m more like: “I don’t need it to blink the LED on startup, get rid of that. Do you really need the internal checksum for the EEPROM? What are the chances of corruption there?…”