mp.config — 9 functions

All setters return (ok: bool, err: string). On success: (true, ""). On failure: (false, "<reason>").

Function	Returns	Description
get()	table	{target, family, programmer, power, file_path, region_index}
set_target(name)	ok, err	Smart: looks up family + programmer in DB, triggers full backend refresh. (false, "Ambiguous target ...") for collisions, (false, "Target not found") if missing
set_target(family, name)	ok, err	Explicit family. Validates target ∈ family
set_family(name)	ok, err	Validates against DB; auto-switches programmer if current isn't supported by the family
set_programmer(t)	ok, err	"stlink" | "usbdm" | "tgsn" | "esp"
set_power(v)	ok, err	"3v3" | "5v" | "off"
set_file(path)	ok, err	Current file path
set_region_index(i)	ok, err	Active region index (0-based)
select(prog, family, target)	ok, err	Full selection; validates target ∈ family before triggering backend refresh
set(opts)	ok, err	Bulk — {target, family, programmer, power, file_path}; validates whole table before applying

Why set_target instead of writing target/family directly?

The smart form emits the same requestUpdateSelection signal the GUI uses, so memory regions, programmer info, power selector, and log level all reconfigure for the new target. A bare cfg.target = "..." write does not trigger that chain — the backend stays initialized for the previous target.

Examples

local cfg = mp.config.get()
mp.log.info("Target: " .. cfg.target)

-- Smart single-arg form
local ok, err = mp.config.set_target("STM32F103C8")
if not ok then mp.log.error(err) end

-- Two-arg form: explicit family for ambiguous targets
mp.config.set_target("STM32F1", "STM32F103C8")

mp.config.set_family("STM32F1")
mp.config.set_programmer("stlink")
mp.config.set_power("3v3")
mp.config.set_file("C:/firmware.hex")
mp.config.set_region_index(0)

-- Bulk
mp.config.set({target="STM32F103C8", family="STM32F1", programmer="stlink"})

-- Explicit programmer + family + target
mp.config.select("stlink", "STM32F1", "STM32F103C8")