Hi Clemens, On Fri, Jan 29, 2021 at 11:31 AM Clemens Gruber <[email protected]> wrote: > > Ok, so you suggest we extend our get_state logic to deal with cases > like the following:
Kind of. We can't control how other actors (bootloaders etc) program the chip. As far as I know, there are many, many different register settings that result in the same physical chip outputs. So if .probe() wants to preserve the existing chip settings, .get_state() has to be able to deal with every possible setting. Even invalid ones. In addition, .apply() cannot make any assumptions as to which bits are already set/cleared on the chip. Including preserved, invalid settings. This might get quite complex. However if we reset the chip in .probe() to a known state (a normalized state, in the mathematical sense), then both .get_state() and .apply() become much simpler. because they only need to deal with known, normalized states. In short, it's a tradeoff between code complexity, and user friendliness/ features. Sven
