This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

I am looking for a timer example which can be used to time the scanned packets interval in millisecond resolution

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

Parents
  • 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 

Reply
  • 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 

Children
  • 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

  • Hello, Torbjorn
       
    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);
    to flash a LED at 1s interval, it seems works fine, but I have another thread - uart echo like below:
    K_THREAD_DEFINE(uart_write_thread_id, STACKSIZE, uart_write_thread, NULL, NULL,
    		NULL, PRIORITY, 0, 0);
    which stops working after I put the timer function.
    Could you please tell me why?
    Regards!
    Ping
     
  • 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

Related