Documentation update

Imagine I end up writing a Python script to automate all the demos, and pause on prompt.should be doable.

2 Likes

If you can both detect the prompt and detect the first line feed / carriage return after the prompt, then…

I’d recommend the pause be after the command is fully entered, rather than when the prompt appears, but before the command is executed.

After all, the point is to let folks pause the playback, and then copy/paste the screen into their own terminal. At least, that’s what I would do. :slight_smile:

2 Likes

A project has emerged lol.

A Python script to:
Run automated demo scripts
Capture the vt100 output
Save to ansciienma format, run the optimizing scripts
Crop sections into individual demo files to include in the docs and convert to HTML

This puts some fun back in the drudgery I’m currently experiencing with the docs update. Turn the copy past into a programming exercise :slight_smile: In the future the scripts can be updated and batch run to update all docs on the latest firmware. Sweet!

5 Likes
[0, "o", "l"]
[0.000694, "o", "s\r\n"]
[0.002905, "o", "\u001b"]
[0.003031, "o", "[3"]
[0.003083, "o", "8"]
[0.003145, "o", ";2;150;203;89m   <DIR>   \u001b[38;2;191;"]

Capturing VT100 to asciinema format :slight_smile: It works in the player but looks like trash.

demo.zip (2.2 KB)

python autodoc.py -p COM34 -i demo.txt -f output.json -d

Detecting the various prompts proved to be a nightmare, sooooo… I added \x03 END OF TEXT (ETX) character to every prompt in the firmware. This is a non-printing character that shouldn’t mess with terminals, but it gives the automated docs/testing a way to spot the next prompt without “guessing”. It works great! (so far)

I also somehow coaxed Chad into converting the ansi2html script from JS to python, and it actually seems to work after a bit of adjustment.

Urgent things to do:

  • “Typing speed”
  • Pause at prompt and after “typing”

TODO:

  • Control mechanisms in the command scripts that indicate where to chop things into asciinema screencasts & file name, and where to chop the HTML output into include files for the docs & file name.
  • Update docs to include the output of the above files

This seems like it could be really slick! Automated docs updates and down the path to automated testing (diff current output vs previous, highlight changes in a report).

3 Likes

demo.zip (4.5 KB)

Updates:

  • Cooperative multitasking loop captures serial in while slow typing serial out
  • Random small delay between characters to simulate typing
  • Recognize and reply to VT100 screen size query (status bar works now)

Still needs delay before enter and after prompt appears again.

Sorry for giving you extra side project. But looks like you enjoy it a byte.

1 Like

Now we’re cooking!

Latest demo. One uses autodocs, the other is manual. Can you tell which? I think it looks pretty great, and is much better than me sweating my way through the screencast without making any mistakes.

Autodocs is now in the tools folder of the bp-docs-hugo repo.

  • Cleaned up the mess into a pseudo state machine
  • Better handling of VT100 detection
  • Comments in the input script are inserted as makers in the screencast
  • Pause before enter and after prompt
  • Natural typing rate
W # W - enable PSU (interactive)
5
100
W 5 100 # W 5 100 - enable PSU (command line options)
W 5 # W 5 - enable PSU (default current limit)
w # w - disable PSU

This is the script for the screencast. The command to send is first. Comments after # are then inserted as markers automatically. This will save so so so much work now and for future updates.

TODO:

  • Script control of what is recorded and where it is saved
  • Alternate mode to record the stationary text examples to be included in the existing console widgets

@AreYouLoco - I’m actually pretty thankful. The docs need help, but going through it all manually is a freaking nightmare and SO boring. This makes it a fun project and automates updates in the future.

y
m hiz
m led
y
# sc_power_supply.json
W # W - enable PSU (interactive)
5
100
W 5 100 # W 5 100 - enable PSU (command line options)
W 5 # W 5 - enable PSU (default current limit)
w # w - disable PSU
# stop

The final piece for asciinema - control of when recording starts and stops.

# sc_power_supply.json

Blank command with file name in comment begins recording. If a file is already recording it is closed.

# stop

Blank command with stop in comment closes current recording file.

Hum. The demo script should probably be unified with the formatting of Bus Pirate scripts and tutorials. Comments above commands.

1 Like

Most of the tutorials-basic now have a screencast. Had an issue with self test aborting at the button press, but the others look ok.

Not sure where exactly to put the screencast. Currently at top, but I think it should go either in a second item after intro, or at the very end.

demo.txt (1.3 KB)

I love it! Easy to use, automate all the markers, space to setup for the next recording without cropping and editing. Wow, very please.

Next I’ll look at @henrygab 's list of suggested uses and update the docs :slight_smile:

2 Likes

A second much simpler script to create output snippets for the docs. There is something weird going on with new line and reset line, seem to get multiples out the VT100 stream that shouldn’t be there.

I’m probably going to need to add some basic vt100 parsing. Just nuking all the 0x0ds seems risky.

With some questionable post processing, simple output looks fine.

I’ve asked over at the asciinema forum if the player could export the HTML for a frame.

2 Likes

This weekend I updated the docs for writing docs and capturing terminal output with the new python scripts.

Today is a holiday, but tomorrow I’ll begin converting the docs to the new automated system. If anyone would like to help, you can pick a device demo or quick start tutorial and give it a try.

Currently there is a main command reference page and then a page for each protocol. I’d like to consolidate this somewhat. Probably not eliminating protocol specific pages, but at least adding a description of each protocol command (think flash, sniff, scan, etc) in a section of the main command reference. This makes it easier to print (to pdf, etc) and ctrl+f search. The inspiration for this is Raspberry Pi’s own rp2040/2350 docs.

3 Likes