Prefer flash (.rodata) for constant tables, because flash is plentiful on an MCU while RAM is scarce, and a flash-resident table costs zero RAM and zero boot time. You control placement by how you build the table: a static const array of literal values (generated offline by a script, or in C++ a constexpr table the compiler computes at build time) is placed in .rodata/flash; a non-const static array filled by a loop at startup lives in RAM and costs boot cycles to populate. So if the table is fixed and known at build time, make it const/constexpr to get it into flash. You'd only build it at runtime into RAM if it genuinely depends on runtime values (e.g. a calibration parameter read from the device). This is the same const/constexpr placement point from the C++ module applied to data structures.
Data Structures & Algorithms · Interview question
Should a lookup table live in RAM or flash, and how do you control that?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
Lookup Tables & Precomputation
Trade memory for time: precompute expensive results into a table and replace an O(k) runtime computation with an O(1) array read, the space-time tradeoff that powers DSP, trig, and CRC.