FreeRTOS cannot poll input pins when using vTaskDelayUntil()
up vote
0
down vote
favorite
I'm facing weird behavior with FreeRTOS code.
Especially when using vTaskDelayUntil()
and vTaskDelay()
I'm trying to read an input pin from my PIR sensor.
On the scope I see that the PIR is holding 3.3v high for at least 1 second.
The code below only reads my PIR input when I comment out the ' vTaskDelayUntil' line. As soon as I activate that line, PINC register is always 0.
Also when I'm sure there is 3.3v on my input pin.
static void TaskStatemachine(void *pvParameters)
(void) pvParameters;
TickType_t xLastWakeTime;
const TickType_t xFrequency = 100;
xLastWakeTime = xTaskGetTickCount();
for(;;)
printf("PINC.1 = %dn", (PINC & (1<<1) ));
vTaskDelayUntil( &xLastWakeTime, ( xFrequency / portTICK_PERIOD_MS ) );
What is happening here?
I changed xFrequency to different values, but without any luck.
polling freertos rtos
|
show 1 more comment
up vote
0
down vote
favorite
I'm facing weird behavior with FreeRTOS code.
Especially when using vTaskDelayUntil()
and vTaskDelay()
I'm trying to read an input pin from my PIR sensor.
On the scope I see that the PIR is holding 3.3v high for at least 1 second.
The code below only reads my PIR input when I comment out the ' vTaskDelayUntil' line. As soon as I activate that line, PINC register is always 0.
Also when I'm sure there is 3.3v on my input pin.
static void TaskStatemachine(void *pvParameters)
(void) pvParameters;
TickType_t xLastWakeTime;
const TickType_t xFrequency = 100;
xLastWakeTime = xTaskGetTickCount();
for(;;)
printf("PINC.1 = %dn", (PINC & (1<<1) ));
vTaskDelayUntil( &xLastWakeTime, ( xFrequency / portTICK_PERIOD_MS ) );
What is happening here?
I changed xFrequency to different values, but without any luck.
polling freertos rtos
Did you see the log? Seems problem in PINC, not in FreeRTOS. How to declared PINC? did you use volatile keyword?
– denis krasutski
Nov 12 at 9:04
PINC is a define pointing to the right register value. This is device specific and coming from avr/io.h
– user3411864
Nov 12 at 9:24
When removing the vTaskDelayUntil the value is updated and you can see the value of the printf changing ? With vTaskDelayUntil/vTaskDelay are the prints at the correct frequency? Can you show the declaration of PINC ?
– Stoogy
Nov 16 at 16:40
1
How much stack have you given the task? Formatted I/O functions such asprintf()
are expensive in stack terms. If you have a stack overflow, you will observe a range of non-deterministic behaviour. Including possibly this.
– Clifford
Nov 22 at 22:55
1
Rather than declaringxFrequency
, and calculating the loop invariant delay on every iteration, suggestconst TickType_t delay_ticks = 100 / portTICK_PERIOD_MS ;
– Clifford
Nov 22 at 23:09
|
show 1 more comment
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I'm facing weird behavior with FreeRTOS code.
Especially when using vTaskDelayUntil()
and vTaskDelay()
I'm trying to read an input pin from my PIR sensor.
On the scope I see that the PIR is holding 3.3v high for at least 1 second.
The code below only reads my PIR input when I comment out the ' vTaskDelayUntil' line. As soon as I activate that line, PINC register is always 0.
Also when I'm sure there is 3.3v on my input pin.
static void TaskStatemachine(void *pvParameters)
(void) pvParameters;
TickType_t xLastWakeTime;
const TickType_t xFrequency = 100;
xLastWakeTime = xTaskGetTickCount();
for(;;)
printf("PINC.1 = %dn", (PINC & (1<<1) ));
vTaskDelayUntil( &xLastWakeTime, ( xFrequency / portTICK_PERIOD_MS ) );
What is happening here?
I changed xFrequency to different values, but without any luck.
polling freertos rtos
I'm facing weird behavior with FreeRTOS code.
Especially when using vTaskDelayUntil()
and vTaskDelay()
I'm trying to read an input pin from my PIR sensor.
On the scope I see that the PIR is holding 3.3v high for at least 1 second.
The code below only reads my PIR input when I comment out the ' vTaskDelayUntil' line. As soon as I activate that line, PINC register is always 0.
Also when I'm sure there is 3.3v on my input pin.
static void TaskStatemachine(void *pvParameters)
(void) pvParameters;
TickType_t xLastWakeTime;
const TickType_t xFrequency = 100;
xLastWakeTime = xTaskGetTickCount();
for(;;)
printf("PINC.1 = %dn", (PINC & (1<<1) ));
vTaskDelayUntil( &xLastWakeTime, ( xFrequency / portTICK_PERIOD_MS ) );
What is happening here?
I changed xFrequency to different values, but without any luck.
polling freertos rtos
polling freertos rtos
edited Nov 16 at 19:38
Juraj
343310
343310
asked Nov 11 at 13:40
user3411864
1251420
1251420
Did you see the log? Seems problem in PINC, not in FreeRTOS. How to declared PINC? did you use volatile keyword?
– denis krasutski
Nov 12 at 9:04
PINC is a define pointing to the right register value. This is device specific and coming from avr/io.h
– user3411864
Nov 12 at 9:24
When removing the vTaskDelayUntil the value is updated and you can see the value of the printf changing ? With vTaskDelayUntil/vTaskDelay are the prints at the correct frequency? Can you show the declaration of PINC ?
– Stoogy
Nov 16 at 16:40
1
How much stack have you given the task? Formatted I/O functions such asprintf()
are expensive in stack terms. If you have a stack overflow, you will observe a range of non-deterministic behaviour. Including possibly this.
– Clifford
Nov 22 at 22:55
1
Rather than declaringxFrequency
, and calculating the loop invariant delay on every iteration, suggestconst TickType_t delay_ticks = 100 / portTICK_PERIOD_MS ;
– Clifford
Nov 22 at 23:09
|
show 1 more comment
Did you see the log? Seems problem in PINC, not in FreeRTOS. How to declared PINC? did you use volatile keyword?
– denis krasutski
Nov 12 at 9:04
PINC is a define pointing to the right register value. This is device specific and coming from avr/io.h
– user3411864
Nov 12 at 9:24
When removing the vTaskDelayUntil the value is updated and you can see the value of the printf changing ? With vTaskDelayUntil/vTaskDelay are the prints at the correct frequency? Can you show the declaration of PINC ?
– Stoogy
Nov 16 at 16:40
1
How much stack have you given the task? Formatted I/O functions such asprintf()
are expensive in stack terms. If you have a stack overflow, you will observe a range of non-deterministic behaviour. Including possibly this.
– Clifford
Nov 22 at 22:55
1
Rather than declaringxFrequency
, and calculating the loop invariant delay on every iteration, suggestconst TickType_t delay_ticks = 100 / portTICK_PERIOD_MS ;
– Clifford
Nov 22 at 23:09
Did you see the log? Seems problem in PINC, not in FreeRTOS. How to declared PINC? did you use volatile keyword?
– denis krasutski
Nov 12 at 9:04
Did you see the log? Seems problem in PINC, not in FreeRTOS. How to declared PINC? did you use volatile keyword?
– denis krasutski
Nov 12 at 9:04
PINC is a define pointing to the right register value. This is device specific and coming from avr/io.h
– user3411864
Nov 12 at 9:24
PINC is a define pointing to the right register value. This is device specific and coming from avr/io.h
– user3411864
Nov 12 at 9:24
When removing the vTaskDelayUntil the value is updated and you can see the value of the printf changing ? With vTaskDelayUntil/vTaskDelay are the prints at the correct frequency? Can you show the declaration of PINC ?
– Stoogy
Nov 16 at 16:40
When removing the vTaskDelayUntil the value is updated and you can see the value of the printf changing ? With vTaskDelayUntil/vTaskDelay are the prints at the correct frequency? Can you show the declaration of PINC ?
– Stoogy
Nov 16 at 16:40
1
1
How much stack have you given the task? Formatted I/O functions such as
printf()
are expensive in stack terms. If you have a stack overflow, you will observe a range of non-deterministic behaviour. Including possibly this.– Clifford
Nov 22 at 22:55
How much stack have you given the task? Formatted I/O functions such as
printf()
are expensive in stack terms. If you have a stack overflow, you will observe a range of non-deterministic behaviour. Including possibly this.– Clifford
Nov 22 at 22:55
1
1
Rather than declaring
xFrequency
, and calculating the loop invariant delay on every iteration, suggest const TickType_t delay_ticks = 100 / portTICK_PERIOD_MS ;
– Clifford
Nov 22 at 23:09
Rather than declaring
xFrequency
, and calculating the loop invariant delay on every iteration, suggest const TickType_t delay_ticks = 100 / portTICK_PERIOD_MS ;
– Clifford
Nov 22 at 23:09
|
show 1 more comment
1 Answer
1
active
oldest
votes
up vote
0
down vote
As an experiment, simplify the output thus:
putchar( (PINC & (1<<1)) == 0 ? '0' : '1' ) ;
You will then get a continuous stream of 1 or 0.
If that works with or without the delay, then it seems likely that that the task has too small a stack to support printf()
. Try increasing the stack and putting the printf()
back in.
I think you are on the right track here. How do I decide how big the stack size has to be for every task. If I increase them randomly, some tasks stop running or my whole program hangs.
– user3411864
Nov 30 at 9:07
@user3411864 : That is a different question - best post a separate question to get a wider audience, but there are already answers to similar questions on SO. It is hard to see how "too much" stack will cause a problem if you have the space. It seems more likely that you are using FreeRTOS's automatic stack allocation which allocates the stack from the heap, and you are running out of heap space. Better to usexTaskCreateStatic
perhaps, then any memory exhaustion will be detected at build time rather than run-time, which is easier to debug.
– Clifford
Nov 30 at 19:52
I have seenprintf()
implementations use as much as 4kb. When you ask the question, include information about the tool-chain you are using and the target device.
– Clifford
Nov 30 at 19:58
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
As an experiment, simplify the output thus:
putchar( (PINC & (1<<1)) == 0 ? '0' : '1' ) ;
You will then get a continuous stream of 1 or 0.
If that works with or without the delay, then it seems likely that that the task has too small a stack to support printf()
. Try increasing the stack and putting the printf()
back in.
I think you are on the right track here. How do I decide how big the stack size has to be for every task. If I increase them randomly, some tasks stop running or my whole program hangs.
– user3411864
Nov 30 at 9:07
@user3411864 : That is a different question - best post a separate question to get a wider audience, but there are already answers to similar questions on SO. It is hard to see how "too much" stack will cause a problem if you have the space. It seems more likely that you are using FreeRTOS's automatic stack allocation which allocates the stack from the heap, and you are running out of heap space. Better to usexTaskCreateStatic
perhaps, then any memory exhaustion will be detected at build time rather than run-time, which is easier to debug.
– Clifford
Nov 30 at 19:52
I have seenprintf()
implementations use as much as 4kb. When you ask the question, include information about the tool-chain you are using and the target device.
– Clifford
Nov 30 at 19:58
add a comment |
up vote
0
down vote
As an experiment, simplify the output thus:
putchar( (PINC & (1<<1)) == 0 ? '0' : '1' ) ;
You will then get a continuous stream of 1 or 0.
If that works with or without the delay, then it seems likely that that the task has too small a stack to support printf()
. Try increasing the stack and putting the printf()
back in.
I think you are on the right track here. How do I decide how big the stack size has to be for every task. If I increase them randomly, some tasks stop running or my whole program hangs.
– user3411864
Nov 30 at 9:07
@user3411864 : That is a different question - best post a separate question to get a wider audience, but there are already answers to similar questions on SO. It is hard to see how "too much" stack will cause a problem if you have the space. It seems more likely that you are using FreeRTOS's automatic stack allocation which allocates the stack from the heap, and you are running out of heap space. Better to usexTaskCreateStatic
perhaps, then any memory exhaustion will be detected at build time rather than run-time, which is easier to debug.
– Clifford
Nov 30 at 19:52
I have seenprintf()
implementations use as much as 4kb. When you ask the question, include information about the tool-chain you are using and the target device.
– Clifford
Nov 30 at 19:58
add a comment |
up vote
0
down vote
up vote
0
down vote
As an experiment, simplify the output thus:
putchar( (PINC & (1<<1)) == 0 ? '0' : '1' ) ;
You will then get a continuous stream of 1 or 0.
If that works with or without the delay, then it seems likely that that the task has too small a stack to support printf()
. Try increasing the stack and putting the printf()
back in.
As an experiment, simplify the output thus:
putchar( (PINC & (1<<1)) == 0 ? '0' : '1' ) ;
You will then get a continuous stream of 1 or 0.
If that works with or without the delay, then it seems likely that that the task has too small a stack to support printf()
. Try increasing the stack and putting the printf()
back in.
answered Nov 22 at 23:04
Clifford
57.9k858124
57.9k858124
I think you are on the right track here. How do I decide how big the stack size has to be for every task. If I increase them randomly, some tasks stop running or my whole program hangs.
– user3411864
Nov 30 at 9:07
@user3411864 : That is a different question - best post a separate question to get a wider audience, but there are already answers to similar questions on SO. It is hard to see how "too much" stack will cause a problem if you have the space. It seems more likely that you are using FreeRTOS's automatic stack allocation which allocates the stack from the heap, and you are running out of heap space. Better to usexTaskCreateStatic
perhaps, then any memory exhaustion will be detected at build time rather than run-time, which is easier to debug.
– Clifford
Nov 30 at 19:52
I have seenprintf()
implementations use as much as 4kb. When you ask the question, include information about the tool-chain you are using and the target device.
– Clifford
Nov 30 at 19:58
add a comment |
I think you are on the right track here. How do I decide how big the stack size has to be for every task. If I increase them randomly, some tasks stop running or my whole program hangs.
– user3411864
Nov 30 at 9:07
@user3411864 : That is a different question - best post a separate question to get a wider audience, but there are already answers to similar questions on SO. It is hard to see how "too much" stack will cause a problem if you have the space. It seems more likely that you are using FreeRTOS's automatic stack allocation which allocates the stack from the heap, and you are running out of heap space. Better to usexTaskCreateStatic
perhaps, then any memory exhaustion will be detected at build time rather than run-time, which is easier to debug.
– Clifford
Nov 30 at 19:52
I have seenprintf()
implementations use as much as 4kb. When you ask the question, include information about the tool-chain you are using and the target device.
– Clifford
Nov 30 at 19:58
I think you are on the right track here. How do I decide how big the stack size has to be for every task. If I increase them randomly, some tasks stop running or my whole program hangs.
– user3411864
Nov 30 at 9:07
I think you are on the right track here. How do I decide how big the stack size has to be for every task. If I increase them randomly, some tasks stop running or my whole program hangs.
– user3411864
Nov 30 at 9:07
@user3411864 : That is a different question - best post a separate question to get a wider audience, but there are already answers to similar questions on SO. It is hard to see how "too much" stack will cause a problem if you have the space. It seems more likely that you are using FreeRTOS's automatic stack allocation which allocates the stack from the heap, and you are running out of heap space. Better to use
xTaskCreateStatic
perhaps, then any memory exhaustion will be detected at build time rather than run-time, which is easier to debug.– Clifford
Nov 30 at 19:52
@user3411864 : That is a different question - best post a separate question to get a wider audience, but there are already answers to similar questions on SO. It is hard to see how "too much" stack will cause a problem if you have the space. It seems more likely that you are using FreeRTOS's automatic stack allocation which allocates the stack from the heap, and you are running out of heap space. Better to use
xTaskCreateStatic
perhaps, then any memory exhaustion will be detected at build time rather than run-time, which is easier to debug.– Clifford
Nov 30 at 19:52
I have seen
printf()
implementations use as much as 4kb. When you ask the question, include information about the tool-chain you are using and the target device.– Clifford
Nov 30 at 19:58
I have seen
printf()
implementations use as much as 4kb. When you ask the question, include information about the tool-chain you are using and the target device.– Clifford
Nov 30 at 19:58
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53249321%2ffreertos-cannot-poll-input-pins-when-using-vtaskdelayuntil%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Did you see the log? Seems problem in PINC, not in FreeRTOS. How to declared PINC? did you use volatile keyword?
– denis krasutski
Nov 12 at 9:04
PINC is a define pointing to the right register value. This is device specific and coming from avr/io.h
– user3411864
Nov 12 at 9:24
When removing the vTaskDelayUntil the value is updated and you can see the value of the printf changing ? With vTaskDelayUntil/vTaskDelay are the prints at the correct frequency? Can you show the declaration of PINC ?
– Stoogy
Nov 16 at 16:40
1
How much stack have you given the task? Formatted I/O functions such as
printf()
are expensive in stack terms. If you have a stack overflow, you will observe a range of non-deterministic behaviour. Including possibly this.– Clifford
Nov 22 at 22:55
1
Rather than declaring
xFrequency
, and calculating the loop invariant delay on every iteration, suggestconst TickType_t delay_ticks = 100 / portTICK_PERIOD_MS ;
– Clifford
Nov 22 at 23:09