Many of TinyUSB's targets are small parts where the USB stack shares limited flash and RAM with the application. Every byte TinyUSB uses is a byte the user can't.

That makes memory footprint a core concern for the project, and a hard one to keep track of. A change in a shared driver might add 80 bytes on one port and 400 on another, and nobody builds every board locally before opening a PR. Without tooling, growth can pile up unnoticed across hundreds of boards, and tracking down where it came from means digging through map files and rebuilding old commits.

MemBrowse gives TinyUSB visibility into its memory footprint on every commit, so these changes are caught in the PR instead of weeks later. When something does grow, you can see exactly where the bytes went, which makes memory footprint investigation a breeze.

What MemBrowse does

MemBrowse runs as a step in your CI, on GitHub Actions or GitLab CI. After each build it reads the ELF, the linker script (for memory region limits) and optionally the map file (to attribute symbols to libraries). Each pull request gets a memory report comment showing how flash and RAM changed per target. Each target gets a history on the dashboard. Any change can be broken down by memory region, section and symbol, so you can see exactly what a commit added or removed and where it came from.

How TinyUSB uses it

TinyUSB's GitHub Actions workflow already builds every example for every board. MemBrowse runs on all of those builds, more than 2,100 of them, and posts a memory report on each PR.

Example: TinyUSB PR #3574

PR #3574 added board support for Nordic's new nRF54LM20 DK. The title only mentions the new board, but part of the change landed in code shared with other Nordic boards.

The MemBrowse report on the PR showed the effect. Eight of the ten biggest changes were examples on the Adafruit CLUE, an existing board built on Nordic's older nRF52840. Each grew by about 1.4 KB of flash and 136 bytes of RAM, up to 21% on the board_test example.

The build diff view shows why. The PR added UART receive support to the shared nRF board code: 14 new symbols such as nrfx_uarte_rx_buffer_set and nrfx_uarte_rx_abort, plus a 64-byte receive FIFO and a 64-byte transmit cache in RAM.

The dashboard shows the same change over time. On the CLUE's audio_4_channel_mic example, the flash line has a single jump of 1.40 KB at commit 3cfe7a0, the merge of PR #3574. Clicking that point leads straight to the symbol breakdown above.

The growth may well have been intended. Either way, it was visible in the PR before the merge, and it stays on record afterwards, down to the function.

Try it

MemBrowse is free for public repos and works with GitHub Actions and GitLab CI.

• TinyUSB dashboard: https://membrowse.com/public/hathach/tinyusb

• GitHub Action: https://github.com/membrowse/membrowse-action

• membrowse.com