For I2C, could you use an I2C-based rotary encoder? That way, you have control over when the values change. Adafruit sells some Adafruit I2C Stemma QT Rotary Encoder, which at least ensures you can find documentation.
I’m happy to send you one as a gift, if you’d like.
Mobile SIM & bank card and 24C02 EEPROM IC card demos updated with autosnips, autocast, and datasheet integration.
I also tried to be sure to link back into the command reference for every command used (m, W, P, etc), and went back and updated the LEDs tutorial as well.
Fixed some firmware display bugs and resnipped everything in the command reference 
This is the true power of the new autosnip and autocast - fix a bug and update the docs in seconds.
Hints for autosnip & autocast:
m hiz
c
3
1
x
rm bpi2c.bp
# 24c02-setup
m i2c
100
1
# 24c02-power
I start every snip script with m hiz; c 3 1 x; rm bpi2c.bp to setup the Bus Pirate before making snips. This:
rm bpi2c.bp
m i2c
100
1
W 5
P
[0xa0 0x00 0xff:8]
[0xa0 0x08 0xff:8]
m hiz
c
3
2
x
rm bpi2c.bp
# 24c02-cast
m i2c # m i2c - enter I2C mode
The screencast is even more involved. First we go to I2C, enable power, pullups. Then we erase the rows used in the demo so they start fresh. Then we go to hiz, enable toolbar, delete the mode config file, and then start the screencast capture.
I’m uploading all my -snip.txt and -scat.txt scripts to the /tools/ folder of the docs repo.
Good suggestion. I’ll read through the datasheet.
Massive update to the W25QXXX NOR Flash demo. Fully reworked demo with datasheet extracts, snips, and a screencast.
This was an enormous update, so I didn’t managed to do the screencast and snips for the flash command. I’ll do that next.
After that there are only two sensor demos and a new GPS demo to deal with. Nearly, almost, done 
ETA: ah man, I flubbed it. Used the wrong chip size. Not a big deal, hopefully I have the right chip around there somewhere.
Yeah! Find the right chip for the demo, also noticed a bug or two in the flash docs.
Flash demo and flash command screencast updated.
2 sensors & a GPS demo remain.
The asciinema player should be responsive and resize with the page size now. Does it look ok for you?
If it’s looking good, I will redirect all the old docs to the new docs site this weekend
Thank you for checking, I’m sorry! I didn’t push 
Live site is updated now.
Thank you! I think it’s time to make it the main docs.
I’m trying to figure out if it also has a blog like feature, I thought it did but apparently not. If it has a blog feature I’d eliminate the ghost install we currently use for the very rare announcement of new hardware.
Updated the si7021 demo.
It still turned out longer/more detailed that I think is needed, especially for a EOL NRND device! The section detailing the configuration register gets at the heart of how I2C devices work, and just couldn’t help but include it. Maybe that was a bad idea. I welcome any feedback on that.
Updated SHT30 and SHT40 series devices are on the way. Both are very different from the SHT20/si7021 (and each other), but I think the basic template of the si7021 can be used to get the demos online quickly.
Demos to update:
Other stuff:
Converted all the math stuff to Katex, looks a bit nicer. Also went ahead and updated tsl2561, just a small tidying up.
Tomorrow I will do the GPS (weather permitting) and demo screencast. Infrared will have to wait.
Weather is too awful for the GPS demo, but I put together the “sizzle reel” screencast giving an overview of some of the more visually interesting features. Compared to tutorial screencasts, everything is sped up 2x.
Each section is an indivivual screencast capture. I tried to merge them with a python package for editing acsiinema screencasts, but it wouldn’t work.
So, a new tool in the docs/tools folder: mergecast.py. Usage:
python mergecast.py file1.json file2.json merged_file.json
I’m going to declare this good enough for now and point all the old docs sites at the new site.
Rather than redirecting the old sites and losing all the existing links, I added an announcement and a banner to each page.
This required yet another python script to automagically process all the markdown files, which saved a ton of time. Firmware.buspirate is updated (updating, docusaurus=slowsaurus), I’ll finish up harware.buspirate tomorrow.
Then it’s probably unavoidable to spend a day updating all the site headers and footers.
Thank you for hanging in there during the last few weeks as I tackled the documentation backlog. It’s not 100% complete, but enough I don’t feel awful about it.
Going forward I think it will be much easier to keep the docs updated.
The old system, NodeJS/docusaurus, was SUPER slow. When I added the “this site is no longer maintained” banner, even on my mighty new laptop, updates were so slow I could do some tasks around the house and come back with time to spare. It also constantly chokes on our terminal output captures.
The new system, Go/Hugo, is super FAST. The entire site rebuilds in less than a second. Now I can write docs as I work. I’ve been using the markdown features in the forum to draft docs here, with the intent to move them over, but that doesn’t turn out to be an effective workflow.
Thanks again for bearing with me. It has been an absolute marathon. Now we should return to “your normally scheduled programming”.
Some things to do on the next docs update:
This is just a mock up, but something like this. I really want to reinforce the pattern of
It will be a ton of work, but I think it will level up the value of the docs as a learning tool.
This is just amazing!
I think this is one of the best ideas to attract people interested in getting started with hardware hacking, and also to encourage them to choose the Bus Pirate as their first tool.
Updated the live docs with a version of the I2C overview. Is it clear? I don’t want to go too in the weeds, but it’s nice to have that connection.
That’s awesome, @Ian I’m already working on the ATC documentation. For example, in my captures I’m pointing out and explaining that there’s a saleae-extension that already shows things like 0xA0 directly on the timeline…
Sounds good, but be careful about linking too much to one of software package. If anything, the FALA would be the integrated option to include on docs. It feels like specific la decoder instructions may be out of the scope of a tutorial. Maybe I’m misunderstanding.
