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).
wspi memory mapping calls
-
Giovanni
- Site Admin
- Posts: 14892
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: wspi memory mapping calls
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
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
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.