Page 1 of 1

Best way to measure serial communication Latency | way to collect latencies in the program

Posted: Wed Apr 24, 2019 8:18 pm
by Jivrik
Hi,


Please what would be the best way to measure the latency that any process could consume during the execution of program?


For example, what I am currently doing is adding timestamps before and after the procedure that I want to verify. Then the timestamps differences are the latency that I should be looking for. The timestamps values come from the pyb.micros() funcition. So, in the code below:

Code: Select all


    t_0 = pyb.micros()
    img = sensor.snapshot()
    #break
    t_1 = pyb.micros()
    diff =  t_1 -  t_0

    show_process_timing(t_0,t_1,"Init Snapshot")


The init snapshot is the id of the process that I want to verify. Please here is here is the implementation of the show_timing_process() function

Code: Select all


def show_process_timing(t_x , t_y , id_pos):
    print("\n{}".format(id_pos))
    print("\nDifference: {} us\n".format(t_y - t_x))



Should I rely on the values returned by the pyb.micros() function?


Also How would you evaluate the delay taken by an SPI , I2C or a UART transaction?




Thank you!



Benjamin.

Re: Best way to measure serial communication Latency | way to collect latencies in the program

Posted: Thu Apr 25, 2019 1:42 am
by kwagyeman
Yeah, this is pretty much valid.

As for the UART/SPI. The main thread waits until the data is sent. So, it's fine to put a timer around any call.

Re: Best way to measure serial communication Latency | way to collect latencies in the program

Posted: Thu Apr 25, 2019 8:30 pm
by Jivrik
Thank you.

I have this concern, is it normal that the UART transaction becomes faster than the I2C transaction?

if yes, How come?

Re: Best way to measure serial communication Latency | way to collect latencies in the program

Posted: Sat Apr 27, 2019 2:06 am
by kwagyeman
Hi, microcontrollers usually communicate to each other via UARTs. SPI and I2C are for communication to more simple hardware chips typically.

In terms of coding... when using the OpenMV Cam you have a camera sensor that's doing work. If you write your code to wait for I2C bus access always then no work can be done. The UART allows bytes to be received asynchronously however. SO, you can process bytes in a loop while doing vision stuff too and then send out results.