Making a Firmware Budget Line Up With the Datasheet
Flash and SRAM are allocated in powers of two, but the numbers you collect while working on the firmware rarely arrive that way. A CI dashboard prints a decimal size, a spreadsheet of candidate parts lists capacities in KB, and the linker script wants a length that matches the silicon exactly. Converting decimal kilobytes into kibibytes is what makes those three numbers comparable before you commit to a part or a memory map.
KiB = KB ÷ 1.024, that is KB × 0.9765625. A build reported as 24 KB is 24 000 ÷ 1024 = 23.4375 KiB, so it leaves a shade over 8.5 KiB free inside a 32 KiB flash region.A Datasheet "32 KB" Is 32 KiB
The Toolchain Reports Raw Bytes
arm-none-eabi-size and you get plain byte totals for .text, .data and .bss. The linker map is byte-addressed too. Any KB or KiB figure in your notes is a human convenience layered on top of those bytes, which is exactly where rounding errors creep in.Reserve Before You Budget
LENGTH, not the headline capacity.EEPROM Thinks in Pages
Turning a Build Report Into a Region Figure
Enter the decimal size you were handed
Type the KB figure from the build summary, the part-selection spreadsheet or the size-tracking job in your pipeline. The decimal separator may be a comma or a dot and spaces are ignored, so 23,44 and 23.44 both parse.
Read the kibibyte value live
The KiB figure updates as you type, with up to eight decimals kept, so a value such as 0.9765625 KiB is shown in full instead of collapsing into a misleading 0.98.
Switch to bytes for the linker script
Linker ORIGIN and LENGTH values are ultimately byte counts. The searchable dropdown on either side lists every unit, so you can take the same value straight to bytes, then use the copy button to lift the bare digits into the .ld file.
Reverse it when the datasheet leads
Often the silicon comes first: the part has 64 KiB of flash and you need the decimal equivalent for a comparison table or a supplier quote. Press the swap button to run KiB back into KB — 64 KiB becomes 65.536 KB — without retyping anything.
Microcontroller Memory Sizes Read Both Ways
The first two columns convert a decimal kilobyte figure into kibibytes — what you need when a tool reported KB and your memory map is binary. The third column shows the trap running the other way: a part whose datasheet prints the same number is describing binary memory, so it holds more bytes than a decimal reading suggests.
| Decimal figure | Converted to KiB | A part labelled with that number really holds |
|---|---|---|
| 8 KB | 7.8125 KiB | 8 KiB = 8 192 bytes |
| 16 KB | 15.625 KiB | 16 KiB = 16 384 bytes |
| 32 KB | 31.25 KiB | 32 KiB = 32 768 bytes |
| 64 KB | 62.5 KiB | 64 KiB = 65 536 bytes |
| 128 KB | 125 KiB | 128 KiB = 131 072 bytes |
| 256 KB | 250 KiB | 256 KiB = 262 144 bytes |
On a small part the 2.4 % gap is not academic. Read "32 KB" as a flat 32 000 bytes and you have quietly written off 768 bytes — on a device where a whole peripheral driver may be under a kilobyte, that is real code. Apply the same slip to a 2 KiB SRAM part and it costs about 48 bytes, which is a stack frame or two, easily the difference between a clean run and a stack that grows down into the heap.
A value you can drop into a linker script
Copy on either field yields the digits alone — no unit, no thousands spacing — so the result pastes directly into a LENGTH expression or a build-time constant.
Binary and decimal units in one list
Both dropdowns carry bytes, KB, KiB, MB and MiB, so a flash region, an SRAM figure and an external memory part quoted in different conventions can be lined up in one place.
Type on whichever side you have
Both fields are editable, matching real firmware work: sometimes the known number is the build output, sometimes it is the region size printed in the reference manual.
Fractions kept, not rounded away
Eight decimals of output keep the difference visible on small regions, where rounding to one decimal would hide it completely.
Flash and RAM Budget Questions
My part is sold with 32 KB of flash — how many bytes can I actually program?
32 768 bytes, because memory arrays are built in powers of two and the label is the binary figure written with a decimal prefix. Confirm it in the reference manual's memory map: the flash region starts at a base address and runs for 0x8000 bytes. Budget against that byte count, since it is the only figure the linker and the programmer both agree on.
The size tool prints text, data and bss separately — which of them fill flash?
Flash consumption is .text plus .data: code and constants, plus the initial values of your initialised variables, which have to live somewhere non-volatile and are copied into RAM at startup. RAM consumption is .data plus .bss, and neither figure includes the stack or heap, which the linker script reserves rather than the size tool counting. Budget flash and RAM as two separate sums, and remember that .data is charged to both.
Why is my .bin file smaller than the flash the map file says I consumed?
A raw binary contains only the bytes that get programmed, while the map file also accounts for alignment padding and gaps between sections. If your image starts above a bootloader, a .bin flashed at an offset omits everything below it, whereas a .hex carries explicit addresses and looks different again. Check the region-usage line in the map file against your KiB budget, not the file size on your workstation.
How much flash should I reserve for a bootloader before budgeting the application?
Reserve whole erase sectors rather than a convenient round decimal number, because a sector is the smallest thing you can erase and a partially used one is lost anyway. A serial or CAN bootloader typically lands between 8 and 32 KiB; add a sector or two for parameter storage if the part has no real EEPROM. Subtract those regions first and treat the remainder as the application budget — 256 KiB minus a 16 KiB bootloader and 8 KiB of parameters leaves 232 KiB.
Does EEPROM page size change how much I can really store?
The capacity does not shrink, but the usable capacity usually does. A write that crosses a page boundary wraps to the start of the same page instead of continuing, so most drivers pad each record up to a whole page. Store 40-byte records in 64-byte pages and a 4 096-byte device holds 64 of them rather than 102 — and a wear-levelling scheme keeping two copies halves it again.
No comments yet. Be the first to comment!