I love my Buspirate v3 and have been hungering to upgrade. I realize v5’s design is probably set in stone by now, but for v6, a minor design enhancement suggestion:
Rearranging Bus Pirate enclosure’s embedded RGB/LED lights into a straight line(vs. current “cupcake sprinkles” layout):
Not only would this look more aesthetically appealing, a straight line of LEDs could also double as a general measurement indicator (custom assignable!).
Obviously the limited number of LEDs wouldn’t provide a lot of precision, but could still be useful as a general visual measurement, especially in the user’s peripheral or when distanced, like when both hands and are handling leads while interacting with the component.
Examples of measurements to visualize:
Data fluctuations during capture,
General voltage/amperage indicator
Timer/countdown indicator
Buffer amount remaining
Triggers
Etc.
Likewise, the color of (multicolor) LEDs could further convey information, e.g. shifting of blue/green to reds, Green(Ready/Go) | Yellow(Capturing) | Red(Error/Buffer filled/voltage threshold), etc.
Rectangular LEDs would also look super clean, reminiscent of old-school audio meters.
I imagine you’re right about the design (since it also seems likely to affect the case). FYI, I’ve made some improvements to the pixels support in the firmware. I’m very interested in creating APIs that:
give fully control of the pixels (except for a brightness limiter due to current constraints)
give simple usage for common scenarios
Obviously these are different APIs.
I think 18 RGB pixels is a significant number… I think you will be surprised what folks come up with. For example, I can imagine simple APIs for…
Top/Lower half-circle “fuel gauge”
One full-circle clock (e.g., timer/countdown … could even have distinct colors for minutes vs. seconds)
Top/Lower edge low-fidelity bar graph; Only 5x pixels, but with blending of colors and light levels, it can seems like more (e.g., buffer remaining)
Since the API would need to be called for all updates (except, perhaps, the timer), all that’s needed is someone with an eye for beauty to help define the animations to be applied.
P.S. - If I had a wishlist item, it would be to have all the pixels facing the same way … either up next to the screeen or sideways … the mix of the two makes light-level matching complex (manual process finding relatively close levels at the moment).
There might be just enough room to swap the side facing LEDs for through hole on the top and bottom, but it’s gonna be tight on the USB side. On the 10P side it’s not possible because of the connector. It might even be possible to keep the side facing LEDs, but push them further towards the PCB center.
The LEDs are used to do indication a couple places so far. The logic analyzer does armed/capture/dump changes.
The Rectangular LEDs is a cool idea. I haven’t seen anything in that profile to be mounted backwards through the PCB though. If we moved to 2 sided board placements, we could cover the top in tiny 1010s. That would also need an enclosure update.
First, reliable CPU-based board revision detection is a critical prerequisite to anything below, if only to keep some sanity in the animation logic. With the RP2350, the board revisions could be stored in an OTP page. But with the BP5, would there be a way to detect this from the CPU? (e.g., can the NAND be configured with a read-only section)?
Secondly, there are two goals worth mentioning:
(1) keep the case the same
(2) all-or-nothing on pixel change … adjusting only most of the pixels to be the same direction would likely not make things better.
Through-hole would be problematic as you noted. However, having all the pixels be side-facing would be an improvement for various reasons. It looks like they are the same (or smaller) footprint, no significant trace changes, and a quick look suggests the exiting case would still work. The existing side-facing pixels get a nice diffusion effect with the current case. If the current through-board pixels are re-done to be side-facing, it should allow for much smoother blending effects (especially with the diffusion of the case).
Besides, having pixels which shine directly in the same direction as the screen … it’s “cool”, but any significant pixel light output from those pixels just makes it harder to read the screen. In contrast, the side-firing pixels don’t cause that problem.
When you next make a test board revision, would you consider swapping all the pixels to be side-facing. I think you may find it effective, and maybe there’ll be other slight tweaks worth looking at. (e.g., corner pairs at 30/60 degrees for more “rounded” effect at corners?)
