Skip to main content
Topic: ProcMenu.c changes (Read 17646 times) previous topic - next topic

ProcMenu.c changes

One of the things that slightly annoyed me about the Bus Pirate was that normal line editing commands other than backspace were not implemented in the terminal.  I make a fair number of typing mistakes, probably more than the average person, and so wanted a little more advanced editing capability. 

I made several changes to the ProcMenu.c code to add:



    [left arrow]         ^B          Moves the cursor left one character


[right arrow]^FMoves the cursor right one character


^AMoves the cursor to the beginning of the line


^EMoves the cursor to the end of the line


[backspace]^HErases the character to the left of the cursor and moves the cursor left one character


[delete]^DErases the character under (or to the right of) the cursor and moves the cursor left one character



I also added the ability to insert text into the middle of a line because otherwise left and right arrows aren't that useful.  If you are not at the end of the line and you type a printable character it will insert the character at the current cursor position and shift the rest of the line to the right.  Likewise, if you are not at the end of the line and you use backspace or delete the appropriate character will be erased and the rest of the line will shift to the left. 

I had to cheat and use a couple goto's to get it all to fit with the bootloader -- it is that tight.   I made these changes for my own use but if we can get them to fit it would be nice to include them (or a subset)  in the next release.  I have a few other changes I want to implement using the up and down arrows to cycle through the command history.  I don't need/want the bootloader on my Bus Pirate so I am not concerned if the command history changes are too big but I will try to get them to fit and also try to clean up the code to see if I can make some extra room (and get rid of the goto's).

Please give this a try and let me know if you find any bugs or if it broke anything else.  Also let me know if it does not give the expected behavior.  I tried to copy the way I think most terminal and command line editing works but I may be off on something.


-Eric

Re: ProcMenu.c changes

Reply #1
Good addition! I know it is on Ian's list for quiet a while. Will integrate it into v5.9.

Space is indeed a scarce :( Since the rewrite (newterm) we are struggling to get it fit. If you don't care about the lcd and keyb you can select BP_FW1 instead BP_MAIN in base.h. This will give some extra room. We are working on a new hardware version with more memory.

Re: ProcMenu.c changes

Reply #2
Great features, thanks! I'll take a look at the source on Monday. We can get a small amount extra space by merging the PWM functions I think.

Quote
using the up and down arrows to cycle through the command history.

This is probably the single longest standing to-do :) I've attempted it a few times, but quite because it's terminal emulation specific (not that we can't just choose one to live with).

For the arrow commands - which emulation did you use?
Got a question? Please ask in the forum for the fastest answers.

Re: ProcMenu.c changes

Reply #3
[quote author="ian"]
For the arrow commands - which emulation did you use?
[/quote]

VT-100 (ANSI C0)

ANSI Escape sequences - VT100 / VT52
VT100 User Guide - Chapter 3 Programmer Information
ANSI Escape Codes - Wikipedia
C0 and C1 control codes - Wikipedia

I assumed this was the most common terminal emulation that nearly all programs will use or support.


[quote author="ian"]
[quote author="Eric"]
using the up and down arrows to cycle through the command history.[/quote]

This is probably the single longest standing to-do :) I've attempted it a few times, but quite because it's terminal emulation specific (not that we can't just choose one to live with).[/quote]

Yes it will have to depend on the user's terminal understanding basic VT-100/ANSI escape sequences.  I'm not using any very advanced control codes, just basic cursor movement commands that I think all VT-100/ANSI terminal emulators should implement.  For the history buffer I will need to use a line blanking command as well but still nothing too advanced.

I started writing the history buffer code but it is getting ugly because of some special cases.  Such as, if the user presses the up arrow before typing anything.  Searching through the command buffer for previous entries is easy but what happens when they try to press the down arrow to come back to the blank line they were on.  So I have to check if they are on an empty line and if so add a marker to find that blank line where they started and then deal with the marker later if they decide to come back to it and start typing.

There are also no grantees that the way I implement it will be the simplest, shortest, most compact and straightforward.  I'm not really a software guy.  So if you have any suggestions or comments let me know.

-Eric

Re: ProcMenu.c changes

Reply #4
Ian,

Would you mind, or would I be stepping on someone else's toes, if I cleaned up and reformatted all the code in ProcMenu.c?  If there is a Dangerous Prototypes codding standard or style guide I can follow that otherwise I will just try to keep it consistent throughout the file.

-Eric

Re: ProcMenu.c changes

Reply #5
There is no real dangerous protype coding style :D In fact multiple styles are present in the source code since it is written by lots of people. I prefer to leave the style as-is unless I change something big in a sub.

Re: ProcMenu.c changes

Reply #6
I have added the history buffer scrolling with the up and down arrow keys to ProcMenu.c and attached the updated version. 

Each press of the up arrow will search back through the command buffer and copy the next older command to the current position in the command buffer.  When you reach the top of the command buffer (wrap around till the end of the current command) any additional presses of the up arrow will only ring the terminal bell.  Each press of the down arrow key will search back through the command buffer and and copy the next newer command to the current position in the command buffer.  When you reach the the newest command in the command buffer the next press of the down arrow will result in a blank command line and any additional presses of the down arrow will only ring the terminal bell.  

Even if I removed all the code associated with the old 'h'-history command these new additions would not fit with the boot loader so I left all the old command code in for now.  Someone in charge of the code will have to decide how to proceed, what to keep and what to discard.

Anyone who can, please test this and let me know if you find any bugs, unexpected behavior or if it broke something else.  If you want to test this and keep the boot loader you will need to disable a protocol or two.  If you don't mid losing the boot loader and have a PIC programmer then just change the line 20 of the p24FJ64GA002.gld file in the project directory from LENGTH = 0xA5FE to LENGTH = 0xA9FC.

I'm an EE who tends to think in terms of hardware and assembly language so my software algorithm design is surely non-optimal.  If anyone has any improvements please let me know.


-Eric

Re: ProcMenu.c changes

Reply #7
Sweet updates! Here's a compile that works with the bootloader. I removed the PC keyboard library (should go in the secondary firmware now I guess).

Can you please confirm that it's ok to release your code in to the public domain? I'll check in the update to SVN.
Got a question? Please ask in the forum for the fastest answers.

Re: ProcMenu.c changes

Reply #8
[quote author="ian"]
Can you please confirm that it's ok to release your code in to the public domain? I'll check in the update to SVN.
[/quote]

Yes, of course do what ever you want with it. 

Also note that in trying to get the code size down I changed some expressions to more compiler efficient ones. 

One of note is the flowing sequence:

var++;  /* or var--; or var += 2; etc. */
var &= MASK;

If this is rewritten as:

var = ( var + 1 ) & MASK;

It will be two instruction words shorter when compiled (at least with this compiler).

This expression is used often in the ProcMenu.c code for the circular buffer so changing all of them saved quite a few words of memory.  Not quite enough to get it all to fit but every little bit helps.  I don't know how often this expression is used elsewhere but changing it everywhere might help some.  I try to write the most compiler efficient code when I know to.  There are probably other expressions in the code that could be optimized like this as well.


-Eric

Re: ProcMenu.c changes

Reply #9
Thanks. I committed the changes. I also searched through the code for any &=mask and updated it. There were a few, but not enough to fit the keyboard mode back in :)

Do you plan to play with the code any more? I'd be happy to give you SVN access so you can submit stuff on your own.
Got a question? Please ask in the forum for the fastest answers.

Re: ProcMenu.c changes

Reply #10
I'm loving these changes!
Got a question? Please ask in the forum for the fastest answers.

Re: ProcMenu.c changes

Reply #11
I'm using tera term set to vt100 emulation, and some of the less-common commands don't work.

up/down/left/right work.

delete looks like this:

DIO> 0b0005~010
again:
DIO> 0b0005~~010

The code sent is 1b 5b 34 7e

End and home (^E ^A?) do the same thing (codes: 1b 5b 35 7e, 1b 5b 32 7e)

I tried several different vt-10x types, but it didn;t seem to make a difference.
Got a question? Please ask in the forum for the fastest answers.

Re: ProcMenu.c changes

Reply #12
Sorry, looking into it more I guess tera term is using non-standard codes. ctrl+A/E seem to work fine.
Got a question? Please ask in the forum for the fastest answers.

Re: ProcMenu.c changes

Reply #13
[quote author="ian"]
Thanks. I committed the changes. [/quote]

Do you want me to update the Bus Pirate user interface Wiki page now or wait till you release the next firmware with these changes?

[quote author="ian"]
I also searched through the code for any &=mask and updated it. There were a few, but not enough to fit the keyboard mode back in :)
[/quote]

Every little bit helps.  There are probably many other expressions and routines that could be hand optimized like this as well.  I'm not that good of a C programmer to know them all though.

[quote author="ian"]
Do you plan to play with the code any more?
[/quote]

There is nothing else I can think of that the terminal really needs, can you?  If space was not an issue I might add ^K and ^U but I do not use these near as much.  Now that I am thinking about it, I forgot to add the mappings for ^P and ^N -- I only did the up and down arrows.

There are a few other things I would like to do if I ever get to them but who knows when that will be. 

One of them is updating the keyboard protocol to be able to act as a passive bus sniffer and possibly injector.  I have an old HP workstation that only seems to work correctly with a PS/2 keyboard and mouse connected directly to the unit but will not work with my PS/2 KVM for some reason.  I would like to be able to monitor the bus and see what traffic is going each direction.  The best write up on the PS/2 protocol I have found is here.  Based on how I read this I should be able to tell which direction the traffic is going based on the start conditions.

This would not fit on the current Bus Pirate hardware but, I would also like to build a version with a parallel output bus that I can connect to my logic analyzer.  Logic analyzers (especially older ones) are great with parallel data but are limited in their ability to process serial data.  I would like to have a Bus Pirate with all the sniffer modes, that can be setup and configured via a terminal interface but, which spits all the data out over a parallel bus.  In addition to data I might add a few other lines for ACK/NACK, error flags, etc.  This could probably be implemented on the current Open Logic Sniffer hardware but I haven't even looked at the FPGA code yet.  I had a brief intro to Xilinx FPGAs more than ten years ago but have not looked at VHDL since then.

[quote author="ian"]
I'd be happy to give you SVN access so you can submit stuff on your own.
[/quote]

Maybe later but not yet.  Right now I'd rather have someone else review anything I write before it gets committed. (then it's not my fault if it breaks something:)

[quote author="ian"]
I'm loving these changes!
[/quote]

Thanks, I'm glad you find them useful.

[quote author="ian"]
Sorry, looking into it more I guess tera term is using non-standard codes. ctrl+A/E seem to work fine.
[/quote]

Let me know what you find out.  I have not tested this with different terminal programs.  The delete function expects 0x7F, it is possible your terminal is mapping it to something else.  As long as they do not conflict we can add a couple alternate key mappings.


-Eric

Re: ProcMenu.c changes

Reply #14
Please update the wiki, that would be great.
Got a question? Please ask in the forum for the fastest answers.