Thanks, let me check.
Giovanni
chTimeIsInRangeX always false? Topic is solved
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: chTimeIsInRangeX always false?
Hi,
If prev==next then the window is the whole time range so the thread goes to sleep for a long time but not forever, I think the behavior is correct but also consider that calling chThdSleepUntilWindowed() with prev==next makes no sense because you want the thread to sleep while the system time is within the specified window.
Previously prev==next meant a zero size window, now it is a "whole" size window, both make no sense IMO or I am just missing the use case.
Giovanni
If prev==next then the window is the whole time range so the thread goes to sleep for a long time but not forever, I think the behavior is correct but also consider that calling chThdSleepUntilWindowed() with prev==next makes no sense because you want the thread to sleep while the system time is within the specified window.
Previously prev==next meant a zero size window, now it is a "whole" size window, both make no sense IMO or I am just missing the use case.
Giovanni
- alex31
- Posts: 379
- Joined: Fri May 25, 2012 10:23 am
- Location: toulouse, france
- Has thanked: 38 times
- Been thanked: 62 times
- Contact:
Re: chTimeIsInRangeX always false?
Hello,
I agree with you that calling chThdSleepUntilWindowed with prev == next is no sense.
The problem arose when next is the result of a calculation of type next = now + something,
° before patch #1060 there was no need to protect the call to chThdSleepUntilWindowed is something was 0 (and then prev == next)
° now with the patch, there is a behaviour change and one must verify that prev != next before calling chThdSleepUntilWindowed.
I say that because i had a program that suddenly stopped to work after commiting chibios 19 stable to the last version, and it tooks me some time to understand why and to protect the call to chThdSleepUntilWindowed.
So the sense of my post is this question : should the test be outside chThdSleepUntilWindowed as it need to be now, or inside, to avoid a behavior change that can conduct existing program to behave differently ?
Alexandre
I agree with you that calling chThdSleepUntilWindowed with prev == next is no sense.
The problem arose when next is the result of a calculation of type next = now + something,
° before patch #1060 there was no need to protect the call to chThdSleepUntilWindowed is something was 0 (and then prev == next)
° now with the patch, there is a behaviour change and one must verify that prev != next before calling chThdSleepUntilWindowed.
I say that because i had a program that suddenly stopped to work after commiting chibios 19 stable to the last version, and it tooks me some time to understand why and to protect the call to chThdSleepUntilWindowed.
So the sense of my post is this question : should the test be outside chThdSleepUntilWindowed as it need to be now, or inside, to avoid a behavior change that can conduct existing program to behave differently ?
Alexandre
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: chTimeIsInRangeX always false?
I decided to restore the original behavior and document it correctly.
Undone bug #1060.
Giovanni
Undone bug #1060.
Giovanni
- wurstnase
- Posts: 121
- Joined: Tue Oct 17, 2017 2:24 pm
- Has thanked: 43 times
- Been thanked: 30 times
- Contact:
Re: chTimeIsInRangeX always false?
The I2C fallback needs now some rework again.
Something like this:
Something like this:
Code: Select all
diff --git a/os/hal/lib/fallback/I2C/hal_i2c_lld.c b/os/hal/lib/fallback/I2C/hal_i2c_lld.c
index f324333dc..e3e3ec86f 100644
--- a/os/hal/lib/fallback/I2C/hal_i2c_lld.c
+++ b/os/hal/lib/fallback/I2C/hal_i2c_lld.c
@@ -94,6 +94,9 @@ static inline msg_t i2c_check_arbitration(I2CDriver *i2cp) {
static inline msg_t i2c_check_timeout(I2CDriver *i2cp) {
+ if (i2cp->start == i2cp->end)
+ return MSG_OK;
+
if (!osalTimeIsInRangeX(osalOsGetSystemTimeX(), i2cp->start, i2cp->end)) {
i2c_write_stop(i2cp);
return MSG_TIMEOUT;
@@ -105,6 +108,7 @@ static inline msg_t i2c_check_timeout(I2CDriver *i2cp) {
static msg_t i2c_wait_clock(I2CDriver *i2cp) {
while (palReadLine(i2cp->config->scl) == PAL_LOW) {
+ if (i2cp->start != i2cp->end)
if (!osalTimeIsInRangeX(osalOsGetSystemTimeX(), i2cp->start, i2cp->end)) {
return MSG_TIMEOUT;
}
\o/ Nico
Who is online
Users browsing this forum: No registered users and 59 guests