-
Notifications
You must be signed in to change notification settings - Fork 94
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
feat(spi_nand_flash): add diagnostics application for NAND flash #451
base: master
Are you sure you want to change the base?
feat(spi_nand_flash): add diagnostics application for NAND flash #451
Conversation
spi_nand_flash/examples/nand_flash_debug_app/main/Kconfig.projbuild
Outdated
Show resolved
Hide resolved
spi_nand_flash/examples/nand_flash_debug_app/main/spi_nand_flash_debug_app_main.c
Outdated
Show resolved
Hide resolved
Please, consider adding ESP_ERROR_CHECK wherever applicable. I didn't comment all single cases, however, we should provide clean-code example. Beside of such minor points, all LGTM. Thanks |
099bdcd
to
85e299d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think nand_read_write_sectors_tp
isn't a great "API" now because it returns information by printing it to console. This means that it can only be used in a test/diagnostic application.
If we keep the function as is, I would suggest:
- Move the function definition to the new diagnostics example
- Remove benchmarking part of the test_app — this is now covered by testing the example.
If you would prefer to keep this as an API, I would suggest some changes:
- Combine most of function arguments into a structure. This way, if you need to add yet another argument or a benchmarking option, that won't be a breaking change.
- Instead of printing the results using ESP_LOG, fill in another "result" structure, return the structure to the caller using an output pointer, and let the caller print the results.
Thank you for the review @igrr. I had considered this point earlier, but I’m not sure how the throughput would be used from the user’s perspective. This API is primarily designed for testing throughput, similar to how the iperf command works—where you provide arguments, and it prints the throughput. That was the idea behind creating this API. Of course, I can update it, but is it really necessary to return the time intervals required for reading and writing sectors? |
Would it then be enough to define this benchmarking function within the diagnostics application/example? This way you aren't committing it any specific API — you are free to change the example at any time without making it a breaking change. And as you said, it's not clear how the throughput will be used from users' perspective. My guess that having a benchmarking application is enough and the users won't need to integrate this into their own apps. |
Yes, I’ll move this function to the diagnostics application as it’s a better option. |
85e299d
to
db46e1a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just one nitpick.
#include "soc/spi_pins.h" | ||
#include "spi_nand_flash.h" | ||
#include "nand_diag_api.h" | ||
#include "nand_private/nand_impl_wrap.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it okay that the example depends on a private API?
Change description
Added a diagnostics application for NAND flash to facilitate debugging and performance analysis.