You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2021/06/04 16:08:26 UTC

[GitHub] [incubator-nuttx] antmerlino commented on pull request #3834: RFQ: progmem.h: Modify interface to avoid terms like page, sector, and block, as these terms are used interchangeably by different silicon vendors.

antmerlino commented on pull request #3834:
URL: https://github.com/apache/incubator-nuttx/pull/3834#issuecomment-854841346


   "I think that mapping the "nuttx specified" naming should be done in the implementing code. For example, in stm32h7 stm_flash.c ( which @davids5 mentioned ), the mapping seems to be done correctly. STM32H7 name "SECTOR" really means smallest erasable unit (block) and "PAGE" means the write-granule (page). I guess there are drivers which map these differently (wrong) still; so these should also be fixed in order not to get burned."
   
   Well, to be fair. It is really the STM32H7 that did not follow what all the other drivers did. It is the one that really introduced the disparity. In all other drivers, the getaddress and getpage calls returned what erasable unit you were in. On the H7 though, you got back the index for what writable unit you were in. And the claim that one is right and one is wrong is EXACTLY why I don't want to use sector or page terminology. 
   
   I hear what you are saying that we may need to expand the interface to include functions for both erasable and writable, but I refuse to accept that reintroducing the term page or sector as a good idea, because it's how the drivers got out of line in the first place.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org