Learning Tracker (Spring 2026)

Sat, 07 Mar 2026 00:00:00 +0000

Here are the articles, books, papers, videos, and tools that I’ve been exploring this Spring.

Articles & Blogs

Paged Out! - Issue #8
Programming zine.
Shell Tricks That Actually Make Life Easier (And Save Your Sanity)
by Christian Hofstede-Kuhn.

Classes

The Missing Semester of Your CS Education - 2026
MIT lectures I plan to send to any college grad new dev hire.

SLIP Analyzer for Saleae Logic 2

Tue, 09 Dec 2025 00:00:00 +0000

I’ve been working on a fairly complicated platform over the last year that contains (among many things) a microcontroller (MCU) and a System-on-Chip (SoC), with various services running on these systems that need to communicate with one another. SLIP (Serial Line Internet Protocol) over UART was chosen as one of the communication channels due to its simplicity and lightweight nature. On the application side, all we see is a network interface, so we can simply write UDP or TCP clients and servers, and the rest is handled by the network stacks and UART drivers.

Sometimes, however, we run into issues and need to debug the communication between services. This can sometimes mean digging all the way down to the bits traveling over the wire between the two systems, and we all know how painful that can be.

Hooking up a logic analyzer to view the digital signals is useful, but I wanted the software to not only show me the signals but also decode the data being transmitted (i.e. IP:Port and payload info that tells me which services are communicating), which in this case means decoding UDP/TCP over IP over SLIP over UART.
With a Saleae logic analyzer¹ (I’m using the Logic 8), the Logic 2 software, and a custom extension for decoding SLIP frames, I was able to capture, visualize, and analyze the data with relative ease.

What is SLIP?

SLIP (Serial Line Internet Protocol), defined in RFC 1055², is a simple protocol for framing IP packets for point-to-point connections over a serial interface.

The protocol is elegantly simple:

END character (0xC0): Marks the beginning and end of packets
ESC character (0xDB): Escapes special bytes in the payload
ESC_END (0xDC): Represents a literal 0xC0 in the data (sent as 0xDB 0xDC)
ESC_ESC (0xDD): Represents a literal 0xDB in the data (sent as 0xDB 0xDD)

For example, if you want to send the byte sequence [0x01, 0xC0, 0x02], SLIP would encode it as:

0xC0 0x01 0xDB 0xDC 0x02 0xC0

The 0xC0 at the beginning marks the packet start, the 0xDB 0xDC sequence represents the literal 0xC0 byte in the data, and the final 0xC0 marks the packet end.

While SLIP has largely been replaced by PPP (Point-to-Point Protocol)³ in many applications, it’s still remarkably useful due to its simplicity and minimal overhead.

Why Build a Custom Analyzer?

Saleae Logic 2 comes with many built-in protocol analyzers, but SLIP isn’t one of them.
If all I wanted to do here was parse SLIP frames (i.e. start/end of frame + escaped characters), it would be a trivial extension to write and I’d argue that there is little-to-no value in doing so given you could probably just inspect the packets directly using the existing Async Serial extension⁴.
However, in my case I want to get information about the TCP/IP or UDP/IP packets encapsulated in the SLIP frames (IP addresses, protocol, port number, etc.), and writing a High-Level Analyzer⁵ in Python that extends the Async Serial extension is an easy way to achieve this.

Another option would have been to write a custom analyzer in C++ using Saleae’s Protocol Analyzer SDK ⁶, but then we would have had to write the UART decoding as well and we already get that for free with the existing Async Serial analyzer.

With a custom High-Level Analyzer (HLA), I can:

Decode SLIP frames: Process framing and escape sequences
Parse IPv4 headers: Extract source/destination IPs, protocol types, and other header fields
Identify TCP/UDP ports: See which services are communicating
Catch protocol errors: Detect invalid escape sequences or malformed packets

The alternative would have been copying hex dumps, writing scripts to parse them offline, and constantly switching between tools. With a custom HLA, all this information appears directly in the Logic 2 interface.

How High-Level Analyzers Work

Saleae’s High-Level Analyzer (HLA) framework allows you to write Python-based protocol decoders that process data from lower-level analyzers. In my case, the HLA relies on receiving frames from the Async Serial analyzer as the input, and will output decoded SLIP + IP + UDP/TCP decoded frames.

The workflow is:

Configure Async Serial analyzer to decode the UART traffic
Attach the SLIP HLA to the Async Serial analyzer output
The HLA processes each byte, building up SLIP frames and parsing their contents
Display decoded frames with human-readable information in the Logic 2 timeline, data table, and terminal UI

The HLA API is straightforward, and all you really need to implement is a class that extends HighLevelAnalyzer and define a decode() method that receives frames from the input analyzer and yields new frames with your decoded data. Saleae handles all the UI integration, timeline rendering, and data management.

Building the SLIP Decoder

GitHub Repo: saleae-analyzers/slip

Architecture

The code for the analyzer is pretty simple:

SLIP Frame Decoder: Handles the low-level SLIP protocol (escape sequences, framing)
IPv4 Parser: Extracts and parses IPv4 headers from SLIP payloads
Result Formatter: Combines SLIP and IP information into displayable frames

At a high level, it looks something like this:

  ---
config:
  class:
    hideEmptyMembersBox: true
---
classDiagram
    class saleae.analyzers.HighLevelAnalyzer {
        <<interface>>
        + decode(frame) AnalyzerFrame[]
    }
    
    class SLIP_HLA {
        + decode(frame) AnalyzerFrame[]
        - _emit_ipv4_frame(start_time, end_time) AnalyzerFrame
        - _emit_packet_frame(end_time) AnalyzerFrame
        - _emit_error_frame(end_time, message, offending_byte) AnalyzerFrame
    }
    
    class AnalyzerFrame {
        + str type
        + saleae.data.GraphTime start_time
        + saleae.data.GraphTime end_time
        + dict data
    }
    
    class SlipProtocol {
        <<enumeration>>
        END = 0xC0
        ESC = 0xDB
        ESC_END = 0xDC
        ESC_ESC = 0xDD
    }
    
    class ProtocolNames {
        <<enumeration>>
        ICMP = 1
        TCP = 6
        UDP = 17
    }
    
    saleae.analyzers.HighLevelAnalyzer <|-- SLIP_HLA : implements
    SLIP_HLA ..> AnalyzerFrame : creates
    SLIP_HLA ..> SlipProtocol : uses
    SLIP_HLA ..> ProtocolNames : uses

Logic 2 feeds Async Serial frames to the SLIP HLA via the HighLevelAnalyzer::decode() interface, which implements the state machine looking for start/end SLIP frames. When a SLIP frame is found, it is then parsed in one of the following ways:

If there is a problem decoding the SLIP frame, issue an error frame.
Otherwise, attempt to parse the frame as an IPv4 packet (I’m not worrying about IPv6 here).
- If it fails to parse the data as an IPv4 packet, simply display the data in the SLIP frame without parsing.

SLIP Decoding State Machine

The state machine in decode() is pretty simple for the SLIP protocol:

IDLE state: Wait for 0xC0 (END) to start a new packet
IN_PACKET state: Accumulate payload bytes
- If we see 0xC0, the packet is complete
- If we see 0xDB (ESC), transition to ESCAPE state
ESCAPE state: Process the next byte
- 0xDC → Insert literal 0xC0 into payload
- 0xDD → Insert literal 0xDB into payload
- Anything else → Protocol error

Once a complete packet is received, it’s passed to the IPv4 parser.

IPv4 Header Parsing

After decoding the SLIP frame, the analyzer checks if the payload looks like an IPv4 packet (version field = 4). If so, it extracts:

Version and Header Length
Total Length
Protocol (TCP, UDP, ICMP, etc.)
Source and Destination IP Addresses
TCP/UDP Port Numbers (if applicable)

Error Handling

The analyzer detects and reports several error conditions:

Invalid SLIP escape sequences: When 0xDB is followed by something other than 0xDC or 0xDD
Malformed IPv4 packets: When the payload is too short or has invalid version/length fields
Incomplete frames: When data ends mid-packet

These errors appear as distinct frame types in Logic 2, making it easy to spot protocol violations.

Displaying Results

The final piece is formatting the decoded information for display. The HLA creates frames with descriptive strings like:

IPv4 [192.168.1.10 -> 192.168.1.1 UDP len=33 5000 -> 8080]

This appears in the Logic 2 timeline, aligned with the serial data that was decoded. You can click on any frame to see the timing, raw bytes, and decoded information side-by-side.

The parsed IPv4 frame is also shown directly in the Data Table:

Improvements and Future Work

There are several enhancements I’d like to make to this extension:

Export PCAP: Figure out a way of generating a PCAP directly from the captured SLIP data which I could then analyze directly in Wireshark (although for this I think I need to go the C++ SDK approach rather than Python High-Level Analyzer).
Protocol Statistics: Add a “Cumulative Stats” field to track packet counts, error rates, and throughput.
Add option to connect two Async Serial inputs: Give the option to configure two Async Serial input sources (RX and TX) and be able to track conversations between peers (SRC-IP:SRC-Port <–> DST-IP:DST-Port) to be able to measure latencies.
Bidirectional Analysis: Track request/response pairs and calculate latencies.
Configuration Options: Allow users to enable/disable IPv4 parsing or customize display format via input options.

Learning Tracker (Winter 2025/2026)

Sat, 06 Dec 2025 00:00:00 +0000

Here are the articles, books, papers, videos, and tools that I’ve been exploring this Winter.

Articles & Blogs

Myths Programmers Believe about CPU Caches
Recap on topics around cache-coherence.
The Next Two Years of Software Engineering

Videos

Advent of Compiler Optimisations 2025
Matt Godbolt’s series on compiler optimizations.
39C3 - Liberating Bluetooth on the ESP32
Presentation by Antonio Vázquez Blanco.
Patterns and Anti-Patterns in Embedded Development: What Security Incidents of 2023 Teach Us
Presentation by Marta Rybczynska.

Repos

ARM Exploitation
Source for “ARM Binary Exploitation” book.

Classes

Georgia Tech’s OMSCS Open Courseware
GaTech’s Online Masters in Computer Science public courses.
Yocto Project and OpenEmbedded training
Online training for Yocto and OpenEmbedded.

Projects & Tools

Binary Ninja
Reverse Engineering Tool.
John the Ripper
Password cracker (OSS).

ARM Semihosting (Part 2) - Example IO

Wed, 26 Nov 2025 00:00:00 +0000

In the previous post I introduced the concept of ARM Semihosting. In this post I am going to set up a simple “Hello World” program running on the Raspberry Pi Pico 2 (RP2350) which shows how to get semihosting working to print out basic I/O output on the debugger console.

RPi Pico Development Setup

The RP2350 is a versatile dual-core MCU that can be configured to run either as ARM Cortex-M33 or Hazard3 RISC-V (for my examples I’ll only be running the ARM cores).
I am also going to be using another Raspberry Pi Pico 1 (RP2040) as a debugger (flashed with the CMSIS-DAP debugprobe image) connected as follows:

I created the following GitHub Repo where I will be pushing all of the examples and builds for this project.

In order to make the development simpler to replicate, I have included a devcontainer setup in vscode that builds the image and container necessary to develop on the RPi Pico boards. This includes the necessary SDK, dependencies, and tools to debug the code.

Pico-SDK Setup

Follow the instruction in the Pico-SDK repo to clone the RPi Pico-SDK and set your PICO_SDK_PATH environment variable to point to this location.

OpenOCD & GDB Setup

The easiest way to get OpenOCD to run with the RP2350 is to get it directly from the pico-sdk-tools repo (release page). Alternatively you can build from source (takes a while):

# Option 1 - download pre-built OpenOCD image
$ cd $PICO_SDK_PATH
$ mkdir -p openocd && cd openocd
$ wget https://github.com/raspberrypi/pico-sdk-tools/releases/download/v2.2.0-3/openocd-0.12.0+dev-x86_64-lin.tar.gz
$ tar -zxvf *.tar.gz && rm *.tar.gz

# Option 2 - build from source
$ git clone https://github.com/raspberrypi/pico-sdk-tools && cd pico-sdk-tools
$ sudo apt update && ./build_linux.sh

The GDB client I’m going to be using is gdb-multiarch (alternatively you can use arm-none-eabi-gdb) which I have installed via:

$ sudo apt install gdb-multiarch

Pico debugprobe Setup

The simplest way to set up the RP2040 as a CMSIS-DAP debugger probe is:

Download the latest debugprobe.uf2 firmware from the debugprobe releases
Hold the BOOTSEL button on the RP2040 while connecting it to your computer via USB
Drag and drop the debugprobe.uf2 file to the mounted drive
The RP2040 will reboot and appear as a debug probe device

Connect the debug probe to your RP2350 target:

GND to GND
GP2 (SWCLK) to SWCLK on target
GP3 (SWDIO) to SWDIO on target
GP4/GP5 for UART (optional, for serial output, which we’re not using in this example)

The probe provides both SWD debugging interface and UART passthrough.

Project Setup

For the most basic setup we’re going to need 3 files:

The C source file where we are exercising the ARM Semihosting functionality.
CMakeLists.txt build file.
pico_sdk_import.cmake from the Pico-SDK which contains definitions needed to properly compile the project.
1. You can copy over the pico_sdk_import.cmake file from the Pico-SDK via $ cp $PICO_SDK_PATH/external/pico_sdk_import.cmake .

Semihosting Example

C Source

The simplest “Hello World” program to test semihosting functionality would look something as follows:

#include <stdio.h>
#include "pico/stdio_semihosting.h"

int main()
{
    stdio_semihosting_init();

    printf("=== ARM Semihosting Test ===\n");
    printf("This message appears in the debugger console.\n");
    printf("Counter test: ");
    for (int i = 0; i < 5; i++)
    {
        printf("%d", i);
    }
    printf("\n");
    
    return 0;
}

CMake

The CMakeLists.txt file looks as follows:

cmake_minimum_required(VERSION 3.13...3.27)

# note: this must happen before project()
include(pico_sdk_import.cmake)

set(TARGET_NAME hello_world)
project(${TARGET_NAME} C CXX ASM)

# initialize the Raspberry Pi Pico SDK
pico_sdk_init()

add_executable(${TARGET_NAME} hello_world.c)

target_link_libraries(${TARGET_NAME} pico_stdlib pico_stdio_semihosting)

# Link with semihosting library (requires --specs=rdimon.specs)
target_link_options(${TARGET_NAME} PRIVATE --specs=rdimon.specs)

# create map/bin/hex/uf2 file in addition to ELF.
pico_add_extra_outputs(${TARGET_NAME})

Note:
We can achieve the correct linking via one of the following ways:

call stdio_semihosting_init() in main() (and include "pico/stdio_semihosting.h")

or, set pico_enable_stdio_semihosting(hello_world ENABLED) in the CMakeLists.txt (and then in main() we just call stdio_init_all())

Both achieve the same result.

Build

In my case I am building for a Pico 2 W (same as the Pico 2 with the addition of an Infineon Wi-Fi module), so I specify the board using the PICO_BOARD variable:

$ cmake -S . -B build -DPICO_BOARD=pico2_w
$ cmake --build build --target hello_world

Run OpenOCD

In a terminal shell we can start OpenOCD as follows:

$ pushd $PICO_SDK_PATH/openocd
$ ./openocd -c "gdb port 50000" -s scripts -f interface/cmsis-dap.cfg -f target/rp2350.cfg -c "adapter speed 5000"

Which will look for a CMSIS-DAP device to connect to, and starts up a gdbserver listening on port 50000.

Run GDB

In a separate terminal run gdb-multiarch as follows:

$ cd ./build
$ gdb-multiarch --se=hello_world.elf 
> target extended-remote localhost:50000
> monitor reset init
> monitor arm semihosting enable
> monitor arm semihosting_fileio enable
> load hello_world.elf
> tbreak main
> continue
> continue

What we are doing here is:

invoke gdb and tell it to load hello_world.elf as the executable and symbol file
connect to the remote OpenOCD gdbserver running on port 50000
the monitor tell OpenOCD to:
- reset init - halt the target, and execute the reset-init script
- arm semihosting enable - allows for code executing on an ARM target to use the I/O facilities on the host computer
- arm semihosting_fileio enable - allow forwarding semihosting I/O to GDB process using the File-I/O remote protocol extension
load hello_world.elf - flash the executable onto the device
tbreak main - set a temporary breakpoint in main
continue - runs to the breakpoint, and another one to let the target run.

Output

When everything is properly configured we will see the following on the gdb console:

=== ARM Semihosting Test ===
This message appears in the debugger console.
Counter test: 01234

Showing that we’ve successfully compiled a simple program on the RP2350 that redirects printf output to the attached debugger via semihosting.

ARM Semihosting (Part 1) - Introduction

Tue, 25 Nov 2025 00:00:00 +0000

In this series I explore ARM Semihosting and work toward a small C library and host-side tools to track and visualize heap activity on a live target. For development and testing I’ll use the RP2350 (Raspberry Pi Pico 2), but the concepts apply broadly to other ARM platforms.

Introduction to ARM Semihosting

ARM semihosting lets code running on a target MCU request services from the host (console I/O, file I/O, system queries, etc.) via the debugger. The target signals a semihosting request by issuing a special exception (typically using BKPT, SVC, or a similar trap instruction). The debugger intercepts the trap, performs the requested operation on behalf of the target, returns the result (usually in R0), and resumes execution.

On ARMv6-M or ARMv7-M devices, semihosting traps are typically generated with BKPT. On other ARM profiles the mechanism may use SVC/SWI. The observable effect is the same: the debugger handles the request and returns a result to the target.

Semihosting is often useful during board bring-up when serial/UART hardware is not yet available, since it lets you get printf-like output and file operations over the debug connection. There are alternatives with different trade-offs (SWO, Segger RTT, dedicated UART/USB logging), and semihosting has limitations I cover below, but it remains a convenient tool during early development.

How it works (brief)

There are various blog posts¹ ² and documentation³ that do a much better job of describing in detail how semihosting works, but at a high level we have the following:

A special instruction is issued by the target that indicates that a special semihosting operation is being performed. For this instruction R0 will contain an operation number, and any parameter is passed via R1.
This will cause the CPU to halt, and now its the debugger’s turn to take the data in R0 (and optionally R1), perform the requested operation and return the result to the target (in R0), along with resuming the core.
Some common operations that the debugger might support via semihosting are: SYS_OPEN / SYS_CLOSE, SYS_READ / SYS_WRITE…

Pros and Cons

Pros: You usually already have SWD/JTAG connected during development, so semihosting requires no additional board wiring. It provides convenient, host-backed I/O without a serial port.
Cons: Semihosting is blocking — the CPU halts while the debugger performs the operation. If no debugger is attached (or the debugger doesn’t implement the requested call), the trap can cause a fault unless you explicitly handle or detect that case. That requires defensive code or configuration to ensure production systems do not rely on semihosting.

Alternatives to semihosting:

SWO: Good for streaming debug output with lower overhead than semihosting, but it requires the SWO pin to be available and a debugger that supports it.
Segger RTT: Non-blocking and very flexible for real-time logging and data transfer over SWD, but is a proprietary solution that requires Segger tooling and their RTT library.

Semihosting Project Idea

Heap instrumentation and visualization

The goal is to use semihosting to instrument heap activity on a running target and produce a visual timeline of allocations and deallocations. With this I want to be able to answer two questions for a running target:

How many allocations and deallocations occur over time?
What does the heap’s layout look like as the system runs?

My hope if to have an implementation that looks as follows:

Reserve (statically) a small circular buffer in RAM to record heap events.
Wrap malloc/realloc/free (or the platform’s allocator hooks) to capture basic metadata for each operation and append an event to the buffer.
When the buffer fills or a flush condition is met, issue a semihosting transfer to dump the buffered events to the host (only if a debugger is attached).
Implement a host-side tool to parse the event stream and generate time-series graphs and heap-layout visualizations.

Development target

The library should be portable across ARM platforms. For development I’ll use the Raspberry Pi Pico 2 (RP2350). Initially I’ll use a single Cortex‑M33 core for the instrumented firmware; later I may explore offloading data transfer to the second core or using a non-blocking transport to avoid halting the main application.

Microcorruption

Sun, 05 Oct 2025 00:00:00 +0000

A year or so ago I came across Microcorruption, a website hosting a set of exercises/challenges where you are supposed to reverse-engineer an MSP430-based embedded device (a lock which they call the “LockIT Pro”) using a debugger, and bookmarked it with all the best intentions to play around with the exercises… I then proceeded to completely forget about it until recently when I was cleaning up my bookmarks.

Now I want to devote some time to play around with the CTF exercises and see how far I get.

The website gives you everything you need - an emulated environment, access to a rudimentary debugger, the assembly code, a memory viewer, console output, and the registers. They also provide links to the MSP430 ABI and User Guide (useful to figure out register map of the device, instruction set, interrupt vector, etc.), as well as LockIT Pro’s manual/user guide which describes the platform that you’re working with.

As I work through the different exercises, I will be posting writeups and solutions in the following GitHub Repository .

Learning Tracker (Fall 2025)

Thu, 02 Oct 2025 00:00:00 +0000

Here are the articles, books, papers, videos, and tools that I’ve been exploring this Fall.

Articles & Blogs

Hosting a WebSite on a Disposable Vape
A fun blog post on how to a simple ARM Cortex-M0+ + ARM Semihosting can be used to serve a static site (AND they’re using the same website theme as me - so you know they’re the real deal).
Introduction to ARM Semihosting
Going down the rabbit hole of ARM Semihosting.
How to stop Linux threads cleanly
Since I’ve been debugging a lot of multi-threaded code at work, a simple intro on thread termination.
Moon
Unbeatable visualizations and explanations by Bartosz Ciechanowski.
Ampcode - How to Build an Agent
A blog post detailing how to build custom agentic tools.

A prvalue is not a temporary
A quick refresher for lvalues, rvalues, xvalues, and prvalues.

Zines

Paged Out! - Issue #7
Latest issue, perfect for reading during your commute or on a Sunday morning with a hot beverage of your choice.

Videos

CppCon 2014: Herb Sutter “Back to the Basics! Essentials of Modern C++ Style”
Engaging talk - worth the watch (basic styles and idioms of C++).
C++ Weekly With Jason Turner
Jason Turner’s YouTube channel covering all sorts of great C++ topics.

Projects & Tools

Celery - Distributed Task Queue
Exploring Celery for a personal project.
pwndbg
Playing with pwndbg python module for extending gdb functionality.

Other

Microcorruption
CTF on a simulated MSP430 platform.

Learning Tracker (Summer 2025)

Sun, 31 Aug 2025 00:00:00 +0000

Here are the articles, books, papers, videos, and tools that I’ve been exploring this Summer.

Articles

Magic Buddy Allocation
Paged Out! - Internals of a simple memory allocator.

Videos

In the Kernel Trenches: Mastering Ethernet Drivers on Linux
Embedded Linux Conference - setting up a basic network driver.
Finding the Best Block Filesystem for Your Embedded Linux System
Embedded Linux Conference - comparison of different block filesystems.
What Has My Compiler Done for Me Lately? Unbolting the Compiler’s Lid
CppCon - demystifying assembly code and what the compiler is doing.
The Bits Between the Bits: How We Get to main()
CppCon - everything that happens in getting from compilation to main().
Data-Oriented Design and C++
CppCon - “transformation of data is the only purpose of any program”…

HEIF Image Conversion and Layout Generation

Wed, 27 Aug 2025 00:00:00 +0000

Recently, my wife tasked me with printing hundreds of photos from mixed sources (iPhone, camera, WhatsApp) for her scrapbooking activities, which presented two primary technical challenges:

Format incompatibility: HEIF (.heic) files from iOS Live Photos were not supported by the printing layout software I had installed
Manual layout inefficiency: Arranging photos in print layouts was manual and time-consuming

Rather than relying on third-party online tools or manual processes, I developed two Python utilities to automate the entire workflow:

HEIC Converter: Batch converts HEIF images to standard formats (JPEG/PNG/WEBP)
Layout Generator: Arranges images in grid layouts optimized for printing

HEIC to JPEG Conversion

GitHub: heic_converter

Key Dependencies:

pyheif: HEIF/AVIF decoder support via libheif
Pillow (PIL): Image processing

Description: The converter uses pyheif to decode HEIC files into raw image data, then leverages Pillow to perform the format conversion. The tool supports multiple output formats and includes comprehensive error handling for corrupted files.

PDF Layout Generation

GitHub: layout_gen

Key Dependencies:

Pillow: Image processing
ReportLab: PDF generation and document layout

Description: The layout generator creates PDF documents with configurable grid layouts, automatically rotating and cropping images to optimize for printing.

Current Limitations & Future Enhancements:

Cropping Algorithm: Currently uses edge-based cropping without content-aware centering, meaning subjects near image edges may be cropped out.
Uniform Sizing Constraint: All images in a layout use identical dimensions, requiring separate invocations when dealing with mixed aspect ratios.

Mon, 01 Jan 0001 00:00:00 +0000

Hi, I’m Gabriel — polyglot (English, French, Portuguese, and Spanish), embedded software developer, tinkerer, woodworker, and team leader currently living in the Washington, D.C. area who’s focused the last 12 years developing security platforms, IoT devices, gateways & routers, and video camera platforms.

I received my Master’s in Computer Science from Georgia Tech, specializing in Computing Systems, and my Bachelor’s from Cornell University in Electrical and Computer Engineering.

The goal of this site is to serve as a place where I can share ideas, work, and explorations relating to the areas that interest me, and push me to dive deep into certain topics so that I can share some of what I’ve learned with others.

You can see my Now page to get a glimpse of what I’m currently up to…

Always interested in connecting with fellow developers, and anyone pushing the boundaries of what’s possible with constrained systems via .

Mon, 01 Jan 0001 00:00:00 +0000

This is a now page, inspired by Derek Sivers. It’s a snapshot of what I’m focused on right now - think of it as what I’d tell a friend I hadn’t seen in a year.

Discovering the joys and challenges of parenthood.

Currently Reading

Books

Zines

Discovering hidden gems in the following e-zines:

Learning

Forcing myself to use vim & tmux