wspi memory mapping calls

Use this forum for requesting small changes in ChibiOS. Large changes should be discussed in the development forum. This forum is NOT for support.
steved
Posts: 823
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 12 times
Been thanked: 135 times

wspi memory mapping calls

Postby steved » Fri Aug 09, 2019 10:56 am

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).

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: wspi memory mapping calls

Postby Giovanni » Sun Aug 11, 2019 8:04 am

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

steved
Posts: 823
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 12 times
Been thanked: 135 times

Re: wspi memory mapping calls

Postby steved » Sun Aug 11, 2019 3:20 pm

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.


Return to “Small Change Requests”

Who is online

Users browsing this forum: No registered users and 5 guests