Bus Pirate nightly version 2.7

v27

There’s some major internal changes in the latest nightly firmware. The binary mode features are implemented and nearly complete. Several bug fixes and a new macro went into the UART library.

Your help testing this new firmware prior to a final release is greatly appreciated. Please leave a comment if you find bugs, or if you can verify that various protocols and features are working. Download the latest v2.7 nightly, update instructions here (Python updates).

More below the fold.

Major changes

  • Global command structure
  • UART error and overrun handling, new macro
  • Binary mode function changes

Global command structure

This is a long awaited change. All protocol libraries now retrieve commands, values, and repeat values from a central memory location. This memory is defined by a struct in base.h. Future variable additions or changes can be done in a single fine and won’t require updates to every protocol library individually.

This is a major change, there are bound to be a few bugs.

Binary mode function changes

Binary mode handling functions have been integrated into the existing protocol libraries. This eliminates a ton of code we duplicated for custom versions during development. We’ve tested the binmode, SPI EEPROM dumper, and self-test scripts without problems, but there are bound to be some more consequences from this change.

v2.7 also includes an untested binary UART mode.

UART error and overrun handling in terminal mode

See the UART mode updates.

Tags:

  1. When setting options in raw mode and switching to raw I2C the settings are cleared, for example, turning on the power supplies in raw mode and switching to raw I2C mode switches them off again, is this deliberate?

    Reply

  2. Yes, like the user mode everything is reset to input/off on a mode change.

    Reply

  3. on my v2go v2.7 broke ZTerm again, can see activity LED on buspirate flashing but nothing happening in terminal window. using ’screen’ from a command line works fine so I know the v2.7 flash took. seems pretty similar to the v2.5 bug I reported.

    Reply

  4. Thanks for the report. That’s a strange bug because nothing changed there, I’ll take a look at it again though.

    Reply

  5. @ninja – Does your MODE LED light when it’s unresponsive with Zterm? The new firmware lights the MODE LED in binmode, so if it accidentally entered then the LED will be on, otherwise it’s a different issue.

    Reply

  6. @ninja – I made a change to the latest nightly that I hope helps. Could you please try that and let me know if it works for you? It looks like ZTerm is the major MAC terminal, so I’d like to get this bug fixed permanently.

    Reply

    1. Only nightly v25-2.7 I see is the last one I tried from yesterday but did notice the new 2.8-nightly so tried that instead, and as you suspected the MODE LED lights up. So I did a little more poking around in ZTerm and it looks like my problem was a bit more than the binary-mode null-chars, from what I could tell ZTerm was sending the buspirate immediately into binary mode due to an initialization string (‘ATE1 V1^M’) in the default “local” settings profile which I never use and instead switch to a custom “Bus Pirate” settings once it’s launched.

      So it seems like it’s related to that because as soon as I set the init string to nothing the MODE LED wasn’t lighting at launch and when I switched to my usual Bus Pirate settings everything is working fine again!

      And yeah, ZTerm is ooooold school Mac terminal – was using it over 20 years ago to dial into BBSs on a Mac+, still using it today. Aside from updating to run in OSX it still looks the same, feels the same, everythings the same – consistency no modern software can match 8)

      Reply

      1. That looks like a modem initialization string. Does that mean the issue is fixed by removing it? I’ll release a new version if this issues is cleared.

  7. consider it cleared!

    Reply