Hey, On 07/10/15 10:32, Simon Vincent wrote: > Currently the issue I get with multiple timers is that calls to > hwtimer_arch_now do not specify a timer. So you call hwtimer_arch_now > and get a value. If you then use this to set a delay there are problems > as when you request this delay it could use a different hwtimer. This > currently occurs in vtimers. hm, did you implement hwtimer for your architecture? The implementation should use only timers that run at the same speed.
>> In order to harmonize platforms, if possible make one timer, preferably >> timer 0, run at 1MHz. > What if my platform does not have a 1MHz timer? Is there going to be > problems? No. Right now, wtimer is just missing support for that. >> Check PR #2926 to see where we're headed. > Ok I will have a look. When do you think it will ready? I'd say, until it is the default timer in master, a couple of weeks. I hope to have it ready as experimental drop-in-replacement before the IETF (next week). >> May I ask which platform you are porting to? > Currently I am porting to the Zynq 7000 which contains a Arm Cortex A9. Very interesting! If possible, please let as see the code. ;) > Currently I have implemented as the periph/timer the three 16-bit timers > running at 0.78MHz (closest I can get to 1MHz). This works well using > hwtimers for short delays but vtimer does not work at all as the timers > overflow too quickly. You could try to fake 32bit timers (in software or by combining two timers). If you only need the timer for your application, take a look at #2926. wtimer has support for 16bit timers and handles overflows a lot better. Kaspar _______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
