@Dee it's actually an 18 pin connector so it uses a TRRRRRRRRRRRRRRRRS connector.
Fediverse quirks I'm still getting used to: When you look at someone's profile in an app (e.g. Tusky) but then you look at their profile in your browser and there's toots you couldn't see before. But if you reply to one of those missing toots on web, it starts showing up in the app.
I guess it's just the way that federation works but it's still weird to me.
Now you can run stupid commands like "edit /sys/kernel.js" followed by "reboot".
I spent several hours today taking apart and testing my coffee machine because it was acting up and refusing to make coffee.
I discovered that the control/LCD board has an unused 6-pin connector socket on it labelled with power (Vcc, Vpp, Gnd), I²C (SCLK, SDA), and Reset. The chip is made by Samsung but I can't tell exactly what it is, because it's underneath the LCD and I don't want to risk destroying it just to read the number; but that socket and especially the Vpp (programming voltage; often 12V, required to burn new data onto the chip) suggests that I could flash new firmware onto this thing, or even dump the existing firmware off it. Now I want to hack my coffee machine.
@thegibson did you know that this image is almost 2MB in size and has a cache-busting parameter on the end of the URL?
Thinking about how one would implement an addressable LED strip.
Let's start with an abstract concept. We can consider each LED to be a device with a message input and a message output. Each output is connected to the next LED's input, except the first (whose input is connected to you) and the last (which is connected to nothing).
Operation is simple. If an LED receives a message that is addressed to it, then it acts on that message. If it isn't addressed to it, it sends it to the next LED. But there's a problem. How does each LED know what its own address is? After all, if we're mass producing these, we want them to all be identical. And let's say we want to sell short segments of LED strip with the ability to solder them together into a long one. Both of these requirements mean we can't bake a hard address into the LED.
Let's say that each message is four bytes (address, red, green, blue). Let's also say that we have decided to support a maximum of 128 LEDs on one strip. Now, we take a strip of arbitrary length and attempt to set a few LEDs, sending packets like (big-endian) 0x00ffffff,0x030000ff, 0x0800ff00. Nothing happens. This because internally, each LED has initialised its 8-bit address to all ones on power-on.
Ok, what if I send 0x80ff0000? Suddenly, the whole strip turns red. And when we resend the packets from before, the correct LEDs now respond. What happened?
Each LED checks the high bit of the address byte. If it's set, it doesn't check the address against its own. Instead, it sets its own address to the one in the packet minus 127 (0x7F & packet), then increments the address byte (packet++) and sends the packet on to the next LED before setting its colour to the values in the packet.
In this way, we have come up with a "broadcast address" (128, 0x80) that can set the colour of every LED, with the side effect of also directly initialising the addresses for the whole strip!
If you were to build your own circuit instead of using a microcontroller, then assuming that all of the details of input and output (e.g. serial) are handled by another circuit on the chip, you would only need:
• Four 8-bit registers to hold the current packet (let's call them M0 thru M3, or M as a whole), directly readable/writable by your send/receive circuit.
• One internal 8-bit register to hold your current address (A)
• Three 8-bit registers to hold your current RGB value (R, G, B), readable by whatever circuit is responsible for pulse-width modulating the actual LED.
• An incoming clock line (CL) driven by the receive circuitry. After a packet is received and written to M. CL will be brought high, then brought low. After this, the receive circuitry will take what's now in M and send it onwards.
• A line (IB, for Init Bit) driven by the high bit of M1.
These logic circuits:
• IA (Increment Address): increments M1 when activated (can be implemented with only one half adder per bit, and only needs to handle the bottom 7 bits!)
• CC (Colour Copy): copies M2→R, M3→G, M4→B when activated.
• AC (Address Copy): copies (M1 & 0x7F)→A when activated.
When CL goes high:
• If M1 == A (XNOR), CC is activated.
• If IB is high, both AC and CC are activated.
When CL goes low:
• If IB is high, IA is activated.
For transmission of data I'm thinking a sensible way to do things would be to have a common clock line that's connected to all LEDs, and a data line that connects each LED's output to the next one's input. You'd constantly drive the clock line, and keep the data line low until you needed to send. Then you'd send a start bit, followed by the 32 data bits.
The serial circuit could simply be a 32-bit shift register clocked by the external clock line. When data arrives, the start bit and the following bits, all enter the shift register.
If we say that the shift register and the M registers are one and the same, it keeps things simple. But you'd have to have a shift register where at least some of the bits (M1) can be directly written to.
Eventually the start bit will exit the other end of the shift register. This output is connected to the data input of the next LED module, but is also ANDed with the clock line, giving an output I'll call SC (for Shift Clock).
You'd also have an RS latch, which is reset by the falling edge of CL (our logic's clock line), and is set by a counter 32 clock cycles later. We will call the output LI for Logic Inhibit.
LI is ANDed with SC and the output is connected to CL. The outcome is that when the start bit makes it all the way through the shift register, the next clock pulse is allowed into SC by the start bit. Since LI is high, this pulses CL, but as soon as CL goes low then so does LI, preventing CL pulsing again until the counter indicates that all of the data bits are safely out of the shift register. It then rests, in case there is another start bit right after the data bits.
You'll note that after the logic has been triggered and M1 potentially modified, then the bits (including the start bit) are feeding directly into the next shift register on the strip.
…Uh, I was just thinking about this on the way home and decided to write it all down?