-
Notifications
You must be signed in to change notification settings - Fork 86
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
support of QSPI transport to operate in 1BIT I/O mode #109
base: master
Are you sure you want to change the base?
Conversation
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.
changes looks great, I kind of guess that you will enable 1bit mode by modifying the flash device table to supports_qspi=false
right ? If that is the case, I think we should take another approach by updating the transport layer instead. I will explain in more detail after getting your confirmation.
src/Adafruit_SPIFlashBase.h
Outdated
@@ -75,6 +75,8 @@ class Adafruit_SPIFlashBase { | |||
int _ind_pin; | |||
bool _ind_active; | |||
|
|||
void write_status_register(uint8_t *); |
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.
the prototype should be
void write_status_register(uint8_t const full_status[2]);
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.
Done in c38a7ca
This PR is intentionally designed to create of no or least harm possible:
- it uses current API only
- setReadCommand() on an intermediate level and
- supports_qspi=false on a 'user level' (in flash device descriptor)
- default behavior remains the same as before - QSPI will operate at quad data rate unless user have not supplied supports_qspi=false argument intentionally.
It is out of the scopes for this PR to alter current API of the library.
I suppose that any changes in the API are only necessary when there are high demands of users to use extended features.
I doubt that this 1-bit access feature is currently so important that we need to change internal and external API of the library.
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.
thanks for confirmation, you don't have to alter the current API. IMHO, the flash device table is flash description, if the flash itself support quad mode, we should just leave it as it is. Instead We could update the actual transport layer. E.g 1bit mode or 2bit mode can be activated when declaring an object with IO1-IO3 = -1
the rest of the code can still apply, and it is transparent to existing user. That also allow using existing flash dev database and the n-bit mode is dictated by the user sketch only. Let me know if this makes sense to you.
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.
will be happy to see (and use) your own PR that will supersede this one
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 would like to, but I don't have motivation (and time) unless adafruit make board that need this. Meanwhile, we can leave this PR pending as reference.
Fix for #104