Hi,
then i am starting the timer with configuration :
Hi,
then i am starting the timer with configuration :
I am getting confusing results with your code snippet.
I am not sure what context the semaphore is taken but in my case I am doing this in the main context.
This below line is in the main context and is having a lot of latencies before it can execute. Like taking the semaphore. This is not a correct place to read delta. The correct place to read delta would be to get a counter capture from the TIMER to avoid all the overhead of interrupt latencies and latencies from semaphore handling between contexts.
But in your case, you can try to read the delta at the beginning of test_counter_interrupt_fn to get better accurate time difference than the one you are getting now. The one you are getting now adds other latencies(interrupt handlng/scheduler switch/semaphore handling etc) into the delta that you are printing.
printk("READ:%lld\n", k_uptime_delta(&time));
1. I can't read from timer interrupt, i also have a SPI read.
2. Try to use event manager and submit an event every 500 us and read the event at other modules(for example 2) and proccess some logic(try sleep for random ms)
I need to understand all the contexts in which you are doing this.
For me it seems more of the post processing latency issue when you are capturing the delta than the timer accuracy issue.
Can you give me a simplistic project to test?
Maybe it is post processing.
1. I started form EVENT_MANAGER project
2. I generate every 500 us timer event, then submit this event to two module that should process the data
3. Every 2000 samples (1 second) i print the delta of time now - previous time , so it should be 1 second.
Maybe it is post processing.
1. I started form EVENT_MANAGER project
2. I generate every 500 us timer event, then submit this event to two module that should process the data
3. Every 2000 samples (1 second) i print the delta of time now - previous time , so it should be 1 second.
Did you try to use event manager?