From 26ccba082573b74c8151706d05561297ad173969 Mon Sep 17 00:00:00 2001 From: Noah Pendleton <2538614+noahp@users.noreply.github.com> Date: Wed, 15 Apr 2026 15:48:47 -0400 Subject: [PATCH] typos: clean up all typos This currently doesn't run as a lint step, to avoid friction to contributors. It does however run in a pre-commit hook if you `yarn install` setup the javascript deps. --- _posts/2019-05-14-zero-to-main-1.md | 4 +- _posts/2019-06-06-best-firmware-size-tools.md | 2 +- ...019-07-30-bluetooth-low-energy-a-primer.md | 2 +- ...dive-into-arm-cortex-m-debug-interfaces.md | 2 +- ...-how-to-write-a-bootloader-from-scratch.md | 2 +- _posts/2019-09-24-ble-throughput-primer.md | 6 +- ...9-11-12-bootstrapping-libc-with-newlib.md} | 2 +- _posts/2019-11-20-cortex-m-hardfault-debug.md | 2 +- _posts/2020-01-22-i2c-in-a-nutshell.md | 6 +- ...2-04-rust-for-digital-signal-processing.md | 2 +- _posts/2020-04-08-gnu-binutils.md | 6 +- .../2020-05-20-arm-cortexm-with-llvm-clang.md | 2 +- ...0-06-23-device-firmware-update-cookbook.md | 2 +- _posts/2020-07-29-cortex-m-debug-monitor.md | 2 +- ...cure-firmware-updates-with-code-signing.md | 2 +- ...2020-10-06-separating-unique-parameters.md | 2 +- _posts/2020-10-20-advanced-gdb.md | 2 +- _posts/2020-11-04-mcuboot-overview.md | 4 +- ...12-08-seamless-firmware-with-platformio.md | 2 +- ...-15-defensive-and-offensive-programming.md | 4 +- .../2020-12-23-instruction-tracing-mtb-m33.md | 4 +- _posts/2021-01-19-release-versioning.md | 2 +- _posts/2021-02-09-january-2021-roundup.md | 2 +- _posts/2021-07-06-june-2021-roundup.md | 2 +- _posts/2021-12-06-november-2021-roundup.md | 2 +- _posts/2022-01-12-trice.md | 2 +- _posts/2022-06-07-testing-library.md | 2 +- _posts/2022-08-09-ota-delta-updates.md | 2 +- _posts/2023-01-12-dec-2022-roundup.md | 2 +- _posts/2023-04-12-feb-march-2023-roundup.md | 2 +- ...azel-build-system-for-embedded-projects.md | 6 +- ...3-08-23-firmware-encryption-with-python.md | 8 +- _posts/2023-09-20-printf-on-embedded.md | 2 +- _posts/2023-11-29-diving-into-jtag-part1.md | 2 +- _posts/2023-12-20-device-logging.md | 2 +- _posts/2024-06-12-diving-into-jtag-part-5.md | 2 +- ...26-updating-nvidia-jetson-with-memfault.md | 2 +- ...24-12-11-upgrading-from-nrf5-sdk-to-ncs.md | 2 +- ...-02-20-why-sleep-for-is-broken-on-esp32.md | 2 +- _posts/2025-05-02-linux-coredumps-part-2.md | 6 +- _posts/2025-06-20-linux-coredumps-part-3.md | 2 +- _redirects | 1 + _typos.toml | 101 +++++++++++++++++- .../Encrypting-PythonAES/aes_ctr.py | 8 +- ...quitecture.png => ExampleArchitecture.png} | Bin .../{MessgaeCTR.jpg => MessageCTR.jpg} | Bin lefthook.yml | 1 + 47 files changed, 161 insertions(+), 66 deletions(-) rename _posts/{2019-11-12-boostrapping-libc-with-newlib.md => 2019-11-12-bootstrapping-libc-with-newlib.md} (99%) rename img/fwup-encryption/{ExampleArquitecture.png => ExampleArchitecture.png} (100%) rename img/fwup-encryption/{MessgaeCTR.jpg => MessageCTR.jpg} (100%) diff --git a/_posts/2019-05-14-zero-to-main-1.md b/_posts/2019-05-14-zero-to-main-1.md index 90b84524..9acfa749 100644 --- a/_posts/2019-05-14-zero-to-main-1.md +++ b/_posts/2019-05-14-zero-to-main-1.md @@ -130,7 +130,7 @@ francois-mba:zero-to-main francois$ xxd build/minimal/minimal.bin | head 00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ ``` -If I'm reading this correctly, our inital SP is `0x20002000`, and our start +If I'm reading this correctly, our initial SP is `0x20002000`, and our start address pointer is `0x000000c1`. Let's dump our symbols to see which one is at `0x000000c1`. @@ -323,7 +323,7 @@ More complex programs often require a more complicated `Reset_Handler`. For example: 1. Relocatable code must be copied over 2. If our program relies on libc, we must initialize it - _EDIT: Post written!_ - [From Zero to main(): Bootstrapping libc with Newlib]({% post_url 2019-11-12-boostrapping-libc-with-newlib %}) + _EDIT: Post written!_ - [From Zero to main(): Bootstrapping libc with Newlib]({% post_url 2019-11-12-bootstrapping-libc-with-newlib %}) 3. More complex memory layouts can add a few copy / zero loops We'll cover all of them in future posts. But before that, diff --git a/_posts/2019-06-06-best-firmware-size-tools.md b/_posts/2019-06-06-best-firmware-size-tools.md index 51bfa968..ef7624bb 100644 --- a/_posts/2019-06-06-best-firmware-size-tools.md +++ b/_posts/2019-06-06-best-firmware-size-tools.md @@ -53,7 +53,7 @@ $ arm-none-eabi-size build/with-libc.elf So in this program we have: - 10800 bytes of `text`, which is code -- 104 bytes of `data`, which is statically initalized memory +- 104 bytes of `data`, which is statically initialized memory - 8272 bytes of `bss`, which is zero-initialized memory Unfortunately, the output of this tool is a little misleading. You may think diff --git a/_posts/2019-07-30-bluetooth-low-energy-a-primer.md b/_posts/2019-07-30-bluetooth-low-energy-a-primer.md index 4e483d8e..a964cbc8 100644 --- a/_posts/2019-07-30-bluetooth-low-energy-a-primer.md +++ b/_posts/2019-07-30-bluetooth-low-energy-a-primer.md @@ -55,7 +55,7 @@ Every technology has its own benefits and limitations, and BLE is no exception. ### Benefits - Lower power consumption even when compared to other low power technologies. - This is achived by keeping the radio off as much as possible and sending small amounts of data at low transfer speeds. + This is achieved by keeping the radio off as much as possible and sending small amounts of data at low transfer speeds. - No cost to access the official specification documents. With most other wireless protocols and technologies, you would have to be a member of the official group or consortium for that technology in order to access the specification. - Lower cost of modules and chipsets, even when compared to other similar technologies. - Most importantly, its existence in most smartphones in the market. diff --git a/_posts/2019-08-06-a-deep-dive-into-arm-cortex-m-debug-interfaces.md b/_posts/2019-08-06-a-deep-dive-into-arm-cortex-m-debug-interfaces.md index b12707b6..1c4f3e69 100644 --- a/_posts/2019-08-06-a-deep-dive-into-arm-cortex-m-debug-interfaces.md +++ b/_posts/2019-08-06-a-deep-dive-into-arm-cortex-m-debug-interfaces.md @@ -84,7 +84,7 @@ When selecting the software to use, the other item you want to look at is its bo The actual GDB server used is usually based on the debug probe selected. Some of the common choices are: -- **pyOCD**[^10] A Python-based open source implementation compatible wth **CMSIS-DAP** and **ST-Link** debug probes. The project is maintained by ARM. This is my favorite gdbserver at the moment. If you want to understand more about the ARM Coresight internals, reading through the code itself is actually a great reference and being open source the framework can be easily extended to support a variety of use cases. +- **pyOCD**[^10] A Python-based open source implementation compatible with **CMSIS-DAP** and **ST-Link** debug probes. The project is maintained by ARM. This is my favorite gdbserver at the moment. If you want to understand more about the ARM Coresight internals, reading through the code itself is actually a great reference and being open source the framework can be easily extended to support a variety of use cases. - **openOCD**[^11] A C-based open source `gdbserver` implementation for a wide array of debug probes. The project probably supports the widest array of debug probes out of any project available (you can run `openocd -c interface_list` to see) including **FTDI**, **CMSIS-DAP**, **J-Link** and about 17 other adapters. The project dates back to 2005 and while it has support for a wide array of parts I have found it to be a bit flaky to use for projects over the years. - **SEGGER JLinkGDBServer**[^12] A proprietary `gdbserver` distributed as a binary. Has support for an impressive amount of devices. (You can find the list at `/JLinkDevices.xml`). I've found it to be quite reliable for debugging but when there are issues, things can be quite painful to fix without being able to see the source - **texane/stlink**[^13] An open source implementation of the ST-Link Debug Probe protocol. This project is independently maintained and not affiliated with ST. diff --git a/_posts/2019-08-13-how-to-write-a-bootloader-from-scratch.md b/_posts/2019-08-13-how-to-write-a-bootloader-from-scratch.md index 1d682fb4..03d424c2 100644 --- a/_posts/2019-08-13-how-to-write-a-bootloader-from-scratch.md +++ b/_posts/2019-08-13-how-to-write-a-bootloader-from-scratch.md @@ -620,7 +620,7 @@ or at [interrupt@memfault.com](mailto:interrupt@memfault.com). Next time in the series, we'll talk about bootstrapping the C library! -_EDIT: Post written!_ - [Bootstrapping libc with Newlib]({% post_url 2019-11-12-boostrapping-libc-with-newlib %}) +_EDIT: Post written!_ - [Bootstrapping libc with Newlib]({% post_url 2019-11-12-bootstrapping-libc-with-newlib %}) > Interested in learning more device firmware update best practices? [Watch this webinar recording](https://hubs.la/Q02hgRrk0) diff --git a/_posts/2019-09-24-ble-throughput-primer.md b/_posts/2019-09-24-ble-throughput-primer.md index 4f49d7fa..d1af24e9 100644 --- a/_posts/2019-09-24-ble-throughput-primer.md +++ b/_posts/2019-09-24-ble-throughput-primer.md @@ -122,7 +122,7 @@ to fit in one LL packet) but the size can be negotiated via the _Exchange MTU Re Per the Bluetooth Core Specification, the maximum allowed length of an attribute value (the ATT payload) is 512 bytes[^11]. While this technically means the MTU size can be slightly larger than 512 bytes (to -accomodate for the ATT protocol overhead), most bluetooth stacks support a maximum MTU value of 512 bytes. +accommodate for the ATT protocol overhead), most bluetooth stacks support a maximum MTU value of 512 bytes. The packet looks like this: @@ -170,7 +170,7 @@ As part of the 5.0 Bluetooth Core Specification revision, a new feature known as ![]({% img_url ble-throughput/ble-throughput-dple-and-2m-phy.png %}) -We can calculate this throughput and see the modification yields almost a _4x_ improvement over the original maximal raw data speed that could be achived with BLE 4.0: +We can calculate this throughput and see the modification yields almost a _4x_ improvement over the original maximal raw data speed that could be achieved with BLE 4.0: `251 bytes / 1400μs = 179.3 kBytes/sec = ~1.434 Mbps` @@ -241,7 +241,7 @@ Many devices only support a subset of the valid connection parameter range (7.5m > ![]({% img_url ble-throughput/apple-connection-parameters.png %}) -A longer connection event in itself isn't necessarily a problem for throughput. Some devices will send and recieve data for an entire connection event so if you are streaming data continuously the same throughput can be realized even if you are using a 30ms interval instead of a 15ms interval. +A longer connection event in itself isn't necessarily a problem for throughput. Some devices will send and receive data for an entire connection event so if you are streaming data continuously the same throughput can be realized even if you are using a 30ms interval instead of a 15ms interval. What the connection interval _does_ impact is latency. Many higher layer protocols have messages which need to be acknowledged by higher level software components. The longer the connection interval, the longer it will take for these round trips to complete diff --git a/_posts/2019-11-12-boostrapping-libc-with-newlib.md b/_posts/2019-11-12-bootstrapping-libc-with-newlib.md similarity index 99% rename from _posts/2019-11-12-boostrapping-libc-with-newlib.md rename to _posts/2019-11-12-bootstrapping-libc-with-newlib.md index 51524ff1..2ea4e051 100644 --- a/_posts/2019-11-12-boostrapping-libc-with-newlib.md +++ b/_posts/2019-11-12-bootstrapping-libc-with-newlib.md @@ -625,7 +625,7 @@ functions being used by that thread. Some standard library functions depend on global memory which would not make sense to hold in the `_reent` struct. This is especially important when using -`malloc` to allocate memory out of the heap. If mutliple threads try modifying +`malloc` to allocate memory out of the heap. If multiple threads try modifying the heap at the same time, they risk corrupting it. To allow multiple threads to call `malloc`, Newlib provides the `__malloc_lock` diff --git a/_posts/2019-11-20-cortex-m-hardfault-debug.md b/_posts/2019-11-20-cortex-m-hardfault-debug.md index f7d539ee..4d08b076 100644 --- a/_posts/2019-11-20-cortex-m-hardfault-debug.md +++ b/_posts/2019-11-20-cortex-m-hardfault-debug.md @@ -328,7 +328,7 @@ Furthermore, we now have a variable we can read stack info from and a C function #### Instrumenting the code -Many Real Time Operating Systems (**RTOS**) targetting Cortex-M devices will add options to dump +Many Real Time Operating Systems (**RTOS**) targeting Cortex-M devices will add options to dump verbose fault register information to the console upon crash. Some examples include Arm Mbed OS[^2] and Zephyr[^3]. For example, with Zephyr, the `illegal_instruction_execution()` crash looks like: diff --git a/_posts/2020-01-22-i2c-in-a-nutshell.md b/_posts/2020-01-22-i2c-in-a-nutshell.md index b54903f3..85378665 100644 --- a/_posts/2020-01-22-i2c-in-a-nutshell.md +++ b/_posts/2020-01-22-i2c-in-a-nutshell.md @@ -35,7 +35,7 @@ signalling). 2. It supports up to 127 devices on a bus with only two pins. 3. It has transfer rates up to 400Kbps, which is fast enough for many human interfaces as well as fan control, temperature sensing and other low-speed -contol loops. +control loops. 4. Historically, it has been less onerous for manufacturers to include than competing protocols like Maxim's 1-wire protocol[^4]. @@ -242,7 +242,7 @@ device attempts to hold the clock down. ## Debugging I2C -While I2C is a robust and simple protocol, firmware engineers find themslves +While I2C is a robust and simple protocol, firmware engineers find themselves debugging unresponsive devices on most projects. Consider the following scenario: you just received a new board and are doing @@ -408,7 +408,7 @@ below! [^1]: [TotalPhase: 10-bit vs 7-bit I2C](https://www.totalphase.com/support/articles/200349176) [^2]: [Salae: How to Analyze I2C](https://support.saleae.com/tutorials/example-projects/how-to-analyze-i2c) -[^3]: [StackExchange: What happens if I omit the pullup resitors?](https://electronics.stackexchange.com/questions/102611/what-happens-if-i-omit-the-pullup-resistors-on-i2c-line://electronics.stackexchange.com/questions/102611/what-happens-if-i-omit-the-pullup-resistors-on-i2c-lines) +[^3]: [StackExchange: What happens if I omit the pullup resistors?](https://electronics.stackexchange.com/questions/102611/what-happens-if-i-omit-the-pullup-resistors-on-i2c-line://electronics.stackexchange.com/questions/102611/what-happens-if-i-omit-the-pullup-resistors-on-i2c-lines) [^4]: [Wikipedia: 1-Wire](https://en.wikipedia.org/wiki/1-Wire) [^5]: [Wikipedia: SPI](https://en.wikipedia.org/wiki/Serial_Peripheral_Interface) [^6]: [Wikipedia: CAN](https://en.wikipedia.org/wiki/Controller_area_network) diff --git a/_posts/2020-02-04-rust-for-digital-signal-processing.md b/_posts/2020-02-04-rust-for-digital-signal-processing.md index 1066b841..57ae1358 100644 --- a/_posts/2020-02-04-rust-for-digital-signal-processing.md +++ b/_posts/2020-02-04-rust-for-digital-signal-processing.md @@ -126,7 +126,7 @@ As a C programmer, I was tempted to write the Rust code using an imperative style. Instead, I decided to leverage Rust's syntax for functional programming, as it maps neatly to digital signal processing concepts. While this is beyond the scope of this article, I found that using a functional rather than -itterative approach yielded a ~2x improvement in performance in this case. +iterative approach yielded a ~2x improvement in performance in this case. We filled in `src/lib.rs`, the file cargo auto-generated for us. It creates a function `dsp_process_rs` which we will expose to our C code. diff --git a/_posts/2020-04-08-gnu-binutils.md b/_posts/2020-04-08-gnu-binutils.md index d3cb289c..008b7268 100644 --- a/_posts/2020-04-08-gnu-binutils.md +++ b/_posts/2020-04-08-gnu-binutils.md @@ -511,7 +511,7 @@ my_library_function lib_v2.c:6: Version 1 The behavior we observed above is because `ar`, unlike other Binutil commands, _appends_ to a pre-existing file if it exists. With embedded software, since creating a new archive is very fast, I recommend just deleting any pre-existing archive when a new one gets generated. For example, we -achieve this in the Make fule below by adding `rm -f $@` before the `ar` invocation: +achieve this in the Make rule below by adding `rm -f $@` before the `ar` invocation: ```bash $(MYLIB_TARGET): $(MYLIB_OBJ_FILES) @@ -779,7 +779,7 @@ $ arm-none-eabi-readelf -S nrf52_example/build/nrf52.elf | grep debug `objcopy` is most commonly used as the last stage of a build to generate the `.bin` or `.hex` file which can be flashed onto a device. Unlike an operating system where there is a "dynamic loader" that -resolves addresses and loads libaries at runtime, on embedded devices all of the memory locations +resolves addresses and loads libraries at runtime, on embedded devices all of the memory locations are typically resolved at link time. ```bash @@ -824,7 +824,7 @@ arm-none-eabi-nm -S -l my_binary.o - `-a` To show the address which was decoded. This can be useful when decoding multiple addresses at once or using `addr2line` in a batch processing mode. - `-f` To display the function name the address is in -- `-e ` To specify the excutable to decode. (Otherwise, `addr2line` checks for `a.out` in the +- `-e ` To specify the executable to decode. (Otherwise, `addr2line` checks for `a.out` in the working directory and uses that.) #### Example Usage diff --git a/_posts/2020-05-20-arm-cortexm-with-llvm-clang.md b/_posts/2020-05-20-arm-cortexm-with-llvm-clang.md index 3cd66580..241e84d7 100644 --- a/_posts/2020-05-20-arm-cortexm-with-llvm-clang.md +++ b/_posts/2020-05-20-arm-cortexm-with-llvm-clang.md @@ -715,7 +715,7 @@ are responsible for providing locations of the standard libraries in this scenar implemented but Clang makes every effort to match the exact subset required by GCC. Fortunately, for ARM Cortex-M development, the official GNU Arm toolchain[^1] bundles pre-compiled -variants of [Newlib's libc and libm]({% post_url 2019-11-12-boostrapping-libc-with-newlib %}). +variants of [Newlib's libc and libm]({% post_url 2019-11-12-bootstrapping-libc-with-newlib %}). When you compile a project with the GNU Arm toolchain, `libc.a` & `libm.a` from the pre-compiled Newlib as well as GCC's `libgcc.a` will be linked into your project automatically. diff --git a/_posts/2020-06-23-device-firmware-update-cookbook.md b/_posts/2020-06-23-device-firmware-update-cookbook.md index d81c3d67..9234924f 100644 --- a/_posts/2020-06-23-device-firmware-update-cookbook.md +++ b/_posts/2020-06-23-device-firmware-update-cookbook.md @@ -568,7 +568,7 @@ const image_hdr_t *image_get_header(image_slot_t slot) { To validate the image, we compute its CRC and compare it with the value written in the header. This will allow you to catch data corruption or bit errors, and save you some trouble down the line. Note that verifying CRC on boot is not -appropriate for every applicaton, as it can slow down boot significantly. +appropriate for every application, as it can slow down boot significantly. ```c int image_validate(image_slot_t slot, const image_hdr_t *hdr) { diff --git a/_posts/2020-07-29-cortex-m-debug-monitor.md b/_posts/2020-07-29-cortex-m-debug-monitor.md index 00e9fe6c..88173ead 100644 --- a/_posts/2020-07-29-cortex-m-debug-monitor.md +++ b/_posts/2020-07-29-cortex-m-debug-monitor.md @@ -569,7 +569,7 @@ Dump of assembler code for function dummy_function_4: End of assembler dump. ``` -We will install a breakpoint at address `0x270`, so if we single step after that we shold see, `0x272`, +We will install a breakpoint at address `0x270`, so if we single step after that we should see, `0x272`, `0x274` and then a branch to `0x6c0` executed by the processor. ```bash diff --git a/_posts/2020-09-08-secure-firmware-updates-with-code-signing.md b/_posts/2020-09-08-secure-firmware-updates-with-code-signing.md index 896f75f5..1eb1ddc2 100644 --- a/_posts/2020-09-08-secure-firmware-updates-with-code-signing.md +++ b/_posts/2020-09-08-secure-firmware-updates-with-code-signing.md @@ -509,7 +509,7 @@ static void prv_sha256(const void *buf, uint32_t size, uint8_t *hash_out) } ``` -Note that `cf_sha256_update` can be called mutliple times, so if you are +Note that `cf_sha256_update` can be called multiple times, so if you are validating a binary that isn't memory mapped you can calculate the hash iteratively rather than all at once. For example, here's an implementation that reads from a POSIX file: diff --git a/_posts/2020-10-06-separating-unique-parameters.md b/_posts/2020-10-06-separating-unique-parameters.md index a8b80a8a..807837be 100644 --- a/_posts/2020-10-06-separating-unique-parameters.md +++ b/_posts/2020-10-06-separating-unique-parameters.md @@ -110,7 +110,7 @@ them to binaries that can be flashed to the correct addresses. Instead, we settled on creating IHEX files since they exactly meet our requirements, are simple to generate and come with lots of great tooling. -### Building HEX File Programatically +### Building HEX File Programmatically Hex files consist of lines of hexadecimal data, called records, that specify both an address and the data to write at this address. The diff --git a/_posts/2020-10-20-advanced-gdb.md b/_posts/2020-10-20-advanced-gdb.md index 9fc66557..2762d143 100644 --- a/_posts/2020-10-20-advanced-gdb.md +++ b/_posts/2020-10-20-advanced-gdb.md @@ -468,7 +468,7 @@ end document xxd Runs xxd on a memory ADDR and LENGTH - xxd ADDR LENTH + xxd ADDR LENGTH end ``` diff --git a/_posts/2020-11-04-mcuboot-overview.md b/_posts/2020-11-04-mcuboot-overview.md index 4c00fc15..043ccc53 100644 --- a/_posts/2020-11-04-mcuboot-overview.md +++ b/_posts/2020-11-04-mcuboot-overview.md @@ -331,7 +331,7 @@ Compile a new application with some kind of change so you can easily confirm it --- a/example/mcuboot/application/src/main.c +++ b/example/mcuboot/application/src/main.c @@ -39,7 +39,8 @@ int main(void) { - // succesfully completed init, mark image as stable + // successfully completed init, mark image as stable boot_set_confirmed(); EXAMPLE_LOG("==Main Application Booted=="); @@ -679,7 +679,7 @@ make 2>&1 | rg ": undefined.*" -o | sort -u Examining the missing symbols we have three classes: -1. Missing Newlib platform dependency implementations. (We've seen these before in [our post about porting newlib]({% post_url 2019-11-12-boostrapping-libc-with-newlib %})). +1. Missing Newlib platform dependency implementations. (We've seen these before in [our post about porting newlib]({% post_url 2019-11-12-bootstrapping-libc-with-newlib %})). 2. The `tc_sha256_*` are missing implementations for the Tincrypt backend we are using. 3. The `flash_*` dependency functions defined in `flash_map_backend.h` need to be filled in. diff --git a/_posts/2020-12-08-seamless-firmware-with-platformio.md b/_posts/2020-12-08-seamless-firmware-with-platformio.md index ffdee4a3..7472cf74 100644 --- a/_posts/2020-12-08-seamless-firmware-with-platformio.md +++ b/_posts/2020-12-08-seamless-firmware-with-platformio.md @@ -34,7 +34,7 @@ embedded that is the best I've seen yet. I hope you will give it a whirl! ## What is PlatformIO? -PlatformIO is a set of open source tools targetted at professional embedded +PlatformIO is a set of open source tools targeted at professional embedded developers. Foremost of those tools is the PlatformIO Plugin for VSCode which is used by hundreds of thousands of embedded developers to create, compile, debug, and test embedded projects. diff --git a/_posts/2020-12-15-defensive-and-offensive-programming.md b/_posts/2020-12-15-defensive-and-offensive-programming.md index ea9eca47..a2bd9993 100644 --- a/_posts/2020-12-15-defensive-and-offensive-programming.md +++ b/_posts/2020-12-15-defensive-and-offensive-programming.md @@ -44,7 +44,7 @@ track down those 1 in 1,000-hour bugs, efficiently root cause them, and keep your end-users happy. And, as a bonus, keep your sanity. > To learn more about offensive and defensive programming best practices and ask -> me questions live, register for our [webinar on Febraury 24, 2022](https://hubs.la/Q013SXmN0). +> me questions live, register for our [webinar on February 24, 2022](https://hubs.la/Q013SXmN0). {% include newsletter.html %} @@ -581,7 +581,7 @@ I'd love to hear about any other strategies that you all take to surface bugs that are hidden in your firmware! Come find me in the [Interrupt Slack](https://interrupt-slack.herokuapp.com/). -> Interested in learning more offensive and defensive programming best practices? Register for our [webinar on Febraury 24, 2022](https://hubs.la/Q013SXmN0). +> Interested in learning more offensive and defensive programming best practices? Register for our [webinar on February 24, 2022](https://hubs.la/Q013SXmN0). diff --git a/_posts/2020-12-23-instruction-tracing-mtb-m33.md b/_posts/2020-12-23-instruction-tracing-mtb-m33.md index e89f2050..4609b56e 100644 --- a/_posts/2020-12-23-instruction-tracing-mtb-m33.md +++ b/_posts/2020-12-23-instruction-tracing-mtb-m33.md @@ -397,7 +397,7 @@ infinite_loop () at ./main.c:157 157 __asm("bkpt 6"); ``` -We can dump the dissasembly of this loop to get a sense of what we expect to be recorded by the MTB: +We can dump the disassembly of this loop to get a sense of what we expect to be recorded by the MTB: ``` (gdb) disassemble infinite_loop @@ -450,7 +450,7 @@ Begin Trace Session Neat, what we are looking at here is a trace of the entire instruction flow up to the breakpoint. -If we want to view the exact instructions executed we can take the destination address from the previous packet and the source from the next packet and dissasemble the range with gdb. We see the `0x20000348` we identified above has been recorded in the trace. +If we want to view the exact instructions executed we can take the destination address from the previous packet and the source from the next packet and disassemble the range with gdb. We see the `0x20000348` we identified above has been recorded in the trace. For example for the first `D` -> `S` transition we have above: diff --git a/_posts/2021-01-19-release-versioning.md b/_posts/2021-01-19-release-versioning.md index 8174006b..8ff73178 100644 --- a/_posts/2021-01-19-release-versioning.md +++ b/_posts/2021-01-19-release-versioning.md @@ -61,7 +61,7 @@ Example: 1.0.0 → 2.0.0 For most firmware projects, the MAJOR field might *never* be incremented. If I'm writing firmware for an nRF52, and it is the only MCU in my hardware product, it doesn't have to interact or communicate with many other pieces of software or hardware, so there shouldn't be any incompatible API changes! -There is one occassion where I would seriously consider incrementing the MAJOR field, and that is when our firmware becomes **incompatible with a version of itself**. Let me explain. +There is one occasion where I would seriously consider incrementing the MAJOR field, and that is when our firmware becomes **incompatible with a version of itself**. Let me explain. Normal software packages can be updated at any time, with almost no repercussions. If incompatibility arises, just revert the change and continue. However, on firmware devices, the firmware updates itself. If there is an incompatibility, it might require a re-install, a factory reset, or in the worst of cases, the device might be bricked! diff --git a/_posts/2021-02-09-january-2021-roundup.md b/_posts/2021-02-09-january-2021-roundup.md index b5274b52..10358779 100644 --- a/_posts/2021-02-09-january-2021-roundup.md +++ b/_posts/2021-02-09-january-2021-roundup.md @@ -22,7 +22,7 @@ Title says it all. - [A 27th IOCCC Winner - Best of show - abuse of libc](https://www.ioccc.org/2020/carlini/index.html) by Nicholas Carlini
TIL that `printf` is Turing complete. In this IOCCC entry, the author implements Tic-Tac-Toe in a single `printf` statement! - [Better Embedded System Software e-Book & Paperback](https://betterembsw.blogspot.com/2021/02/better-embedded-system-software-e-book.html?m=1) by Phil Koopman
-Phil has updated his popular embedded systems book with what he calls a v1.1 edition. The hardcover was prohibitivly expensive for some (but worth it), and this new version comes in both a paperback book and digital version, costing $25 and $10 respectively, which is a steal. The group in the Interrupt Slack channel say it's a worthwhile purchase for hte new price. +Phil has updated his popular embedded systems book with what he calls a v1.1 edition. The hardcover was prohibitivly expensive for some (but worth it), and this new version comes in both a paperback book and digital version, costing $25 and $10 respectively, which is a steal. The group in the Interrupt Slack channel say it's a worthwhile purchase for the new price. - [Thoroughly Commented Cortex M0+ Micro Trace Buffer interface (Twitter)](https://twitter.com/theavalkyrie/status/1353925165072207872?s=21) by Stargirl
The Micro Trace Buffer on the Cortex-M0+ (and the ETB) are some notoriously difficult modules to get set up, and they are rarely included by chip vendors in a package. A few of Stargirl's hardware products under the brand [Winterbloom](https://winterbloom.com/) use the SAMD21, which *does* include the MTB! In the Tweet above, she links to the MTB initialization code in the firmware. - [Linux and Zephyr, Sitting in a tree (slides)](http://christopher.biggs.id.au/talk/2021-01-24-linux-zephyr/) by Christopher Biggs
diff --git a/_posts/2021-07-06-june-2021-roundup.md b/_posts/2021-07-06-june-2021-roundup.md index ede0a183..e42993be 100644 --- a/_posts/2021-07-06-june-2021-roundup.md +++ b/_posts/2021-07-06-june-2021-roundup.md @@ -31,7 +31,7 @@ reading in the comments or [on the Interrupt Slack](https://interrupt-slack.hero - [Benchmarking OpenCV on STM32 MCUs | Embedded.com](https://www.embedded.com/benchmarking-opencv-on-stm32-mcus/)
OpenCV is usually run on higher performance MCU's and CPU's, but here, it's running on an STM32F7! The article claims that the device can detect (not comprehend) a QR code in 3 seconds, and do face detection in 10-15 seconds. - [Reverse engineering and fixing a bug in the firmware of a "ThinkPad Compact USB Keyboard with TrackPoint" | Magic Smoke](https://hohlerde.org/rauch/en/elektronik/projekte/tpkbd-fix/) by Dennis Schneider
- I love this so much. Dennis was frustrated by a hardware quirk on his Lenovo keyboard which triggered a click at an inapropriate time while scrolling. His solution? Dump the firmware, print out and understand the assembly, modify the firmware, and load it. Problem solved! + I love this so much. Dennis was frustrated by a hardware quirk on his Lenovo keyboard which triggered a click at an inappropriate time while scrolling. His solution? Dump the firmware, print out and understand the assembly, modify the firmware, and load it. Problem solved! ## Tools & Projects diff --git a/_posts/2021-12-06-november-2021-roundup.md b/_posts/2021-12-06-november-2021-roundup.md index de6330c7..1edf9002 100644 --- a/_posts/2021-12-06-november-2021-roundup.md +++ b/_posts/2021-12-06-november-2021-roundup.md @@ -62,7 +62,7 @@ reading in the comments or [on the Interrupt Slack](https://interrupt-slack.hero ## Tools & Projects - [elfshaker/elfshaker: elfshaker stores binary objects efficiently](https://github.com/elfshaker/elfshaker)
- An incredibly neat tool that takes many binary files and compresses them effeciently in a custom format. Since binary ELF files don't change often with rebuilds, and because normal compression like gzip doesn't work well on binaries, this tool can produce amazing results. They claim a 0.01% compression ratio when it's snapshotting many binaries at once! To prove their point, they also have [elfshaker/manyclangs](https://github.com/elfshaker/manyclangs), which is a GitHub repo of all LLVM builds ever, stored in 100MB. Impressive! + An incredibly neat tool that takes many binary files and compresses them efficiently in a custom format. Since binary ELF files don't change often with rebuilds, and because normal compression like gzip doesn't work well on binaries, this tool can produce amazing results. They claim a 0.01% compression ratio when it's snapshotting many binaries at once! To prove their point, they also have [elfshaker/manyclangs](https://github.com/elfshaker/manyclangs), which is a GitHub repo of all LLVM builds ever, stored in 100MB. Impressive! - [nadavrot/memset_benchmark](https://github.com/nadavrot/memset_benchmark)
`memcpy` and `memset` implements which outperform the folly and glibc versions. - [Dirbaio/rzcobs](https://github.com/dirbaio/rzcobs)
diff --git a/_posts/2022-01-12-trice.md b/_posts/2022-01-12-trice.md index 8eb12723..adea42f7 100644 --- a/_posts/2022-01-12-trice.md +++ b/_posts/2022-01-12-trice.md @@ -78,7 +78,7 @@ During runtime, the PC **trice** tool receives everything that happened in the l ![]({% img_url trice/triceCOBSBlockDiagram.svg %}) -The **trice** tool runs in the background allowing the developer to focus on programming tasks. Once an ID is generated from a string, it keeps the same ID unless the _Trice_ is changed. If for example the format string gets changed into `"msg: %d Celcius\n"`, a new ID is inserted automatically and the reference list gets extended. Obsolete IDs are kept inside the [**T**rice **I**D **L**ist](https://github.com/rokath/trice/tree/master/til.json) (`til.json`) for compatibility with older firmware versions. It could be possible when merging code, an **ID** is used twice for different format strings. In that case, the **ID** inside the reference list wins and the additional source gets patched with a new **ID**. This may be unwanted, but patching is avoidable with proper [ID management](https://github.com/rokath/trice/tree/master/docs/TriceIDManagement.md). The reference list should be kept under source code control. +The **trice** tool runs in the background allowing the developer to focus on programming tasks. Once an ID is generated from a string, it keeps the same ID unless the _Trice_ is changed. If for example the format string gets changed into `"msg: %d Celsius\n"`, a new ID is inserted automatically and the reference list gets extended. Obsolete IDs are kept inside the [**T**rice **I**D **L**ist](https://github.com/rokath/trice/tree/master/til.json) (`til.json`) for compatibility with older firmware versions. It could be possible when merging code, an **ID** is used twice for different format strings. In that case, the **ID** inside the reference list wins and the additional source gets patched with a new **ID**. This may be unwanted, but patching is avoidable with proper [ID management](https://github.com/rokath/trice/tree/master/docs/TriceIDManagement.md). The reference list should be kept under source code control. ## _Trice_ features diff --git a/_posts/2022-06-07-testing-library.md b/_posts/2022-06-07-testing-library.md index 73bfe4b3..d8d7dedc 100644 --- a/_posts/2022-06-07-testing-library.md +++ b/_posts/2022-06-07-testing-library.md @@ -222,7 +222,7 @@ Once the test is executed (the controller tells the reactor to execute it), it i The testing code should use the record to get any data from the controller, collect any data during the test, and primarily, provide information whenever the test failed or succeeded. In the example, you can see the usage of all the primitives: - - `rec.get_arg("product_id")` tells the reactor to ask the controller for an argument with key `product_id` and retreive it as integer type + - `rec.get_arg("product_id")` tells the reactor to ask the controller for an argument with key `product_id` and retrieve it as integer type - `rec.expect( product_id < MAX_PRODUCTS_N )` is a form checking properties in the test - if `false` is passed to the `expect(bool)` method the test is marked as failed. - `rec.collect("released: ", product_id )` collects the data `product_id` with key `released: ` and sends it to the controller. diff --git a/_posts/2022-08-09-ota-delta-updates.md b/_posts/2022-08-09-ota-delta-updates.md index bb4f1c93..263a5dbe 100644 --- a/_posts/2022-08-09-ota-delta-updates.md +++ b/_posts/2022-08-09-ota-delta-updates.md @@ -495,7 +495,7 @@ janpatch_ctx ctx = { }; ``` -Finally, we need to invoke the `janpatch` method itself. It acccepts three +Finally, we need to invoke the `janpatch` method itself. It accepts three `JANPATCH_STREAM`: - `source`, here that is our App image in slot 2. diff --git a/_posts/2023-01-12-dec-2022-roundup.md b/_posts/2023-01-12-dec-2022-roundup.md index 164a79f4..7bd12d68 100644 --- a/_posts/2023-01-12-dec-2022-roundup.md +++ b/_posts/2023-01-12-dec-2022-roundup.md @@ -53,7 +53,7 @@ From Mitch Johnson on the Interrupt Slack, a new Bluetooth LE standard extension Teaching the basics of embedded programming in Ada. If you find yourself programming an embedded device in Ada, please reach out! I'm very curious to hear your story. - [**What is zchunk?**](https://www.jdieter.net/posts/2018/05/31/what-is-zchunk/)
-An implementation of a delta-update system similar in appication to zsync and casync but with some interesting design choices that seem quite nice! - Noah +An implementation of a delta-update system similar in application to zsync and casync but with some interesting design choices that seem quite nice! - Noah - [**Parsing Protobuf at 2+GB/s: How I Learned To Love Tail Calls in C**](https://blog.reverberate.org/2021/04/21/musttail-efficient-interpreters.html)
Interesting article about using tail-calls for performance. - Noah diff --git a/_posts/2023-04-12-feb-march-2023-roundup.md b/_posts/2023-04-12-feb-march-2023-roundup.md index 7e3a1e2e..8f2896b0 100644 --- a/_posts/2023-04-12-feb-march-2023-roundup.md +++ b/_posts/2023-04-12-feb-march-2023-roundup.md @@ -22,7 +22,7 @@ Team Memfault would be thrilled to host you at Workbar Boston downtown for food, ## Articles & Learning - [**Interrupt Panel Discussion - OTA Updates & Fleet Management at Scale**](https://go.memfault.com/ota-updates-fleet-management-at-scale)
-David Shoemaker (Tesla), Phillip Johnston (Embedded Artistry), Eric (Memfault), Noah (Memfault) all talk about how each of them think about peforming OTA for hardware devices. Need a podcast of sorts to listen to while writing your new OTA code? This is the one. +David Shoemaker (Tesla), Phillip Johnston (Embedded Artistry), Eric (Memfault), Noah (Memfault) all talk about how each of them think about performing OTA for hardware devices. Need a podcast of sorts to listen to while writing your new OTA code? This is the one. - [**Utilizing Memfault to Debug Your Embedded Devices**](https://go.memfault.com/utilizing-memfault-debug-your-embedded-devices)
Eric and Noah from Memfault cover how to use Memfault to debug firmware, both while it's connected to your local computer using JTAG and remotely using Memfault. diff --git a/_posts/2023-05-30-bazel-build-system-for-embedded-projects.md b/_posts/2023-05-30-bazel-build-system-for-embedded-projects.md index eacaf138..8d78f9a1 100644 --- a/_posts/2023-05-30-bazel-build-system-for-embedded-projects.md +++ b/_posts/2023-05-30-bazel-build-system-for-embedded-projects.md @@ -42,7 +42,7 @@ Building a target is done as follows: ```bash bazel build //: ``` -Where `` is the path of the package to be built and `` specifies one or more targets. For example `bazel build //my_dir:hello`, will build the target named `hello`, within the directory `my_dir`, or `bazel build //my_dir/...` will build all targets within the directory `my_dir`. Various declinations of this syntax make it less verbose, for example, the leading `//` can be omitted, and if the target name is the same as the package name, it can also be omited. +Where `` is the path of the package to be built and `` specifies one or more targets. For example `bazel build //my_dir:hello`, will build the target named `hello`, within the directory `my_dir`, or `bazel build //my_dir/...` will build all targets within the directory `my_dir`. Various declinations of this syntax make it less verbose, for example, the leading `//` can be omitted, and if the target name is the same as the package name, it can also be omitted. Similarly, all tests targets can be tested with: ```bash @@ -58,12 +58,12 @@ An executable target is any Bazel rule that can be executed, so it also includes Note that running `bazel test` or `bazel run` will also run `bazel build` if the target was not built or if any of the input files of the target have been altered. -Flags can also be used to change the behavior of a command. These flags can be passed as command line arguments, such as `bazel test //:my_target --runs_per_test=10` to execute a specific test 10 times, or `bazel build /:my_trarget --platforms=//platforms:esp32` to cross-compile a target for esp32. +Flags can also be used to change the behavior of a command. These flags can be passed as command line arguments, such as `bazel test //:my_target --runs_per_test=10` to execute a specific test 10 times, or `bazel build /:my_target --platforms=//platforms:esp32` to cross-compile a target for esp32. These flags can be combined and can add up to a very verbose command line which makes it difficult to remember, type or even share. That is where the `.bazelrc` file comes in handy. Here is an example of a `.bazelrc` file: ```bash -# All options comming from this file will be announced on the terminal. +# All options coming from this file will be announced on the terminal. common --announce_rc # If the file `.bazelrc.local`, exists it will be imported. diff --git a/_posts/2023-08-23-firmware-encryption-with-python.md b/_posts/2023-08-23-firmware-encryption-with-python.md index f892eceb..4895d634 100644 --- a/_posts/2023-08-23-firmware-encryption-with-python.md +++ b/_posts/2023-08-23-firmware-encryption-with-python.md @@ -246,7 +246,7 @@ def main(): PlainFirmware = BinaryFile(sys.argv[1],'rb') CipherFirmware = BinaryFile(sys.argv[2],'wb') - CrytoFirmware = EncryptionCTR(mykey,myiv) + CryptoFirmware = EncryptionCTR(mykey,myiv) bytes_remaining = 0 bytes_so_far_cryted = 0 BinaryFileSize = PlainFirmware.SizeFile() @@ -254,9 +254,9 @@ def main(): print("Bytes to encrypt :{}", bytes_remaining ) while(bytes_remaining): Plainbytes = PlainFirmware.ReadFile(BYTES_READ) - PlainbytesLittle = CrytoFirmware.SwapLittleEndian(Plainbytes) - Cipherbytes = CrytoFirmware.EncryptCtr(PlainbytesLittle) - CipherbytesLittle = CrytoFirmware.SwapLittleEndian(Cipherbytes) + PlainbytesLittle = CryptoFirmware.SwapLittleEndian(Plainbytes) + Cipherbytes = CryptoFirmware.EncryptCtr(PlainbytesLittle) + CipherbytesLittle = CryptoFirmware.SwapLittleEndian(Cipherbytes) CipherFirmware.WriteFile(CipherbytesLittle) print( PlainbytesLittle ) print( CipherbytesLittle ) diff --git a/_posts/2023-09-20-printf-on-embedded.md b/_posts/2023-09-20-printf-on-embedded.md index 54d1a9c3..8099b4a6 100644 --- a/_posts/2023-09-20-printf-on-embedded.md +++ b/_posts/2023-09-20-printf-on-embedded.md @@ -557,7 +557,7 @@ either in the comments here or in the Interrupt community Slack! - [Interrupt: Introduction to ARM Semihosting]({% post_url 2021-02-16-arm-semihosting %}) -- [Interrupt: From Zero to main(): Bootstrapping libc with Newlib]({% post_url 2019-11-12-boostrapping-libc-with-newlib %}) +- [Interrupt: From Zero to main(): Bootstrapping libc with Newlib]({% post_url 2019-11-12-bootstrapping-libc-with-newlib %}) - [libc `setvbuf()` stdlib reference](http://www.cplusplus.com/reference/cstdio/setvbuf/) - [Newlib `reent.h` header](https://github.com/bminor/newlib/blob/6226bad0eafe762b811c62d1dc096bc0858b0d1a/newlib/libc/include/reent.h) - [Reentrancy in Newlib](https://www.codeinsideout.com/blog/freertos/reentrant/) diff --git a/_posts/2023-11-29-diving-into-jtag-part1.md b/_posts/2023-11-29-diving-into-jtag-part1.md index 80323927..f4c16120 100644 --- a/_posts/2023-11-29-diving-into-jtag-part1.md +++ b/_posts/2023-11-29-diving-into-jtag-part1.md @@ -171,7 +171,7 @@ Let's describe the most important states. But since `IR` path and DR path have i - **Capture-DR** — In this state, there is a parallel loading of the value stored in the selected DR register into the shift register if you follow the Select-DR-Scan state branch and loading of a special pattern if we follow the Select-IR-Scan state path, the value 0x01 is usually selected as the pattern.

- DR register during catpure-DR state + DR register during capture-DR state

- **Shift-DR** — register shifts data from `TDI` one step forward `TDO`. The Shift-DR and Shift-IR states are the main states for serial-loading data into either data registers or the instruction register. diff --git a/_posts/2023-12-20-device-logging.md b/_posts/2023-12-20-device-logging.md index c1b553a4..8fb85c65 100644 --- a/_posts/2023-12-20-device-logging.md +++ b/_posts/2023-12-20-device-logging.md @@ -27,7 +27,7 @@ As is common in embedded development, there are many interesting decisions to be One of the fundamental constraints to work around with device logging is how much disk space to allocate just for logging. Unlike on servers where the log cache is basically infinite (and you can often pay more for the storage), most logging systems on hardware will reserve a fixed amount of disk space in the form of a rotating buffer of logs. When you log past the limit, the logs in the oldest buffer gets written over. -The amount of disk space chosen greatly influences logging — it affects how verbose your logs can be, how long your logs are retained, what information you'll want prioritize logging, how you'll store the logs, and more. You’ll want to choose the maximum amount of space you can afford, where the logs you get back contain enough useful information at the timeframe of the incident. But you'll also want to change how you log to accomodate for the amount of space, such as using an abbreviated short form instead of full words. +The amount of disk space chosen greatly influences logging — it affects how verbose your logs can be, how long your logs are retained, what information you'll want prioritize logging, how you'll store the logs, and more. You’ll want to choose the maximum amount of space you can afford, where the logs you get back contain enough useful information at the timeframe of the incident. But you'll also want to change how you log to accommodate for the amount of space, such as using an abbreviated short form instead of full words. I've been lucky in that embedded Android devices are generally not very disk space constrained, so I’ve had the benefit of having 10s of MBs of logs to store (and comb) through. But even so, that would only constitute maybe 2-3 hours of logs, depending on how busy the device was, and there was a constant trade-off with how much information was being logged. diff --git a/_posts/2024-06-12-diving-into-jtag-part-5.md b/_posts/2024-06-12-diving-into-jtag-part-5.md index ac5b151f..b0b52404 100644 --- a/_posts/2024-06-12-diving-into-jtag-part-5.md +++ b/_posts/2024-06-12-diving-into-jtag-part-5.md @@ -263,4 +263,4 @@ JTAG interface and also ways to bypass these restrictions. ## Links - [TopJTAG Probe Official Site](http://www.topjtag.com/probe/) -- [Segger Offical Site](https://www.segger.com/) +- [Segger Official Site](https://www.segger.com/) diff --git a/_posts/2024-06-26-updating-nvidia-jetson-with-memfault.md b/_posts/2024-06-26-updating-nvidia-jetson-with-memfault.md index 04272274..d1bd1e17 100644 --- a/_posts/2024-06-26-updating-nvidia-jetson-with-memfault.md +++ b/_posts/2024-06-26-updating-nvidia-jetson-with-memfault.md @@ -258,7 +258,7 @@ $ sudo -E ROOTFS_AB=1 ./tools/ota_tools/version_upgrade/l4t_generate_ota_package This will generate the `bootloader/jetson-orin-nano-devkit/ota_payload_package.tar.gz` file. -Our `update-instaler` also needs the OTA tools so we will include them in each release. +Our `update-installer` also needs the OTA tools so we will include them in each release. ```bash $ cd ~/nvidia/Linux_for_Tegra/bootloader/jetson-orin-nano-devkit diff --git a/_posts/2024-12-11-upgrading-from-nrf5-sdk-to-ncs.md b/_posts/2024-12-11-upgrading-from-nrf5-sdk-to-ncs.md index a4d549fd..a9aeb46b 100644 --- a/_posts/2024-12-11-upgrading-from-nrf5-sdk-to-ncs.md +++ b/_posts/2024-12-11-upgrading-from-nrf5-sdk-to-ncs.md @@ -405,7 +405,7 @@ void service_changed_work_handle(struct k_work *item) { int err; static struct bt_gatt_indicate_params indicate_params; - /* Harcode the attribute handle for SC characteristic from nRF5 SDK application (12 in this + /* Hardcode the attribute handle for SC characteristic from nRF5 SDK application (12 in this * case). CONFIG_BT_GATT_ENFORCE_SUBSCRIPTION must be disabled in project configuration to * allow the indication to be sent, as the Zephyr host has know way of knowing if the client * was subscribed to this characteristic. diff --git a/_posts/2025-02-20-why-sleep-for-is-broken-on-esp32.md b/_posts/2025-02-20-why-sleep-for-is-broken-on-esp32.md index 82e3a9f0..aeae98fb 100644 --- a/_posts/2025-02-20-why-sleep-for-is-broken-on-esp32.md +++ b/_posts/2025-02-20-why-sleep-for-is-broken-on-esp32.md @@ -626,7 +626,7 @@ custom `sleep_for()` to busy wait or to yield: enum class SleepStrategy { Default, // Platform decides when to use busy wait vs. yield PreciseBusyWait, // Busy wait, which is usually very precise - EfficientYield // Efficently yield to other threads, but will often sleep longer than specified + EfficientYield // Efficiently yield to other threads, but will often sleep longer than specified }; template diff --git a/_posts/2025-05-02-linux-coredumps-part-2.md b/_posts/2025-05-02-linux-coredumps-part-2.md index 630abef7..74355c4e 100644 --- a/_posts/2025-05-02-linux-coredumps-part-2.md +++ b/_posts/2025-05-02-linux-coredumps-part-2.md @@ -51,7 +51,7 @@ slim coredump: - Remove heap allocations - Capture metadata needed for debuggers. -By fullfilling the above requirements, we'll have a coredump that stripped down +By fulfilling the above requirements, we'll have a coredump that stripped down to just the essentials. This does, however, have two major tradeoffs. For one, any heap-allocated values on the stack will not be resolved if they're on the stack, and obviously, we will not be able to look at heap-allocated values at @@ -126,7 +126,7 @@ GDB, however, it wouldn't work. That's because we're missing some vital bits of debug information. Let's take a look at what these sections are, and how we can identify them. -### `r_debug` - Debug Rendevous Structure +### `r_debug` - Debug Rendezvous Structure Dynamic linking allows programs to call code from shared libraries on the system. For example, this can allow a single `libopenssl` binary to handle @@ -144,7 +144,7 @@ program. You can probably already see how this presents a problem for us. If the address is randomized at every load, how do we translate the fixed address in the debug info to the random address at load time? -This is where the `r_debug`[^r_debug], or debug rendevous structure comes in. +This is where the `r_debug`[^r_debug], or debug rendezvous structure comes in. While it has many functions, the main reason we need it here is the mapping it provides from compile time address to runtime address. Below, we can see the layout of the `r_debug` structure: diff --git a/_posts/2025-06-20-linux-coredumps-part-3.md b/_posts/2025-06-20-linux-coredumps-part-3.md index f3baa065..c98bacac 100644 --- a/_posts/2025-06-20-linux-coredumps-part-3.md +++ b/_posts/2025-06-20-linux-coredumps-part-3.md @@ -287,7 +287,7 @@ the same instructions we previously saw in our `CIE`. Note that our total set of instructions are the ones present in the `CIE` in addition to those defined in the `FDE`. -#### Cannonical Frame Address (`CFA`) +#### Canonical Frame Address (`CFA`) Alright, we're almost done defining acronyms, I promise! You may have noticed `CFA` mentioned in all of our unwind rules defined in both the `CIE` and `FDE`. diff --git a/_redirects b/_redirects index 22547e10..ee4a04a1 100644 --- a/_redirects +++ b/_redirects @@ -5,6 +5,7 @@ /blog/swig-for-c-and-lua-copy /blog/swig-for-c-and-lua /blog/drafting-a-c-dev-environment /blog/a-modern-c-dev-env /blog/mcu-periphral-forwarding /blog/mcu-peripheral-forwarding +/blog/boostrapping-libc-with-newlib /blog/bootstrapping-libc-with-newlib /blog/authors/* /authors/:splat diff --git a/_typos.toml b/_typos.toml index f8c33a20..a75649eb 100644 --- a/_typos.toml +++ b/_typos.toml @@ -1,12 +1,105 @@ # See config documentation here: # https://github.com/crate-ci/typos/blob/master/docs/reference.md + [default.extend-words] +# "preemptable" is a valid alternate spelling of "preemptible" in CS contexts +preemptable = "preemptable" [default] -# extend-ignore-re list operates on sequences, not identifiers, so we can -# have very targeted ignores -extend-ignore-re = [] +# extend-ignore-re matches against raw text, so patterns can target specific +# contexts rather than blanket-ignoring a word everywhere. +extend-ignore-re = [ + # ser = serial.Serial(...) / ser = Serial(...) — Python serial port variable + # ser.readline() / ser, ser) — serial port used in calls and as argument + # ser2net — tool name + # ser-mk — GitHub username in author data + "ser\\s*=\\s*[Ss]erial|\\bser[.,\\s()=]|ser2net|ser-mk", + + # rsource "..." — Zephyr Kconfig file-include directive + "rsource\\s+\"", + + # FP_COMPn, DWT_COMPn — ARM Cortex-M register names with n-index suffix + # DWT_FUNCTIONn — same pattern, covers FUNCTIO false positive + "COMPn\\b", + "FUNCTIONn\\b", + + # LFS_O_WRONLY, O_WRONLY — standard POSIX/littlefs file-open flag + "O_WRONLY", + + # .rela.dyn, .rela.plt — ELF relocation section names + "\\.rela\\.", + + # [**T**rice **I**D **L**ist] — markdown bold-letter formatting of "List" + # produces bare "ist" as a token + "\\*\\*L\\*\\*ist", + + # EXTI.fpr(...) — STM32 EXTI falling-pending register + "\\.fpr\\(", + + # RTOSs, RTOSes — plural of RTOS + "RTOSs\\b|RTOSes\\b", + + "000000ba g F .text 00000006 HardFault_Handler", + + # ded7 1b8d ... — 4-char hex groups in memory dump output; require at least + # one digit to avoid matching prose words like "dead", "cafe", "face" + # ue.. — ASCII column in xxd-style hex dump + # "\\b(?:[0-9][0-9a-f]{3}|[0-9a-f][0-9][0-9a-f]{2}|[0-9a-f]{2}[0-9][0-9a-f]|[0-9a-f]{3}[0-9])\\b", + "00000060: ded7 1b8d ffe0 5356 61e7 847a 0000 0000", + "2730 75650000 41737365 72742069 6e206061 ue..Assert in", + + # DEVICE_DT_GET_2nd, DT_DRV_INST_2nd — Zephyr DT macro ordinal suffix + "_2nd\\b", + + # System on Module (SOM) — standard embedded acronym + "\\(SOM\\)", + + # 1NCE — IoT connectivity provider name + "1NCE", + + # SleepStrategy strat — C++ parameter variable in sleep_for code example + "SleepStrategy\\s+strat|strat\\s*[=!]=", + + # "is datas" — GDB info files output showing a section type + "is datas\\b", + + # pre-empted — valid hyphenated form + "pre-empted", + + # author: mabe — author shortname slug in post frontmatter + "author: mabe", + + # "Nothin' but a J Thang" — deliberate informal song-title spelling + "Nothin'", + + # Embedd — company name (embedd.it startup) + # embedd.it / embedd.jpg — URL and image references + # [^embedd] — footnote reference + "Embedd\\b|embedd\\.|\\^embedd", + + # je ne sais quoi — French phrase + "ne sais", + + # .debug_aranges — DWARF debug section name + "debug_aranges", + + # 899ede2be378 — Medium article URL hash + "899ede2be378", +] [files] # list of files to exclude -extend-exclude = [] +extend-exclude = [ + "example/", + "misc/", + # Non-prose directories: images, stylesheets, structured data + "img/", + "_sass/", + "_data/", + # Heavy use of OpenThread API prefix (ot/OT) throughout + "_posts/2026-03-24-matter-internet-connectivity.md", + # AddressInterceptor (ADIN) LLVM pass — adin/ADIN pervades the whole post + "_posts/2023-10-11-mcu-peripheral-forwarding.md", + # LTE User Equipment (UE) acronym used throughout + "_posts/2023-12-13-lte-and-iot.md", +] diff --git a/example/fwup-encryption/Encrypting-PythonAES/aes_ctr.py b/example/fwup-encryption/Encrypting-PythonAES/aes_ctr.py index 10c95806..efebd414 100644 --- a/example/fwup-encryption/Encrypting-PythonAES/aes_ctr.py +++ b/example/fwup-encryption/Encrypting-PythonAES/aes_ctr.py @@ -58,7 +58,7 @@ def main(): PlainFirmware = BinaryFile(sys.argv[1],'rb') CipherFirmware = BinaryFile(sys.argv[2],'wb') - CrytoFirmware = EncryptionCTR(mykey,myiv) + CryptoFirmware = EncryptionCTR(mykey,myiv) bytes_remaining = 0 bytes_so_far_cryted = 0 @@ -69,9 +69,9 @@ def main(): while(bytes_remaining): Plainbytes = PlainFirmware.ReadFile(BYTES_READ) - PlainbytesLittle = CrytoFirmware.SwapLittleEndian(Plainbytes) - Cipherbytes = CrytoFirmware.EncryptCtr(PlainbytesLittle) - CipherbytesLittle = CrytoFirmware.SwapLittleEndian(Cipherbytes) + PlainbytesLittle = CryptoFirmware.SwapLittleEndian(Plainbytes) + Cipherbytes = CryptoFirmware.EncryptCtr(PlainbytesLittle) + CipherbytesLittle = CryptoFirmware.SwapLittleEndian(Cipherbytes) CipherFirmware.WriteFile(CipherbytesLittle) print( PlainbytesLittle ) diff --git a/img/fwup-encryption/ExampleArquitecture.png b/img/fwup-encryption/ExampleArchitecture.png similarity index 100% rename from img/fwup-encryption/ExampleArquitecture.png rename to img/fwup-encryption/ExampleArchitecture.png diff --git a/img/fwup-encryption/MessgaeCTR.jpg b/img/fwup-encryption/MessageCTR.jpg similarity index 100% rename from img/fwup-encryption/MessgaeCTR.jpg rename to img/fwup-encryption/MessageCTR.jpg diff --git a/lefthook.yml b/lefthook.yml index 4a72e5ad..d1fb27b5 100644 --- a/lefthook.yml +++ b/lefthook.yml @@ -13,4 +13,5 @@ pre-commit: stage_fixed: true typos: glob: "*.md" + exclude: "^(example|misc)/|matter-internet-connectivity|mcu-peripheral-forwarding|lte-and-iot" run: yarn typos --config _typos.toml {staged_files}