The latest firmware has an improved button command thanks to @HEDoRAH!
Different scripts can be assigned to short and long button presses.
There is a known bug in the button command (before this update as well): pressing the up arrow after a button press with send the Bus Pirate into an infinite loop. Iāll get that worked out soon.
The latest Bus Pirate firmware supports 1Gbit NAND (default) and 2Gbit NAND (upgraded) flash chips thanks to @henrygab.
There may still be test boards with the 2Gbit NAND, or you can get a chip and upgrade your own. Be really careful not to damage the LCD when removing the old chip with hot air.
Iām not sure when/if/how this goes into production hardware yet, but please share a photo if you upgrade your own!
Some changes from other branches are trickling in to main:
Binmode branch cleanup and merged into main for further development
@phdussud logic analyzer updates to SUMP and edge triggers on test branch have been integrated into the new binmode system.
A very very quick port of a CH32V003 swio programmer/debugger from CH32 FUN has been added to binmode. Should work once the timings are fixed, but I donāt have a test bench for it.
There is a new binmode command to select the active binmode (binary mode) interface. Now we can add as many binary mode interfaces as we like. SUMP logic analyzer is the default
Some handling for locking the terminal when binmode is active, needs a bit more work.
Setup and cleanup functions for switching binmodes
A new build server is running, and I completely reworked the automated build script. The latest auto builds use the Pico SDK 2.0, and include firmware for Bus Pirate 5 (rev8 & rev10), 5XL, and 6.
The python build script is clean enough I posted it in the forum, along with updated build server install instructions.
A new image command probes bitmap image headers, and can write (correctly sized, 16bit or 24bit) BMPs to the display.
There is a new image processing Python script to dump images to c .header files for use in the firmware. This pre-formats data to significantly speed the screen draw time (and therefore the startup time) of the Bus Pirate.
Iām sure Iām leaving a bunch of stuff out, itās been a lot. Thank you so much to all the contributors!
Some binmodes can now be saved as the default to load at startup. There is a catch though - only binmodes that 1. Donāt lock the terminal and 2. have been verified to not output text during startup (causes serial port crash) can be saved as the default. Currently this is:
SUMP logic analyzer
FALA
Other modes will not currently see the option to save as default until they have been updated.
Do I have this scenario correct? If I have a BP6, I can enable the FALA on bootup, and then just use the BP as a normal BP5, and when there is something I need to understand, I just start up pulseview, and redo the test, and voila! - I see the logic analyzer display.
And as long as I donāt change the binmode, Iām all set, I can do this?
And thereās no downside? There has to be a downside.
You are indeed correct You can also now save that setting so it always boots in FALA mode.
Whats more: it works with BP5 and BP6. The difference being that the BP6 has that extra āreach aroundā buffer that sees whatās actually happening on the bus. BP5 is starting at the back of the buffer ICs and may not reflect the true state of the bus when there is a problem(especially in open drain busses like I2C).
Not exactly the project I had in mind, but I completely reworked the syntax compile/run/post process code to try and squeeze a little more performance out of it. All the big switch statements were turned into arrays of functions.
Iām not sure that goal was accomplished, but the code is much more readable /maintainable/debuggable now.
As with any major change there will probably be a few bugs. Please let me know if you have any issues.
Other updates:
LED mode forces system number of bits to 32 so the full frame is displayed by default
LED mode for APA102 (2wire) has a small enhancement. Data frames for APA102 start with 0b111xxxxx, where x is the global brightness setting. If the first 3 bits are not 1, the Bus Pirate will set the first 8 bits to 1 (0b111, with full global brightness). The change will be displayed in the terminal so it isnāt hidden.
If the data starts with 0b111, the bus pirate will assume the user provided global brightness is correct and not make any changes.
I submitted an issue to add this to the documentation.
Thanks for going the extra step, reviewing even my BUGBUG notes in recent PRs, and doing the work to create a proper fix. Iāve been without mains power for almost a week, so I apologize for where I wasnāt responsive.
Being able to set the global brightness on APA102 / SK9822 can make a big improvement for accurate color reproduction. Itās great to see the ability to verify this setting on real strands. Thanks, Ian!
I may back off on this a bit, and make it an option. I was debugging and I wanted to generate my own start frame (0x00000000) and it overrode me, which was annoying.
On the other hand, if you want raw SPI there is already a mode for that.
Iām surprised some eye candy for LED mode hasnāt appeared yet
Can you let me know if the pixel reservation / release API and method to temporarily disable background animation looks OK? Those are the first stepsā¦
// NOTE: the names here are intended to be descriptive,
// not necessarily how they'd end up...
typedef uint32_t pixelmask;
// Prevent or allow the background task to update
// the pixel animation (from the configuration file).
// This is a dynamic disable, irrespective of configuration,
// and does NOT persist across reboots.
// RAM cost: 1 byte (bool)
// RAM cost: 1 bit (if combined with other bools)
bool get_background_pixel_animation_disabled();
void set_background_pixel_animation_disabled(bool disable);
// For UI, pixels should be reserved prior to use,
// and released when they are no longer needed.
// This allows multiple simultaneous UI elements,
// so long as they don't overlap.
// RAM Cost: 4*PixelCount bytes to store tags
pixelmask get_pixels_available_for_exclusive_use();
bool reserve_pixels_for_exclusive_use(pixelmask pixels_to_reserve, uint32_t tag);
bool release_pixels_from_exclusive_use(pixelmask pixels_to_release, uint32_t tag);
// false if any of the pixels in the mask are not reserved.
// false if any of the pixels in the mask not reserved by tag
// else sets the color for those pixels and returns true
bool set_pixels(pixelmask mask, RGB color, uint32_t tag);
Should the API auto-balance the brightness of the top-facing vs. side-facing pixels?
Helper functions for common UI?
Full-circle progress bar? (filled or point progress)
Two half-circle progress-bars (filled or point, top or bottom pixels)
Two single-edge progress bars (filled or point, top or bottom pixels only ā¦ not using edges with USB / plank)
Other?
"Fun" patterns
Until the brightness balance for the different pixel directions is sorted, it can be difficult to get best-looking results, even for the simple progress indicators. This is one reason I pushed for at least considering changing all the pixels to be side-firing (or top-firing ā¦ either way ā¦ just consistent).
I may just need to manually generate a mapping, but I donāt have tools to do this correctly, so would just be approximating based on my own visual prejudices. Maybe good enoughā¦ but definitely time-consuming.
Iām not sure itās worth backing off for that ā¦ your own start frame wasnāt aligned with the mode you were using. As you yourself mentioned ā¦ may as well use the raw SPI in that case?
Major nasty issue fixed in new syntax compiler when using repeats :
Converting to universal inlined PIO idle detect function begun
Implementing a universal voltage/pull-up check in each mode. This is currently attached to [ and { (generally the beginning of syntax), There is a new mode function to sanity check that is run at the beginning of each syntax operation. (complete) This will keep it from running multiple times, and ensure it always runs at the beginning of the syntax operation.
FALA validation on I2C continues
Discussion point: Should a sanity check error (no power or no pullups) halt the execution of syntax? I think no, because sometimes (eg I2C) the pull-up is stuck low because of a failed previous operation (or an un-NACKād read operation). In that case one may need to execute [] to reset the bus.
You can also now save that setting so it always boots in FALA mode.
Thanks, Ian!