Page 1 of 1

wspi memory mapping calls

Posted: Fri Aug 09, 2019 10:56 am
by steved
At presentwspiMapFlash() and wspiUnmapFlash() assert if the required mode is already set.

Arguably they should just return if there's nothing to do. Otherwise the application effectively duplicates code. (It's sometimes useful to set a known state without worrying about the previous state).

Re: wspi memory mapping calls

Posted: Sun Aug 11, 2019 8:04 am
by Giovanni
Hi,

Shouldn't the application "know" its state? failing with an assert by calling an API on a wrong SM state is a pattern used everywhere in HAL. It is about not hiding potential problems.

Giovanni

Re: wspi memory mapping calls

Posted: Sun Aug 11, 2019 3:20 pm
by steved
Giovanni wrote:Shouldn't the application "know" its state? failing with an assert by calling an API on a wrong SM state is a pattern used everywhere in HAL. It is about not hiding potential problems.

Not necessarily, without duplicating the state-tracking code.
This arose in some test routines, where various tests might (intentionally) leave the interface in any of its possible states. On exit, I just tidy up by setting an appropriate state. Suggested from the perspective of minimising code, rather than any major difficulty.
Maybe this is a bit of a special case, since the current state doesn't (IMO) actually matter - all that matters is what is wanted now, assuming it is possible.