Trying to harness the #fediverse #electronics #hobbyist #brain ...
I've got a busted consumer product here that has 2 #Holtek #microcontrollers in it. Either one would be sufficient to run this product (a brushless-motor tower fan), but #MCUs are cheap, so why not throw a second one in if it saves a few centimeters of wire?
I'm trying to determine if there's a #standard #serial #physical #layer in use here to communicate from one #MCU to the other. It's one-way communication.
[...]
The connection from one MCU to the other is a single #signal #wire, plus shared #power and #ground. It's a point-to-point link; there's no addressing involved. It's simplex, so no collision detection or anything complicated.
In fact, it's dirt-simple, and extremely low-bandwidth. The secondary MCU transmits a single #byte of data to the primary MCU approximately every 120ms. So ~70 bits per second, max.
The signal line has a #pullup #resistor at the primary end.
[...]
The other MCU pulls the signal wire to #ground to xmit.
The MCUs - Holtek BS82C16A-3 and BS84B08A-3 - natively support #SPI and #I2C, but this isn't either of those.
Each #frame with one byte of data starts with a long (~10ms) low pulse (for #sync, presumably), followed by the #data line returning high for ~5ms, then the data bits are transmitted as low #pulses of different durations for 0 and 1 - 0.6ms and 2.8ms.
The eight data bits are followed by a stop/end bit, always short.
[...]
So there are always the same number of pulses per frame, but the time duration of the frame varies based on the contents of the data bits, as 1s take longer to transmit than 0s.
I looked up obvious candidates like #1wire, but that appears to be proprietary, and uses an addressing scheme anyways. It's not plain #UART-style, as it's not using high/low signal levels to indicate the bits. It's not SPI or I2C or a bunch of others.
[...]
I presume they've implemented the transmit with simple bit-banging a GPIO line.
I want to replace the secondary MCU with one of my own. I can implement the interface with just bit-banging, too, but if I don't have to - because it's a standard and someone has already written #code for the #RP2040 / Raspberry Pi Pico - then that would be great.
Anyone know if this is a standard I haven't found?