It’s getting closer! This will be a minipost addressing the last design conundrum in the signal board – how to get the optocoupler input to play nice with a programming linker. Last time, I discovered that the USB linkers didn’t play nicely with my oddball bidirectional optocoupler setup, so I halved the bidirectional opto and pushed a new board revision. Clearly, I didn’t get to the bottom of what the mysterious 1-wire bidirectional serial-like bus of the popular SimonK/BLHeli bootloaders want, so here is my short investigation.
What happened was while I could use the R/C input side of the optocoupler, the programming header only worked without a pulldown resistor. This, of course, meant the optocoupler no longer worked, so I was still in the same state as before.
I already understood that my preference for pulldown resistors is the opposite of “normal” practice which is pullup resistors, but wanted to try to see if it would play anyway. I guess not :(
So I fully decoupled the opto to watch what the bus wants to do when it’s being programmed. Here’s the sequence of exchanges between the programmer and the board. The programmer talks in 3.3v but the microcontroller responds in 5V, then there is an idle waiting period which is pulled high.
With the programmer plugged in but not transmitting, the line is pulled high to 3.3v. This works with the bootloader detector in the firmware such that when it wakes up, it will not activate the main program if it detects logic high for a certain time period.
The programmer initiates communication first at 3.3v. I wonder if it’s 3.3V because it’s an easy voltage to regulate down to from the 5V of the USB connector, and keeps the programmer compatible with controllers that might use 3.3V (as not all micros have higher voltage tolerant pins).
And the chip responds using 5V (or if this were a 3.3v board, it would also be 3.3v). I can’t be arsed to actually decypher or research the bus, I just want my electrical interface to work. Open-collector (pull-up) logic buses have a benefit of being able to tolerate different voltage levels on different devices like this, so I guess that’s why it’s more standard practice!
As I feared, my pull-down style optocoupler forced the bus idle state too low for either process to begin. It seems like the default state is high impedance or at least a VERY high resistance pullup, because this was taken using a 10K pulldown resistor (which caused the opto to be extremely noisy, so it was going to be unusable)
Okay, okay, fine. I’ll change the opto circuit to be a pullup like a competent EE and use the Inverted input setting in SimonK.
Some little blue wire edits to the board to change the configuration permanently, and we have a working board which can both program with a USB linker AND take opto-isolated R/C signal in! The irony is not lost on me that the original, unmodified I2C bidirectional optocoupler circuit would have worked just fine with the bus, but I’m not going to go back to it at this time. :'(
Oh, by the way, the LEDs? They’re also pulled up by default and the chip pin is driven low or turned off to light them. Like the opposite of how I want it.
Alright, time to commit the Little Blue Wires to the board. I swear, this is the last revision! Right now with the edited board, all I need to do is flash the initial firmware payload on using a chip socket. From there, I can then use the AfroESC USB dongle to talk using the PROG header. A commercialized Brushless Rage will come with the bootloader-enabled firmware and Reasonable Settings already written.
Detroit Maker Faire is coming up in 2 weeks, and I’m intending to take a batch of Brushless Ragebabies there to get them whipped into shape! And coming up soon, a writeup on modifying the FiTech Fuel Command Center to not melt down.