-
Notifications
You must be signed in to change notification settings - Fork 327
Added HAL_Delay_us() for BK7231 #1579
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
base: main
Are you sure you want to change the base?
Conversation
@rpv-tomsk |
Quick look on source shows:
So quantum/step will be 31us. |
Looking in calendar.h it seems 3125 is just a misspelling, it was meant to be 31_25, meaning a step will be 0.3125us. Or am i thinking it wrong? |
My thoughts ares following: |
I understand what you meant now, and i didn't bother to check it in code - since this is default implementation for delayMicroseconds for bk7238 arduino core. |
Also want to notice, current implementation of OWReset() is incorrect. Things are better with patch applied:
|
Checked timings on 7231N. Code:
produces results: So there is ~3.5us overhead only. |
Simple patch reduces that time to another 1us... Thanks for pointing. |
Would these changes be acceptable to merge? |
Wow. For my BK7231T gpio overhead reduced to 1.6us. |
Does DS1820 now works for you? |
I reviewed HAL_Delay_us() a bit. One major change is timer overflow value. It seems to have another value. Also, reviewed Also, I had thoughts about Also, I thought that getTicksCount() adds his overhead, so removed second call from while loop... So, added changes and the code now looks like shown below. Please review.
|
And some changes with GPIO implementation:
|
Overcomplicated.
|
Yes, for now I don't think anybody should use usleep() for microseconds, so these several lines of vTaskDelay() should be removed when doing PR code update. As for |
240a95a
to
ded3289
Compare
2550485
to
703cf31
Compare
* Do not use HAL_PIN_SetOutputValue() when reading sensor response - output must be open-drain. * Use Input_Pullup when reading sensor response instead. That allows to connect sensor w/o adding pullup resistor. * Fixed OWReadBit timing, read must be done within 15us, instead of after. Closes: openshwprojects#1582
Code prepared for merge. |
Sorry for my late feedback, thank you so much for your work on this! I didn't test, but I'm quite sure the overhead is not necessarily equal for all platforms, and there are quite a lot around. |
Yes, I have same thoughts so left overhead in hal/ files, left comment about this in code too. |
something like this maybe ? |
For N I also have 2us overhead, not 1us. |
What is needed for this PR gets merged? |
Please note that this version will not work on BK7238 - it will crash. I didn't get it to work on this platform with this approach (every call to read the ticks will timeout, so even if you do some checks that it wont crash, usleep won't work). I also didn't manage to get DS18B20 working with the idea with calendar from @NonPIayerCharacter (this version for me on BK7238 only works o.k. with delays > 20us, all values smaller ~ 20us will [don't ask me, why] result in some longer(!) delays, e.g. for me 5us/6us/10s will all take approx 35us. Starting with a delay of 20 the values are "near" the expected ones: 20 -> 24 / 50 -> 58 / 100->115 / 200->214 / 500->500). So for now I simply made a special case for BK7238 which is at least working with DS18B20 for me, though timing is not too good. There is also some sort of error handling for getTicksCount() - this can be streamlined for sure...
EDIT: This will not work for bigger values on BK7238, e.g. used for DHT. |
This works for me on BK7238 with DS1820 and DHT11 (didn't test the other Beken platforms):
|
BK7238 - how is it possible that timer is not running there? What SDK does it use? |
@rpv-tomsk |
Back to the original topic: I don't know if it's worth trying, since it seems to work well, but the code for the actual test if delay-counter is reached is surely correct, but seems (too) "expensive" in many cases: in each run of the while-loop there is at least one subtraction and one comparison (if the compiler ignores second parameter in an AND statement where the first test is "false"). Worst case there are two subtractions and two comparisons in every loop. If we add a little more code, we can make the loops much simpler. There are three cases, since we need to take care about a possible overflow. The most common case: The other "easy" case: Then there is the seldom but "tricky" case: So in most cases, we will only need one comparison inside the loop (though we need two loops for the overflow case) and only the seldom case with a possible overflow needs multiple comparisons. My proposal is (only for the non-BK7238 platforms):
As I said, it's a bit more code for the different cases, but the loops should be faster in most cases... |
Added HAL_Delay_us() based on timer, not nop.
Timings are much better now.