Broken link report. This does not include links between the old hardware.bp.com and firmware.bp.com, which also need to be updated.
Alright, I’ll take care of fixing all the internal links—I’ll go through everything manually and carefully.
Just ping me in the chat when I can start.
(I’ve got the PLANK SNIFF project on hold for now, but I can definitely do this without a problem!)
I am going to make a PR with fixes I reported on the chat. Also would like to know when to start so there are no merge conflicts and its one click merge
@Dreg @AreYouLoco Thank you both! Appreciate anything you have time to do.
My latest is pushed. That’s the final major update.
Found the issue with the previous and next page links being wild. It’s a doozy!
- The left side menu sorts the top level items by their weight assigned in the front matter, then the content of each folder by it’s weight. This is expected behavior of docusaurus as well.
- The Previous and Next buttons however are just all the page weights sorted, with no regard for the hierarchy of sub folders. This means to move a “group” or folder of items, each sub item has to be assigned a new weight as well or the next previous might go to a different section. This is gonna be SUPER annoying.
I reweighted each page in a way so that it sticks how I want, but this is defo worth putting in a bug report for. Long term this is gonna be nuts and at minimum we’ll need a python script to help move sections when needed.
Resuming the docs update.
It occurs to me that it might be nice to have a docs
or log
command that captures the terminal IO to a file on the NAND flash, excluding any toolbar output.
Currently I log with teraterm. Have to remember to disable the toolbar or garbage gets in the log. Have to tell teraterm where to save the log every time. Etc.
To make things stupid easy, I guess a 2K buffer should be used to match the NAND sector size. When the buffer fills, flush it to NAND. When done logging flush the buffer if anything is in it.
If this can be implemented easily, I will do it before reworking all the terminal output examples.
Isn’t this something that is better solved on the terminal program side?
I really like tio and it comes with all the logging options you want. --log --log-strip
should do what you want and strip all control characters for you. It can do a lot more, from adding timestamps to each line to integrated lua scripting.
It also seems to be available on Windows via MSYS2. And I heard that Microsoft improved the shell usability in the last few Windows releases. So maybe your terminal program doesn’t really need to come with it’s own GUI.
I do not want to stifle your enthusiasm about a new feature and I am not against it. But I consider this something that can easily be solved on the host pc side. I think it would make more sense to invest the time into stuff that can only be done on the BusPirate itself and that extends the features of the BP or fixes actual usuability issues regular users have.
I relented and fell back on the TeraTerm logging to get things moving
Here are the new header links. This will be used on the site homepage as well as the site links in the left side of the forum.
This is the current order of the table of contents. I put “download firmware” at the top.
Two page updates so far, I’m pretty please with the added info and illustrations. It also matches the latest firmware experience.
I’ll proceed with updating all the tutorial pages next.
Tutorial - Basics section has been updated and slightly reworked.
Tomorrow:
- Bus Pirate 6 hardware design (illustrate FALA buffer section)
- Master command reference page
I’m glad you decided against this.
In case it's thought of again in future...
I agree one would think this would be “stupid easy”, but unfortunately, I can immediately think of some complexities:
File System Limits
IIRC, the file system has a hard-coded limited number of open handles allowed. The limit is quite low (2?), and I’m not sure if that includes the directory handle (essentially allowing a single file at a time).
Edge Cases made more common
If the host has cached any file system updates, today that has no negative effect when the terminal opens, does stuff, and closes without changing the file system. If you add logs that modify the root directory, this could exacerbate a long-standing (but rare-ish) file system corruption due to the shared-writeable-volume.
RANDOM timing impacts to everything!
Auto-open of the log file when terminal connects is easy, as is automatically closing the log file when the terminal disconnects, and neither would really impact operations.
However, writing to NAND at non-controlled time (based on output passing a 2k buffer limit) would have a significantly negative impact on any time-sensitive commands. It would add a level of randomness to timing that would make it more difficult to write other features.
For example, if feature X someday logged to a log file, maybe it could pre-allocate space and do other hacks to remove the random-timing aspects of the FS overhead, and thus ensure it is able to stream data directly for an extended time. But add in other background flash access, and things go south quickly.
Keep logging of terminal output where it belongs … in the client. Yes, it’d be “neat” to have this log. But … the edge cases and increased difficulty in debugging timing-related problems is so severe that I would not recommend this.
TLDR: Increased difficulty in debugging timing-related problems is severe, making any background NAND writing a non-recommended feature.
Recommendation: An actively executing command retains exclusive access to the NAND, allowing it to predictably decide when NAND operations occur.
For the teraterm instructions I wonder if this step could be eliminated as the settings don’t mean much. Instead just opening a new connection (alt N in teraterm).
Maybe asciinema?
This is quite nice. You may set terminal speed and just “record” as text not video so it takes very little space. And then use it as some tutorials using BP terminal or as examples on the docs pages.