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.
I added redirects from the base docs.buspirate.com/ to a landing page in the docs. The default is an ugly default landing page, which I tried to edit down to something usable, but there is a bug and the default template stuff won’t go away.
It is probably time to make the new docs the main docs. I’ll start updating all the different themes to link there.
asciinema looks amazing! What as great addition for device demos, intros, etc.
@AreYouLoco are you able to use asciinema to record Bus Pirate output? Through what terminal? screen?
It is installed and working, but I can’t manage to attach the Bus Pirate to my WSL instance. I think it is the flash drive changing modes, I will disable the drive and try without.
For now I am quite busy with day-work kliken maken thing. But afternoon I will try to capture something. Need to reflash main firmware as I have DirtyJTAG now.
So I didnt have time I was not home. But I looked up upon di Internets. And seems you cannot record tio with ascinema. I saw its doable with screen and tmux. So you start session normally and then attach to it with asciinema.
Thank you so much! If I can get the wsl USB stuff going I’ll try screen.
What problems are you having with WSL? I’ve used my Tigard in WSL using USB passthrough Connect USB devices | Microsoft Learn
I just did this maybe 2 months ago, so things shouldn’t have changed too much. From what I remember you just install GitHub - dorssel/usbipd-win: Windows software for sharing locally connected USB devices to other machines, including Hyper-V guests and WSL 2. then use usbipd list
to get your USB device list, then usbipd bind --busid <ID from list>
and lastly usbipd attach --wsl --busid <ID from list>
I’ll give this a try tonight.
The issue seems to be related to the swap when the USB drive detaches and attaches as read/write. Attach hangs for a bit while the drive beeps and burps while reattaching. Then wsl says device error.
I think I need to add a compile switch to prevent the drive reattach.
Please let me know though, it could be an issue specific to my system or setup.
It’s not immediately working for me either. I can get the device to show up in Ubuntu WSL but it appears to be dead when I connect to it.
In windows to attach the BP:
dmesg from Ubuntu WSL:
Output from tio:
Is this what you are getting too?
I’m pretty sure it’s a driver issue. I tried to complie the kernel using these instructions rpasek/usbip-wsl2-instructions but it’s pretty old and I’m on 5.15.167.4. When I try to compile I get
BTF: .tmp_vmlinux.btf: pahole (pahole) is not available
Failed to generate BTF for vmlinux
Try to disable CONFIG_DEBUG_INFO_BTF
make: *** [Makefile:1226: vmlinux] Error 1
I haven’t had time to dig into that error yet and I need to get to sleep. I’ll poke at it more tomorrow