Unconfirmed (using that site’s labeling): Cyrillic (Russia), Japan, Myanmar, Korea, Thailand, Arabic, Hebrew, Urdu, … but even these appear to have QWERTY fallbacks?
Even the rare Turkish F-Keyboard
z has low likelihood as the first character of future commands, so is correspondingly unlikely to conflict with mode-specific commands.
Ian … can you share your thoughts on enabling the above as a separate global command?
We should also consider @tayken 's suggestion for a command to temporarily put the current mode into safe mode (HiZ) with a command to restore it. Maybe that could be the same?
I am unclear if there’s generic support for “restoring” a current mode. I’d need to better understand the expectations there, the intended use cases, and compare those to existing options users have. That said, my plate is full, so at most I could offer advice / thoughts on such a “restoring” feature.
Thanks for confirming that you support z (and uppercase Z) for the immediate move to safe-mode (HiZ)!
There were times when I was connecting several similar devices one at a time for testing purposes. It might be dumping RAM, or testing I2C devices. I sent up one devices, specifying power, mode, pins held high, pulse width, whatever.
When I switched from one device to the other, I want to disconnect one and connect a second. I don’t want power on while I do this.
If I type “#” to turn off everything, it resets everything, and I have to retype all the commands.
I had requested a way to “disengage” the BP, switch the Device Under Test, and re-engage the BP and repeat the test with as few keystrokes as possible.
So, in this case something like “profiles” for each mode would be useful, and when you switch to a mode you could just pick one of them (it could simply be a Bus Pirate script) and that’s it, right?
The buffers power down when they don’t have a voltage on either half. So if you w to turn off the power supply, the buffers are in partial power down mode and should be off. When you W it will come back on. We have a 10k resistor to ground to make sure the buffers are in partial power down mode if the ppsu isn’t active.
Ok, I think I understand your use case here. It does sound like this is something that a script would handle well.
The edge case that requires a bit more work is when first tinkering, and not sure what settings to be used. In this case, a user is cycling through options. Then again, after one DUT works, it would seem you’d want to verify those settings at least once. A terminal’s scrollback buffer should provide the command history, allowing you to select the ones to keep.
Are there other scenarios where scripting doesn’t work?
Also, for I2C (which I played with a bunch recently), it’s possible to stay in the I2C mode, and simply use w to disable power, swap out what’s connected, and the use W 3.3 100 (for example) to restore power. I definitely used the terminal’s scrollback buffer. And (so long as I didn’t cause a prompt, such as by typing W instead of W 3.3 100, the command history within the buspirate worked well also.
Thank you for that I2C tip! As a bilingual (Linux/Windows) computer user, I’m intimately familiar with terminal scroll back, whether in Bash or PowerShell; it’s a trusty friend with a perfect memory.