Dear All
Could you point me a timer example, can be used to time the interval in ms between something? like read the system time when something happens and then read again when it happens again?
Thank you!
Ping
Dear All
Could you point me a timer example, can be used to time the interval in ms between something? like read the system time when something happens and then read again when it happens again?
Thank you!
Ping
Hi Ping
You should be able to use the k_uptime_get() or k_uptime_get_32() functions for this. They will return the number of milliseconds that have passed since the system booted, either as a 64-bit or 32-bit value, and if you call this twice and compare the two values you can see how much time has passed.
Best regards
Torbjørn
Hi Ping
You should be able to use the k_uptime_get() or k_uptime_get_32() functions for this. They will return the number of milliseconds that have passed since the system booted, either as a 64-bit or 32-bit value, and if you call this twice and compare the two values you can see how much time has passed.
Best regards
Torbjørn
Thanks, Torbjorn
That works fine.
I also need to create a timer to do a periodic task like blink a LED, I don't want to use k_sleep() , what is the best way to do it please?
I am sorry keep asking you the small questions like this, but I am new to Zephyr.
Thanks
Ping
void my_work_handler(struct k_work *work) { /* do the processing that needs to be done periodically */ gpio_pin_set(dev, PIN, (int)led_is_on); led_is_on = !led_is_on; } K_WORK_DEFINE(my_work, my_work_handler); void my_timer_handler(struct k_timer *dummy) { k_work_submit(&my_work); } K_TIMER_DEFINE(my_timer, my_timer_handler, NULL);
K_THREAD_DEFINE(uart_write_thread_id, STACKSIZE, uart_write_thread, NULL, NULL, NULL, PRIORITY, 0, 0);
Hi Ping
It is very odd that running the timer would cause your thread to stop functioning.
Does it matter if you start the timer or not, or if you submit the work item or not?
Would you be able to share your main file with me, so I can see what your thread is doing?
I can make this case private if you don't want to share your code in a public case.
Best regards
Torbjørn
Hi, Torbjorn
Thanks for your help, I tried the timer again and I think I have found a bug in my UART thread. It seems working fine now.
I also tried the below thread for blink LED like the Thread sample:
void blink0(void) { while(1) { k_sleep(K_SECONDS(1)); gpio_pin_set(dev, PIN, (int)led_is_on); led_is_on = !led_is_on; } } K_THREAD_DEFINE(blink0_id, STACKSIZE, blink0, NULL, NULL, NULL, PRIORITY, 0, 0);
Wonder what is the difference between two implements - the timer one and above thread one, my UART thread is similar to above blink0 , in terms of priority, are they same?
Regards!
Ping
Hi Ping
Any callbacks that you schedule through the k_work_submit(..) call will be handled by the system workqueue, which is handled by a dedicated system workqueue thread.
The practical difference of running your own dedicated thread is not very large, but every thread you create requires quite a bit of memory, so there is some memory overhead of using more threads.
Usually it makes sense to use a dedicated thread if you are planning to do a lot of time consuming tasks, or if you need to be able to prioritize different parts of your application.
All the items in the system workqueue will by default run at the lowest priority, and if you schedule multiple callbacks then they will be handled in a first in first out manner. For this reason it is not a good idea to use sleep functions or other slow, blocking function calls in a work item, since it will delay the processing of all the other work items.
If you make your own thread then any blocking call or delay will only block that thread, and not affect other parts of the system.
When you make your own thread you can also decide the priority of each thread.
All items on the system workqueue will have the same priority, but if you want you can change this priority by changing the SYSTEM_CONFIG_PRIORITY configuration.
Best regards
Torbjørn