-
Notifications
You must be signed in to change notification settings - Fork 177
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
feature: expose C api cs_pre_trans_delay
in SpiDriver
#266
Merged
ivmarkov
merged 10 commits into
esp-rs:master
from
vpochapuis:feature/expose-c-api-cs-pre-trans-delay-in-spi-driver
May 6, 2024
Merged
Changes from all commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
0412e3b
feature: expose C api `cs_pre_trans_delay` in `SpiDriver`
0e2807b
docs: add explanation on Duplex specifities for cs pre-transaction de…
5b1899b
Merge branch 'master' into feature/expose-c-api-cs-pre-trans-delay-in…
vpochapuis 4432eec
Merge branch 'esp-rs:master' into feature/expose-c-api-cs-pre-trans-d…
vpochapuis 3d918c5
fix(spi): add missing pre transaction parameters for C config struct
vpochapuis 3fc68ff
Merge branch 'esp-rs:master' into feature/expose-c-api-cs-pre-trans-d…
vpochapuis 0dd6ba6
Merge branch 'esp-rs:master' into feature/expose-c-api-cs-pre-trans-d…
vpochapuis 164389e
Merge branch 'esp-rs:master' into feature/expose-c-api-cs-pre-trans-d…
vpochapuis f047c62
Merge branch 'esp-rs:master' into feature/expose-c-api-cs-pre-trans-d…
vpochapuis c1b1464
Merge branch 'esp-rs:master' into feature/expose-c-api-cs-pre-trans-d…
vpochapuis File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
How does it behave when not in half-duplex mode? Do we get a runtime EspError or does it just get eaten silently? If you are not sure could you test out the cases and report how it acts running?
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.
That's a very funny thing in fact. I only use the FullDuplex mode.
I am using the AI-Thinker NodeMcu ESP32-S.
And it does make a difference (small one, but there is). However it only seems to take in account the fact that its different from 0.
When I do not set it or put 0, we have no time gap between CS pull-down and the first clock (and you can see the turquoise MISO channel doesn't change its state):
When I set it to 1/16/1000, I get the same small time gap between the CS pull-down and the first clock (and MISO answers):
This is all using FullDuplex.
They say in the C API driver include that its not supported, but somewhere else if we look closely we see:
So, at least from what I see its that, even though some part of the C doc seems to say that in FullDuplex mode it doesn't work. In reality its more like a on-off switch for a 1us pre-delay in FullDuplex mode, but it does make a big difference for some SPI chips.
Also, as you can see, setting a value higher than 16 (here 1000), doesn't change the behavior compared to 16.
(And sorry for the bad pictures instead of the oscilloscope screen capture, I was lazy to remember the functionality, but I think its still is enough to demonstrate)
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.
Further reading of the doc says:
But on the field itself:
Seems like its not as clear as it could be in the doc.
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 testing it out!
We are not using the Command & Address part currently in the driver. So that bit doesn't matter.
Did you also test the post delay? Docs don't indicate that this isn't only working in Half-Duplex.
What version of esp-idf are you using? We could annotate your finding's that a delay is happening in Full-Duplex at least in your tested esp-idf version, but with a warning that it might not be a "stable" option to do so.
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.
This week will be busy at work for reports etc... I will see if I have time, if not it will be next week!
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.
Its your PR -> your pacing 😄
i have no stress here