Cogs & Squigs

Internet Standards and Fascism

Fri, 24 Jan 2025 00:00:00 +0000

What do all of these things have in common? Well, they’re all crucial, important pieces of how we communicate today — without them, we wouldn’t even be able to text, email, or even just go online. They set the standards, organizations, and utilities we use to make sure that, for example:

I can create this website using web standards (W3C, IETF, OpenJS Foundation)</li>

This website can be published under the name

cogsandsquigs.dev</code> (IANA, ICANN)</li>

Your computer knows how to get from cogsandsquigs.dev</code> to it’s IP address (IANA, ICANN, IETF)</li>

Your computer can route it’s packets from itself to cogsandsquigs.dev</code>’s IP (IETF)</li>

Your computer can decode the packets it receives from cogsandsquig.dev</code> (IETF)</li>

Your browser can understand the decoded files — HTML, CSS, JS (W3C, Unicode)</li>

Your browser can display the decoded files (W3C, Unicode)</li>

Your browser (and consequently, computer) understand when I published this page (IANA, specificallyTZDB</a>)</li> </ol> Any one of these things going offline would result in massive catastrophe across the internet, and subsequently would probably lead to the shuttering of many necessary and important services we use day-to-day (think: email communication, texting, digital maps, etc.). And yet, here they are. In the US of A. Which is currently suffering under a fascist regime (and if you don’t think that, I just hope you read a history book one day). If Trump (or, let’s be honest, Musk) decides to target any one of these organizations, we’re basically done for. No more communication globally, at all. Zip. Zilch. Nada. It’s not gonna be another Great Firewall (a la China). Instead, all of the internet will be at stake. People in unrelated countries, with unrelated politics and unrelated gripes will suffer. We all will. I pray that hopefully, this doesn’t happen. Hopefully, I’m wrong. Hopefully, we can trust these organizations. We will see.



Dotbak
Tue, 18 Jul 2023 05:00:00 +0000
When I made this, I was facing an issue: how do I synchronize my shared environments, my laptop,
desktop, and even (home)server? How can I make it as easy as possible to share my dotfiles?</p>
The current methods were always too tedious and time-consuming to update my dotfiles: I needed to go
to the locations where they’re stored (not where they exist in my filesystem), update them there,
run a command to update the files across my computer, and finally back them up.</p>
With dotbak</code>, I can run a single command, dotbak sync</code>, to update my dotfiles right where they
are in the filesystem!</em> I don’t need to run
something like</a>
chezmoi cd && git add . && git commit -m "Dotfile update"</code>. Instead, It’s just one command.</p>
You might wonder why I would go through making my solution when there are probably other solutions
that would work. After all, why reinvent the wheel?



For one, I want to get experience making something that would impact people, even if that person is
just me. The process of creating is always something that I can learn from, and I don’t want to just
use a solution that I don’t learn anything from.</p>
This brings me to my second point, which is that I want to understand</em> the solution I’m given. If I
don’t understand how something works, then why use it? What if it breaks, or ruins my system, or is
feature-incomplete (for me, at least)? With a home-grown solution, I can make all the features I
need, and patch all the fixes I want when I want.</p>
Right now, this project is mostly complete. In the future, I may add more features like automatic
synchronization in the background (using some kind of daemon), but that’s only if I have the time,
energy, and need for it. Otherwise, this is mostly done!</p>
If you’re interested in using dotbak</code>, give it a try! If there’s anything you want me to fix or
add, you can make an issue or pull request, and I’ll try to incorporate it as best I can. However,
remember that I’m just one person, and I kinda have a lot of other things on my plate right now, so
please be patient and kind!</p>


(Actually) Binding Rust to Swift
Sun, 16 Jul 2023 05:00:00 +0000
So, about Rust.</p>
It’s great and all, but unfortunately, not every</em> company supports using Rust directly on their
platform (boo! boo Apple!). In my case, it’s (surprise, surprise) Apple that doesn’t support Rust
instead of Swift. However</em>, other people have had this problem in the past, and they’ve created
solutions to work around this.</p>
Why am I writing about binding Swift to Rust in the first place? Because for my work, I needed to
create an assembler for a custom CPU</a> (called
nand7400</code>) that’s programmed via an iOS/MacOS app. Besides, bindings are a (theoretically) fun
adventure into more low-level concepts, something I wanted to (quote-unquote) enjoy more often.</p>
My poison of choice for this project is UniFFI</a>. This library
allows Swift to bind and call to Rust, without much hassle (remember the “much”). You should go read
the docs, but in essence:</p>

Define a .udl file</a> which
specifies</a> the exposed APIs.</li>
Include some
magic mumbo jumbo</a> in your
library to expose the symbols (This step is VERY important! It won’t generate any warnings if
it’s skipped, but doing so will lead to undefined symbol errors down the line in Xcode or
whatever).</li>
Create and export code</a>
in your language of choice via an
associated binary</a>.
You can also use
custom back-ends</a>
for unofficially supported languages!</li>
</ol>
That’s it! The documentation pretty much ends there, and expects you to package everything nice and
neat like the good little developer you are. Funnily enough, there’s not a lot of documentation
online on how to do this, even on Apple’s part. Fortunately, some guy has a
guide</a> on how to package Rust
applications into an XCFramework</code>, which is a special type of binary that can be used on Apple
platforms. There’s also a rust library</a> that demonstrates
compiling to an XCFramework</code>, which that guy worked on!</p>
To get everything up and running, follow
that guide</a> to set up your dev
environment for creating an XCFramework</code>. You can use
my own makefile</a> to set up and
compile everything, too, which is shown below. In my case, I have the main Rust library in
nand7400</code>, the Swift-binding Rust scaffolding code in nand7400-ffi</code>, and export the Swift code to
nand7400-ffi-bindings/swift</code> (I used the YSwift repository’s
build script</a> to start
this Makefile</code>, then tweaked it to my liking and specific setup).</p>
# This makefile is used to build the Nand7400 framework for iOS, macOS and Mac Catalyst. To use it, run `make package` in</span></span>
# the root of the repository.</span></span>
</span>
# Rust-specific configuration</span></span>
PACKAGE_NAME=nand7400-ffi</span></span>
LIB_NAME=libnand7400_ffi.a</span></span>
CARGO_FLAGS= --package </span>${</span>PACKAGE_NAME</span>}</span> --lib --locked --release</span></span>
</span>
# General binding configuration</span></span>
UNIFFI_CMD=cargo run -p nand7400-ffi --features=cli --bin uniffi --</span></span>
UNIFFI_UDL_FILE=src/ffi.udl</span></span>
</span>
# General build configuration</span></span>
BUILD_FOLDER=target</span></span>
ARTIFACTS_FOLDER=target/uniffi-artifacts</span></span>
BINDINGS_FOLDER=nand7400-ffi-bindings</span></span>
</span>
# Testing/fuzzing stuff</span></span>
FUZZ_TARGET=nand7400-fuzz</span></span>
# Additional flags for AFL besides the input, output and target binary</span></span>
AFL_FLAGS=-d -D</span></span>
</span>
# Swift-specific stuff</span></span>
FRAMEWORK_NAME=Nand7400FFI</span></span>
XCFRAMEWORK_FOLDER=target/</span>${</span>FRAMEWORK_NAME</span>}</span>.xcframework</span></span>
</span>
# Install all the necessary build targets to build for Mac, iOS and Mac Catalyst.</span></span>
setup-build</span>:</span></span>
	@</span>echo "▸ Installing toolchains..."</span></span>
# 	iOS Simulator (Intel)</span></span>
	@</span>rustup target add x86_64-apple-ios</span></span>
#	iOS Simulator (M1)</span></span>
	@</span>rustup target add aarch64-apple-ios-sim</span></span>
#	iOS Device</span></span>
	@</span>rustup target add aarch64-apple-ios</span></span>
#	macOS ARM/M1</span></span>
	@</span>rustup target add aarch64-apple-darwin</span></span>
#	macOS Intel/x86</span></span>
	@</span>rustup target add x86_64-apple-darwin</span></span>
</span>
clean</span>:</span></span>
	@</span>echo ▸ Cleaning build...</span></span>
	@</span>rm -rf </span>${</span>ARTIFACTS_FOLDER</span>}</span></span>
	@</span>rm -rf </span>${</span>XCFRAMEWORK_FOLDER</span>}</span></span>
	@</span>rm -rf </span>${</span>BINDINGS_FOLDER</span>}</span></span>
	@</span>mkdir -p </span>${</span>ARTIFACTS_FOLDER</span>}</span></span>
	@</span>mkdir -p </span>${</span>BINDINGS_FOLDER</span>}</span></span>
</span>
bind</span>: setup-build clean</span></span>
	@</span>echo "▸ Generating Swift scaffolding code..."</span></span>
	${</span>UNIFFI_CMD</span>}</span> generate </span>${</span>PACKAGE_NAME</span>}</span>/</span>${</span>UNIFFI_UDL_FILE</span>}</span> --language swift --out-dir </span>${</span>BINDINGS_FOLDER</span>}</span>/swift</span></span>
</span>
build-swift</span>: bind</span></span>
	@</span>echo "▸ Building for x86_64-apple-ios..."</span></span>
	@</span>CFLAGS_x86_64_apple_ios="-target x86_64-apple-ios" </span>\</span></span>
	cargo build --target x86_64-apple-ios </span>${</span>CARGO_FLAGS</span>}</span></span>
</span>
	@</span>echo "▸ Building for aarch64-apple-ios-sim..."</span></span>
	@</span>CFLAGS_aarch64_apple_ios="-target aarch64-apple-ios-sim" </span>\</span></span>
	cargo build --target aarch64-apple-ios-sim </span>${</span>CARGO_FLAGS</span>}</span></span>
</span>
	@</span>echo "▸ Building for aarch64-apple-ios..."</span></span>
	@</span>CFLAGS_aarch64_apple_ios="-target aarch64-apple-ios" </span>\</span></span>
	cargo build --target aarch64-apple-ios </span>${</span>CARGO_FLAGS</span>}</span></span>
</span>
	@</span>echo "▸ Building for aarch64-apple-darwin..."</span></span>
	@</span>CFLAGS_aarch64_apple_darwin="-target aarch64-apple-darwin" </span>\</span></span>
	cargo build --target aarch64-apple-darwin </span>${</span>CARGO_FLAGS</span>}</span></span>
</span>
	@</span>echo "▸ Building for x86_64-apple-darwin..."</span></span>
	@</span>CFLAGS_x86_64_apple_darwin="-target x86_64-apple-darwin" </span>\</span></span>
	cargo build --target x86_64-apple-darwin </span>${</span>CARGO_FLAGS</span>}</span></span>
</span>
	@</span>echo "▸ Building for x86_64-apple-ios-macabi..."</span></span>
	@</span>CFLAGS_x86_64_apple_ios="-target x86_64-apple-ios-macabi" </span>\</span></span>
	cargo +nightly build -Z build-std --target x86_64-apple-ios-macabi </span>${</span>CARGO_FLAGS</span>}</span></span>
</span>
	@</span>echo "▸ Building for aarch64-apple-ios-macabi..."</span></span>
	@</span>CFLAGS_aarch64_apple_ios="-target aarch64-apple-ios-macabi" </span>\</span></span>
	cargo +nightly build -Z build-std --target aarch64-apple-ios-macabi </span>${</span>CARGO_FLAGS</span>}</span></span>
</span>
	@</span>echo "▸ Consolidating the headers and modulemaps for XCFramework generation..."</span></span>
	@</span>mkdir -p </span>${</span>ARTIFACTS_FOLDER</span>}</span>/includes</span></span>
	@</span>cp </span>${</span>BINDINGS_FOLDER</span>}</span>/swift/</span>${</span>FRAMEWORK_NAME</span>}</span>.h </span>${</span>ARTIFACTS_FOLDER</span>}</span>/includes</span></span>
	@</span>cp </span>${</span>BINDINGS_FOLDER</span>}</span>/swift/</span>${</span>FRAMEWORK_NAME</span>}</span>.modulemap </span>${</span>ARTIFACTS_FOLDER</span>}</span>/includes/module.modulemap</span></span>
</span>
	@</span>echo "▸ Merging x86 and arm iOS simulator static libraries into a fat static binary..."</span></span>
	@</span>mkdir -p </span>${</span>ARTIFACTS_FOLDER</span>}</span>/ios-simulator/release</span></span>
	@</span>lipo -create </span>\</span></span>
		./</span>${</span>BUILD_FOLDER</span>}</span>/x86_64-apple-ios/release/</span>${</span>LIB_NAME</span>}</span> \</span></span>
		./</span>${</span>BUILD_FOLDER</span>}</span>/aarch64-apple-ios-sim/release/</span>${</span>LIB_NAME</span>}</span> \</span></span>
		-output </span>${</span>ARTIFACTS_FOLDER</span>}</span>/ios-simulator/release/</span>${</span>LIB_NAME</span>}</span></span>
</span>
	@</span>echo "▸ Merging x86 and arm macOS static libraries into a fat static binary..."</span></span>
	@</span>mkdir -p </span>${</span>ARTIFACTS_FOLDER</span>}</span>/apple-darwin/release</span></span>
	@</span>lipo -create </span>\</span></span>
		./</span>${</span>BUILD_FOLDER</span>}</span>/x86_64-apple-darwin/release/</span>${</span>LIB_NAME</span>}</span> \</span></span>
		./</span>${</span>BUILD_FOLDER</span>}</span>/aarch64-apple-darwin/release/</span>${</span>LIB_NAME</span>}</span> \</span></span>
		-output </span>${</span>ARTIFACTS_FOLDER</span>}</span>/apple-darwin/release/</span>${</span>LIB_NAME</span>}</span></span>
</span>
	@</span>echo "▸ Merging x86 and arm macOS Catalyst static libraries into a fat static binary..."</span></span>
	@</span>mkdir -p </span>${</span>ARTIFACTS_FOLDER</span>}</span>/mac-catalyst/release</span></span>
	@</span>lipo -create </span>\</span></span>
		./</span>${</span>BUILD_FOLDER</span>}</span>/x86_64-apple-ios-macabi/release/</span>${</span>LIB_NAME</span>}</span> \</span></span>
		./</span>${</span>BUILD_FOLDER</span>}</span>/aarch64-apple-ios-macabi/release/</span>${</span>LIB_NAME</span>}</span> \</span></span>
		-output </span>${</span>ARTIFACTS_FOLDER</span>}</span>/mac-catalyst/release/</span>${</span>LIB_NAME</span>}</span></span>
</span>
</span>
package-swift</span>: build-swift</span></span>
	@</span>echo "▸ Creating XCFramework..."</span></span>
#	what docs there are:</span></span>
#	xcodebuild -create-xcframework -help</span></span>
#	https://developer.apple.com/documentation/xcode/creating-a-multi-platform-binary-framework-bundle</span></span>
	@</span>BUILD_LIBRARY_FOR_DISTRIBUTION=YES </span>\</span></span>
	xcodebuild -create-xcframework </span>\</span></span>
		-library ./</span>${</span>BUILD_FOLDER</span>}</span>/aarch64-apple-ios/release/</span>${</span>LIB_NAME</span>}</span> \</span></span>
		-headers ./</span>${</span>ARTIFACTS_FOLDER</span>}</span>/includes </span>\</span></span>
		-library ./</span>${</span>ARTIFACTS_FOLDER</span>}</span>/ios-simulator/release/</span>${</span>LIB_NAME</span>}</span> \</span></span>
		-headers ./</span>${</span>ARTIFACTS_FOLDER</span>}</span>/includes </span>\</span></span>
		-library ./</span>${</span>ARTIFACTS_FOLDER</span>}</span>/apple-darwin/release/</span>${</span>LIB_NAME</span>}</span> \</span></span>
		-headers ./</span>${</span>ARTIFACTS_FOLDER</span>}</span>/includes </span>\</span></span>
		-library ./</span>${</span>ARTIFACTS_FOLDER</span>}</span>/mac-catalyst/release/</span>${</span>LIB_NAME</span>}</span> \</span></span>
		-headers ./</span>${</span>ARTIFACTS_FOLDER</span>}</span>/includes </span>\</span></span>
		-output ./</span>${</span>XCFRAMEWORK_FOLDER</span>}</span></span>
</span>
#	Move modulemaps to the right place, so that the XCFramework can be used directly in Swift Package Manager</span></span>
	@</span>mkdir -p </span>${</span>XCFRAMEWORK_FOLDER</span>}</span>/ios-arm64/Modules</span></span>
	@</span>mkdir -p </span>${</span>XCFRAMEWORK_FOLDER</span>}</span>/ios-x86_64-simulator/Modules</span></span>
	@</span>mkdir -p </span>${</span>XCFRAMEWORK_FOLDER</span>}</span>/ios-arm64_x86_64-simulator/Modules</span></span>
	@</span>mkdir -p </span>${</span>XCFRAMEWORK_FOLDER</span>}</span>/ios-arm64_x86_64-maccatalyst/Modules</span></span>
	@</span>mkdir -p </span>${</span>XCFRAMEWORK_FOLDER</span>}</span>/macos-arm64_x86_64/Modules</span></span>
	@</span>cp </span>${</span>BINDINGS_FOLDER</span>}</span>/swift/</span>${</span>FRAMEWORK_NAME</span>}</span>.modulemap </span>${</span>XCFRAMEWORK_FOLDER</span>}</span>/ios-arm64/Modules/module.modulemap</span></span>
	@</span>cp </span>${</span>BINDINGS_FOLDER</span>}</span>/swift/</span>${</span>FRAMEWORK_NAME</span>}</span>.modulemap </span>${</span>XCFRAMEWORK_FOLDER</span>}</span>/ios-x86_64-simulator/Modules/module.modulemap</span></span>
	@</span>cp </span>${</span>BINDINGS_FOLDER</span>}</span>/swift/</span>${</span>FRAMEWORK_NAME</span>}</span>.modulemap </span>${</span>XCFRAMEWORK_FOLDER</span>}</span>/ios-arm64_x86_64-simulator/Modules/module.modulemap</span></span>
	@</span>cp </span>${</span>BINDINGS_FOLDER</span>}</span>/swift/</span>${</span>FRAMEWORK_NAME</span>}</span>.modulemap </span>${</span>XCFRAMEWORK_FOLDER</span>}</span>/ios-arm64_x86_64-maccatalyst/Modules/module.modulemap</span></span>
	@</span>cp </span>${</span>BINDINGS_FOLDER</span>}</span>/swift/</span>${</span>FRAMEWORK_NAME</span>}</span>.modulemap </span>${</span>XCFRAMEWORK_FOLDER</span>}</span>/macos-arm64_x86_64/Modules/module.modulemap</span></span>
</span>
	@</span>echo "▸ Compressing XCFramework..."</span></span>
	@</span>ditto -c -k --sequesterRsrc --keepParent </span>${</span>XCFRAMEWORK_FOLDER</span>} ${</span>XCFRAMEWORK_FOLDER</span>}</span>.zip</span></span>
</span>
	@</span>echo "▸ Computing checksum..."</span></span>
	@</span>swift package compute-checksum </span>${</span>XCFRAMEWORK_FOLDER</span>}</span>.zip > </span>${</span>XCFRAMEWORK_FOLDER</span>}</span>.zip.sha256</span></span>
</span>
	@</span>echo "▸ Finished Swift bindings!"</span></span>
</span>
# Convenience target to build and package everything</span></span>
package</span>: package-swift</span></span>
	@</span>echo "▸ Done!"</span></span></code></pre>
We’re not done, however. We also need to define a Package.swift</code> that tells Xcode how to install
the swift binary. This is mostly also copied from the above repo, and is shown below:</p>
// swift-tools-version:5.8</span></span>
</span>
import</span> Foundation</span></span>
import</span> PackageDescription</span></span>
</span>
let</span> FFIbinaryTarget: PackageDescription.Target</span></span>
</span>
let package =</span> Package</span>(</span></span>
	name</span>:</span> "Nand7400"</span>,</span></span>
	platforms</span>: [.</span>iOS</span>(.v13), .</span>macOS</span>(.v10_15)],</span></span>
	products</span>: [</span></span>
		.</span>library</span>(</span></span>
			name</span>:</span> "Nand7400"</span>,</span></span>
			targets</span>: [</span>"Nand7400"</span>]</span></span>
		),</span></span>
	],</span></span>
	dependencies</span>: [],</span></span>
	targets</span>: [</span></span>
		.</span>target</span>(</span></span>
			name</span>:</span> "Nand7400"</span>,</span></span>
			dependencies</span>: [</span>"Nand7400FFI"</span>],</span></span>
			path</span>:</span> "nand7400-ffi-bindings/swift"</span></span>
		),</span></span>
		.</span>binaryTarget</span>(</span></span>
			name</span>:</span> "Nand7400FFI"</span>,</span></span>
			url</span>:</span> "https://github.com/cogsandsquigs/nand7400/releases/download/v0.3.1/Nand7400FFI.xcframework.zip"</span>,</span></span>
			checksum</span>:</span> "3bcdfb390e55cd7f940a5fabb1944f8bb2fbf85791a3b8c55fbd1492d1c18428"</span></span>
		),</span></span>
	]</span></span>
)</span></span></code></pre>
We define a .target</code> to export to, and also a .binaryTarget</code> which the .target</code> depends on
(that’s where the bindings live). I also specify a path to the swift bindings in .target</code>, because
the default is Sources</code>.</p>
Once everything’s done and set up, you should be good to go! If you’re running my makefile, run
make package</code> to package everything up into an XCFramework</code>, then export that somewhere and put
the link (as well as the sha256</code>) in the Package.swift</code> file.</p>
Happy binding!</p>


Flash Portenta H7 with Nucleo on-board STLink
Wed, 14 Jun 2023 05:00:00 +0000
This post comes from an issue I had at work, that I spent hours trying to debug and fix. Now, you
can avoid my terrible fate!</p>
Sometimes, after messing around with things for a while, you’ll cause your Arduino Portenta H7 to
brick itself by scrambling the bootloader. This leads to:</p>


The leftmost orange LED staying on permanently, or with occasional flickering.</p>
</li>

The Portenta no longer responds over USB, and thus cannot be programmed the usual way.</p>
</li>
</ul>
To fix this issue, you’ll need to flash the Portenta’s bootloader with an external JTAG/SWD debugger
of your choice. In my case, I had an STLink-V3PWR to flash with, but that kept failing for some
unknown reason. So, I decided to use a Nucleo-64 on-board STLink-V2 debugger to flash. This is how I
did it.</p>



    🔗
</a>
Materials</h2>


1 Portenta H7</a> board, bricked or otherwise.</p>
</li>

1 Portenta Breakout</a> board.</p>
</li>

1 Nucleo</a> board with built-in STLink
debugger. I used a Nucleo-F072RB, but similar boards may work. The documentation for Nucleo-F072RB
boards is
here</a>,
and a list of documentation for all Nucleo boards is
here</a>.</p>
</li>

5 strands of thin wire that can wrap around the JTAG pins on the Portenta breakout. I used
Saleae Test Leads</a> with
their Saleae Test Clips</a>.</p>
</li>

1 USB-C cable (for the portenta).</p>
</li>

1 Mini-USB cable (for the Nucleo).</p>
</li>
</ul>



    🔗
</a>
Procedure</h2>


Connect the Portenta to the Portenta breakout board. If desired, break off the Nucleo debugger
(it is the smaller portion attached by 3 bridges to the main board).</p>
</li>

Remove the CN2</strong> jumpers off of the Nucleo debugger. This section may change, so refer to your
board’s documentation on using the on-board debugger to debug external chips.</p>
</li>

Connect jumper wires to the SWD</strong> section (also labeled CM4</strong>) of the Nucleo debugger. Refer
to your board’s documentation for more information on where to place these. A picture of the
wires are shown below.</p>
</p>
</li>

Connect the Nucleo debugger to the Portenta. This step is non-trivial, so pay attention! The
diagrams below show the respective pinouts of important areas for the two boards.</p>
Nucleo debugger:</p>
</p>
Portenta breakout JTAG connector:</p>
</p>
</li>

In the following order, use the 5 wires to connect these 5 pins from the Nucleo debugger to the
Portenta JTAG pins:</p>

VDD_TARGET</strong> (pin 1) to +3V3</strong> (pin 1)</li>
SWCLK</strong> (pin 2) to TCK/SWCLK</strong> (pin 4)</li>
GND</strong> (pin 3) to GND</strong> (pin 3, 5, or 9)</li>
SWDIO</strong> (pin 4) to TMS/SWDIO</strong> (pin 2)</li>
NRST</strong> (pin 5) to RESET</strong> (pin 10)</li>
</ul>
A picture of the setup is shown below:</p>
</p>
</li>

Connect both</strong> the Nucleo debugger and the Portenta to power. Make sure that each cable can
transfer data to and from their respective ports.</p>
</li>

In the Arduino IDE, go to Tools > Port</strong> and set the port to the Nucleo debugger (it should
show up as a long string of numbers). Go to Tools > Programmer</strong> and set it to
STMicroelectronics STLINK</strong>. Make sure that the board type is set to Portenta H7</strong>.</p>
</li>

Go to Tools > Burn bootloader</strong>. The bootloader should now be burned onto the Portenta!</p>
</li>
</ol>
And now, the issue should be resolved. The orange LED should no longer stay on permanently, and you
can now flash any program you like onto the Portenta.</p>


Hematite
Tue, 07 Feb 2023 05:00:00 +0000
This is a Battlesnake</a> that I made a a while ago, which I still run
on fly.io</a> to this day. Occasionally, I may try to improve it, although I have a
few other things going on right now, so it’s not top priority.</p>
Currently, it uses a heuristic approach combined with a Monte-Carlo tree search. However, that lead
to worse performance both in time and in ability, so my next steps are to either roll it back to
plain heuristics or to improve upon the search.</p>


Flying high
Sun, 27 Nov 2022 18:00:00 +0000
Flying high, I see the skies that cradle the ground below, with its shifting hues casting an
iridescent delight to those below and above. Clouds roll by, forming an unbeknownst land of
night-dark ocean and puffy-white ground. Shifting and changing, it renews itself, creating worlds in
the air that only exist for a moment.</p>
I wonder if these worlds have people. Would they be perturbed by their ever-changing domain? Would
they have adapted, becoming one with their kingdom in the sky? Endless questions drift by,
entertaining thoughts and ideas for a while.</p>
Passing through the clouds, I see a grid of lit houses, their lights flickering as endless minuscule
shapes flash by. Almost like it’s living, the light moves and waves and dances in the night, a sight
to behold from above. Scurrying like ants, vehicles cast their presence across the roads, twisting
and turning into their homes for tonight.</p>
The last thing I see before landing is the vestiges of the sky and land connected on the horizon,
with the shadows of structures standing prominently in-between, an inescapable presence.</p>


Jarfe
Fri, 14 Oct 2022 05:00:00 +0000
This was just a silly side-project to make a JSFuck</a> compiler, in Rust of
course! I just wanted something to do, so why not this?</p>
It was fun making this, and while it serves no practical purpose, it was at least a nice distraction
from boredom. Maybe you’ll find it useful? (I doubt it)</p>


Slaving away so you don’t have to
Fri, 05 Aug 2022 00:00:00 +0000
Sooo… where was I?</p>
Mostly just doing my own thing, building stuff, breaking stuff, etc., etc. Living the dream, as some
might say.</p>
Part of what I was doing was taking the long, winding road to creating
cogsandsquigs/twiboot</a> (not to be confused with
orempel/twiboot</a>, but that’ll be explained later). How I got
here was long, tiring, and frankly too exhausting. So that’s where two (of the many previous) weeks
of my life went!</p>
Flashback to 2 weeks prior: I was sitting around, minding my own buisness, when my boss and I were
having a discussion about what to do about our problem: The chips we were using for our internal
project didn’t support OTA updates. They’re just tiny little ATmega328s, which we could possibly
ship with buggy or outright broken code! Fortunately, these guys were controlled by a Particle
Argon, which could connect to WiFi and did</em> support OTA updates.</p>
The question was, how do we get the ATmegas to be updated by the Argon? The answer was a
bootloader</strong>, of course! A custom bootloader which could be controlled (for a split second) by the
Argon, which could send it new firmware through a communication protocol (I2C/TWI was the one we
were gonna use), and bam! updates! How hard could it be? Not worse than coding in C for the Argon
and Arduino Uno (basically an ATmega + nice libraries + nice hardware), right?</p>
As it turns out, it was awfully hard. Like, really, really, really hard. Low level programming with
C is not for everyone (and definitely not for me!). Because I don’t want to provide too much detail,
being a lazy blogger, here’s a step-by-step of what happened:</p>

Research.</li>
Start with low-level programming.</li>
Get a simple blink example to work on an ATmega328.</li>
Great, that works! Try doing stuff over UART/Serial.</li>
Very difficult, but manageable. Try I2C/TWI now?.</li>
Wow, that was awful, and it doesn’t work!.</li>
Repeat steps 1-6 a few more times.</li>
Stumble across orempel/twiboot</a>.</li>
Try to get that to work.</li>
Suprise! It doesn’t :(.</li>
Repeat steps 1-6.</li>
Try to make just a bootloader, see if that can work.</li>
It works, just not for what we need.</li>
Repeat steps 1-6.</li>
Try twiboot in desperation again.</li>
Suprise! It works now. (I needed to send 128 bytes of flash per page at a time, nothing more or
less. Silly me, just read the docs!)</li>
Make a particle library for it.</li>
Done! Eazy-peezy lemon-squeezy.</li>
</ol>
Yeah… those were an awful two weeks. But I’m done now, and you can find the library at the link
above. Don’t confuse it for orempel’s library, though. That’s the actual</em> bootloader.</p>
So if you’re ever in my position, and need something to help you, maybe my work can make your life
easier. Maybe. Or it could make it hell, I dunno how many bugs are in there (but I tried to squash
them all, don’t worry :P).</p>
So I guess the moral of the story is that you should do things the easier way, especially if someone
has done them before, because otherwise you end up wasting weeks of your time and energy getting
nearly nothing done, only for you to find out that someone else did what you tried to do better than
you ever could.</p>
See ya!</p>