I can. Say you want to display one 'frame', that is, one run where you display all the pixels where the pixels on average have the intensity you want them to have. Because you can only turn the pixels off and on, you need to send a certain amount of 'subframes'.
PWM works as such: you send 256 subframes at the same time interval, and if you want a pixel to be 50% dimmed, you turn it on in half of the subframes and off in the other half. When you want it at 1/255 brightness, you turn it on in only one of the 255 subframes.
BCM/BAM works as such: you send only 8 subframes, but each subframe has a specified time when they are visible: each following subframe stays on for twice as long as the previous one. For example, subframe 0 is visible for 1 ms, subframe 1 is visible for 2 ms, subframe 2 is visible for 4 ms, subframe 3 is visible for 8 ms, etc. Now, by turning on the pixels in some subframes, you can exactly specify how long they are on in the total frame: say you want to have your pixel at a dimness of 200, you'd turn it on in subframe 3, 6 and 7.
As to CPU use: because you only need to calculate and send 8 subframes instead of 256, everything takes up less CPU. Especially during the longer subframes, the CPU can context switch out and go do something more useful while waiting.
PWM has more capacitive-switching energy cost (in wires and it gate cap), and crowbar current. But I'm curious how much of the total energy is due to these transients, because LEDs burn a ton of power. Is crowbar/capswitching 50% 90% 1%?
Now the hardware to compute the binary signal is the same as the PWM because you still need to subdivide the clock and count to know how many phases have passed to pulse at 1, 2, 4, 8ms, etc. This is typically done with dedicated hardware (the Atmega has a fairly unsophistcated PWM compared to TI, ADI or STM). Ideally you want the PWM to use the IO fabric to DMA the data, and not have the CPU twiddle GPIOs, that's a sledgehammer approach.
Also, the PWM rate is not fixed, it does not have to be 256 pulses. Depending on the hardware it can go from Hz to MHz (it impacts responsiveness). But that is a function of the MCU, and Atmega has fairly coarse adjustment for the PWM modes.
Ironically, the point of PWM is to actually save power.
Running the bus for a large array definitely takes a lot of power, but I agree it wouldn't be huge compared to the LEDs themselves.
> Now the hardware to compute the binary signal is the same as the PWM because you still need to subdivide the clock and count to know how many phases have passed to pulse at 1, 2, 4, 8ms, etc. This is typically done with dedicated hardware (the Atmega has a fairly unsophistcated PWM compared to TI, ADI or STM). Ideally you want the PWM to use the IO fabric to DMA the data, and not have the CPU twiddle GPIOs, that's a sledgehammer approach.
BCM isn't used when hardware PWM is an option. It's used for displays driven by long long chains of shift registers where you have to reload a whole frame to change an LED's state. Your DMA is sending data to a hardware SPI transmitter, not a PWM block in this case. There are ICs designed for _very_ large, high-end LED arrays that have hardware PWM for each LED, but they're less common and much more expensive.
You also don't really need to 'compute' BCM. You generate a bit-sync pulse or interrupt or whatever that runs once for each bit. At that point you just grab the pixel from the frame buffer, mask the correct bit, and output it to the array. The advantage over PWM is this bit-sync only runs 8 times (or whatever the bit depth) instead of 256. The shortest time between syncs is still the same length of the equivalent PWM signal, but the length between them grows but double each time (up until the start of the next period).
> Also, the PWM rate is not fixed, it does not have to be 256 pulses. Depending on the hardware it can go from Hz to MHz (it impacts responsiveness). But that is a function of the MCU, and Atmega has fairly coarse adjustment for the PWM modes.
256 is the number of grayscale colours (2^bit depth), not the pulse rate. Just like PWM, BCM can run at any rate or any bit depth.
You're really hung up on microcontroller PWMs. They're certainly helpful, and you certainly can use them to drive LEDs, but they top out at anywhere between 2 and 24 channels, so they aren't cost-effective for large, dense arrays. These LED drivers are really just shift registers, so they're dead simple and very, very cheap.
The only difference in power consumption is in the reduced toggling of the IO pins and the reduced effort of the CPU (but that's assuming the CPU will downclock or downvolt automatically, which is unlikely for a microcontroller.)
In an LED panel, the vast majority of power consumption is in lighting up the LEDs.
Yes, for an intensity that is not a power-2 fraction of fully-on, but all the additional flickering is at frequencies that are harmonics of the fundamental frame rate. If the fundamental is high enough that you do not notice the flickering, you will not notice the additional components.
