UpArrow support for command history

[grymoire]

I was testing some WS2812 Neopixel strings, and I have a suggestion.
This is using BP6 and today's firmware.

I enter LED mode 10.
If I type
[0x808080:16]
I get an error because I haven't turned on the voltage with the W command. And that's good because I forgot. So I enable voltage, and press an up-arrow. This does not allow me to repeat the earlier command. I have to type [0x808080:16] again.

The same thing happens, if I want to

1. Turn off voltage
2. Connect a different WS2812 string
3. Re-enable the voltage
4. Repeat the LED command using the up arrow.

I'm testing several Neopixel strings, and having the up-arrow repeat the earlier command would be useful.

[henrygab]

There's a general need to support up arrow for command history.

Doing so should not be specific to the LED mode, so I've updated the title accordingly.

[DangerousPrototypes]

The up arrow does do command history. The issue is that after parsing a prompt the history gets blown out.

One aspect is that we use the same buffer to hold and parse any user input. This is partly for simplicity, and partly inherited from v3.x code base.

The circular buffer with history is "cute" and the way I've seen most CLIs designed, but it is also a nightmare to deal with.

I've thought a better way to deal with it on the Bus Pirate is to have a linear incoming buffer of say 512 bytes, and all user input/navigation/delete/insert stuff happens in there. On enter, that 0...511 byte array is passed to whomever needs to process it. it could be syntax or CLI command, in which case the syntax or CLI system would put the input into a circular history buffer. It could be a prompt, x for exit, press any key, in which case it would not go on the history "stack".

There has been discussion about integrating a new CLI or redesigning the current CLI. Having looked at a few CLIs, they seem very fancy with the pointers and whatnot, but I never quite see how they would fit into the Bus Pirate. It could be my own inexperience in that area though.

[grymoire]

In this case, "parsing a prompt" is turning power on and off, right?

I hesitate to suggest another approach, because it would be adding complexity. In many of the modes, you set up the mode using pull-ups and power,

You could add a quick enable/disable function that temporarily makes things safe to connect/disconnect. Like switch wiring harnesses, etc.

The Glasgow has a special switch to do a quick and safe disconnect. That's a nice feature.

I know I could program the button to do a "#" command. But that completely resets the BP, and have to I reconnect to it, enter the mode, set up the mode, voltages, speeds, etc. etc.

I could also script the button to do a "m 1" to go into HiZ mode.

[DangerousPrototypes]

A prompt is for example P for power, but then entering 3.3 and 100 for voltage and current limit. The history should still work if you use the command line only: P 3.3 100.

A safe disconnect is a good idea, and we already have most of the infrastructure because I had to adopt modes to tear down and re-enable when switching between things like the I2C sniffer and much of the IR stuff.

[grymoire]

What do you think of a safe disconnect and reconnect (retaining the same setup?)

[DangerousPrototypes]

Yes, I think is is useful and won't be too hard to add.

Any suggestions for a key or a command?

[grymoire]

Hmm. An emergency shutdown command should be easy to type. Perhaps one like an escape key in the upper left. Something that doesn't need a shift key or function key.

How about lower left? That is:

z - shut down
Z - bring back up

[DangerousPrototypes]

Sounds good, I am in the process of implementing this. It will take some cleanup of all the modes, but I am updating them as I go. Today I will do 2wire.

[henrygab]

What do you think of a safe disconnect and reconnect (retaining the same setup?)

Wouldn't w (disable power output) and W 3.3 100 (enable 3.3V power, maximum 100ma ... adjust voltage and max per your scenario) do what you are looking for?