Fix-timer-sdk

[FrancescoPoluzzi]

• Fixed timer SDK (that was not working in WFI).
• Added timer function for inirtializing timer to measure time in microseconds instead of cycles .
• Added fuction for waiting a specific amount of time.
• Added function for enabling timer interrupts.
• Extended example_timer_sdk application.

[davideschiavone]

@JuanSapriza can you pls test it?

[JoseCalero]

I did not run the app, just checked the code. Some comments:

General:
Having the same code organization and practices done for all the SDK and HAL files would be nice (and preferred). There are different HAL layers that have been completely refactorised based on this: DMA, FIC, PLIC, SPI, GPIO. Moreover, I recommend following also the SPI SDK which was done following such code practices of the refactorised HAL layers. Finally, please, when adding a new layer that is supposed to be used by users that are not experts, then we need to create their respective documentation --> please check the documentation already created for the DMA and for the SPI in our readthedocs. Additionally, doing the SDK is great and I am sure this SDK is gonna be used a lot!, but it would be nice to do the HAL refactorization first if it is not done before going to tackle the SDK. For instance, right now in the SDK you are declaring <mmio_region_t timer_base>--> why are you declaring this? you are already having the base address automatically generated and link to a DEFINE in the <rv_timer_structus.h> --> the answer is because you have the old HAL (not redisgned/refactorised) and so it is working based on the mmio based address struct, which is fine, but it is not as the last modified FW drivers. It is a matter of being coherent with the rest of the things we use for the other peripherals.

Functionality:
I do not fully understand the current behaviour. So at the very beginning, hw_timer_value, is '0'. Then when we start the time, which is counting upwards. First, actually when you do timer_cycles_init() you are already starting the timer because you are doing rv_timer_counter_set_enabled(&timer, 0, kRvTimerEnabled) into it. So, that is not just init, but also starting. Then, I guess that you substract when calling your starting function because the timer is already started and you want to, ideally, reset the cycle counter (your variable). Then, my main question is: is there any corner is which you could be running into overflow problems? i know that the HAL is tackling the overflow when reading the counter register (lower and upper parts), but you are adding another cycle counter variable on top of that. The other thing is that --> why do you need to have the timer ALWAYS running since the moment that you init? i mean... the normal thing is to init and then to run it when you want to really count, isn't it?
Then, a SDK should be abstracting some HW things... for example: in your case image that you call timer_arm_start(1000), but you did not call timer_irq_enable(), then what is gonna happen is that you will be waiting forever basically. Then, the SDK should be able to handle that, as one of the main purposes of it is to reduce the need for HW knowledge form an user point of view. By the way, another thing that is happening right now is that from a HW point of view when you use the comparator and wait for the interrupt:
timer_cycles_init(); timer_irq_enable(); timer_arm_start(1000); timer_start(); asm volatile ("wfi"); // Wait for interrupt timer_cycles = timer_stop();

you are starting the timer from the very first line --> is that OK?