I’m starting on the CHIRP-to-radio writing programming on a live radio model. CHIRP seems to call set_memory for every possible change to the screen display of a memory.

Yep.

Is there a way to defer writing until all changes have been made? With something like a “write the selected memory now” button, and using the “memory modified” flag that’s available in the live model. For that matter, can one request selective reads as well (as opposed to reading the whole radio).

Nope.

I’m under the impression that the radio manufacturer would prefer to have as few write cycles as possible.

Most of the radios I know of seem to write to the EEPROM with every detent of the tuning dial, so I really hope they're not unhappy about the occasional programming operation. All of the rig control software I've ever seen send commands to the radio for every button press, which is usually persisted in the "active settings" region of memory. Those hot spots should wear out *way* earlier than the memories due to repeated programming, IMHO.

If you're worried about it, either edit your memories with the properties dialog or cultivate your plan in CSV format and paste them in, which will result in one operation per memory. Live radios are really few and far between and I don't think we need to go too far down the path of coalescing multiple updates for the relative few of them that we support.

On another matter, is there a reasonable way to instantiate the data model that bitwise.parse can do in a live radio? I got really used to having symbolic access to bitfields in a clone-mode driver, and it might help with the live model as well. (Although NamedTuple and unpack()/pack() seem to be pretty easy to handle at the moment.)

You can bitwise.parse() each result from a memory fetch, of course.

--Dan