-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
drivers: Add NVRAM API #2353
drivers: Add NVRAM API #2353
Conversation
458a099
to
ac04725
Compare
Added a test application and have successfully tested on actual hardware. |
Needs a clean up of |
Updated the PR with cleaned up headers. Made all implementation specific functions static when possible, user interface is supposed to happen through nvram_t device descriptor, as in the test case. |
6fb42bf
to
5bd0f61
Compare
Squashed and rebased after some more testing on real hardware. Ready for review. |
@OlegHahm ping |
I unassigned @haukepetersen since he was on a trip and seem preoccupied with the network stack refactoring. I assigned @OlegHahm based on his request in #1222 (comment) |
Thanks @gebart for re-assigning. I have nothing to complain about this PR, but I'm not an expert on this low-level stuff. The interface looks reasonable to me. @thomaseichinger, @PeterKietzmann, care to review? |
I'll have a look at it but I assume I don't have something to test |
@PeterKietzmann The hardware device SPI protocol is very limited, so there is not very much to test there, it is not even possible to read the device size or any kind of identification. The biggest part of reviewing this PR is the introduction of a new API for NVRAM devices which can handle random byte writes without sector erase. |
Apart from me no one seems to object the function pointers. |
No one agains this API? That is good :-) . Let's wait for a final result in discussion #2528 and then go go for it soon. |
9f184dd
to
45554bf
Compare
I would like to merge this. My conclusion of the discussion here and in #2528 is that nobody is strongly opposed to this interface, and that the bus initialization can be left as is in the example. @PeterKietzmann @haukepetersen @OlegHahm any ACKs/NACKs? Btw, rebased. |
@gebart ok! Had a look at it again and still looks reasonable to me, even if I was not able to test. ACK. Please squash. |
Travis complains about whitespace errors. The rest seems to be fine |
Corrected whitespace error. |
This is a simple test application for the nvram_spi driver for tests on actual hardware.
@PeterKietzmann Is the commit list OK now or should I further squash everything into a single commit? |
@gebart no. The commit-messages seem reasonable to me. ACK and go |
Jippie |
This API is designed around non-volatile memories which do not need blockwise erase, such as ferro-electric RAM (FRAM) or magneto-resistive RAM (MRAM).
Flash devices do need blockwise erase and are not supported by this API.
Also included is a generic implementation of the NVRAM API for SPI connected FRAM devices from Cypress Semiconductor. This SPI driver may also work for MRAM from Everspin Technologies (according to the datasheet), however it has not been verified.