The same app.c reads the ADC, prints a line, blinks the LED, once a second. It ran unchanged on eleven TI boards, from an MSPM0C1104 with 1 kB of RAM to an AM62L running Linux. Moving it to another TI chip costs one small glue file per family. If you know Arduino: app.c is your sketch, and the glue file is the board core, written once per family.
The last line each board printed on its serial port: t is seconds since start, adc the raw reading, avg the 4-reading average
0lines of app.c changed on any of the 11 boards35 to 66lines of glue per chip familyPlus 5 to 41 lines of board setup. Boards in the same family share one glue file.
What a move costs, family by family
Each card is one glue file. Moving inside a family means a new setup file only (SysConfig, TI's pin and peripheral setup tool, writes most of it); moving to a new family means a new glue file. DriverLib is TI's plain C library for each chip's peripherals; TI Drivers is the portable layer above it. The ADC readings differ because each board reads a different input.
MSPM0
39lines of glue, shared by 4 boards
30 to 34 lines of board setup · 2.3 kB to 2.4 kB flash · DriverLib, no operating system
One glue file for all four boards. Each board adds only its SysConfig file: pins, ADC channel, UART.
Setup is C calls in board_init, with no SysConfig. Its 29 lines include a 5-line header that defines uint8_t, a type C2000 compilers leave out because the chip has no 8-bit byte.
Five calls, and nothing else in the app touches the chip. To bring the app to a board that is not here, write these five for it, starting from the glue file of the closest family.
board_initclocks and pins
adc_readone ADC reading
uart_writesend the line
led_toggleflip the LED
sleep_mswait a second
Run it on your board
Build every image (about 3 minutes, no board needed), then flash your board's image and check its serial output. The checker prints PASS when the lines arrive once a second and the average adds up, or FAIL: and what was wrong. Per-board flash commands are in the folder README.
Replace /dev/cu.usbmodemXXXX1 with your board's serial port (ls /dev/cu.usbmodem* lists them). Back up your board first: flashing overwrites the main flash.
Limits
Sizes compare layers, not chips. The radio boards carry FreeRTOS and TI Drivers (18 to 21 kB); bare DriverLib on an MSPM0 is about 2.3 kB. The AM62L number is the size of a Linux program file.
The smallest board, the MSPM0 C1104, has 1 kB of RAM. The running app touched 184 bytes of it: 16 bytes of variables and about 168 of stack.
The ADC input is whatever each board offers without wires: a thermistor, the temperature sensor, the battery channel or a floating pin. The numbers prove the app runs, not that the boards agree.
Zephyr and TI Drivers on the same MSPM0 cost more glue and flash: three ways on one board has the comparison.
Sources and run details
App, glue and setup files: the three ways folder. Line counts are code lines (no blank or comment-only lines) from count.py. Glue, setup, flash and RAM numbers are rows in each board's results file in the results folder (tests app_glue_lines, app_config_lines, port_flash_bytes, port_ram_bytes), dated 2026-10-25. Flash is the linker map's used total (for the C1104 and G3519, the text size tiarmsize reports from the same build); the AM62L size is the stripped, dynamically linked program. Console captures: portability/three-ways/logs/run-*.txt. Built on macOS with TI Arm Clang 5.1.1 (MSPM0, MSPM33, AM13, radios), the C2000 compiler from C2000Ware (F2800137) and GCC 14 on the board (AM62L). The test is also on Move across TI chips.