hwtimer implementation for Freescale MKW2xDxxx

Hello RIOTers,

I tried to implement a hwtimer for MKW2xDxxx and failed.

The MCU has 4 downcounter PIT(Periodic Interrupt Timmer) 32-bit timers, PITs can be cascaded so that timer[0] acts as prescaler for timer[1]. PIT can be loaded with a start value. The timer will count down and generate an interrupt at 0. Then the start value will be reloaded and it will repeating. PITs can not run in low power modes. Apart from the fact that it is a down counter, the timer do not work in low power mode, and that bothers me.

The MCU has also one Low-Power Timer. This one is a upcounter 16-bit timer with compare register and can be configured as as Free-Running Counter (reset on overflow not on compare match). Also LPTMR can run in (very) low power modes. I tried to implement the hwtimer with LPTMR. The implementation divided (or multiply) the tick-values by 1000 and run the timer with 1kHz. But this does not work reliable.

There is also a RTC module, but it fits even less for the hwtimer.

Ideas?

Regards, Johann Fischer

Hello Johann,

I am developing for the K60 which has the same timer set up as the KW2x. The solution that I decided to go for is to let the LPTMR run at 32768 Hz and let the hwtimer use that one. It will not allow for 1 �s precision, but at least it will be able to wake the MCU from STOP modes. I have not yet made a PR from my work, but you can see the current WIP state at https://github.com/gebart/RIOT, mulle branch.

Would there be any interest in merging the K60 and the KW2x peripherals into a single Kinetis port?

See also some earlier threads regarding the Kinetis timers:

http://lists.riot-os.org/pipermail/devel/2014-November/001426.html http://lists.riot-os.org/pipermail/devel/2014-October/001219.html http://lists.riot-os.org/pipermail/devel/2014-September/001086.html

Best regards,

Joakim Gebart Eistec AB www.eistec.se

Hi Johann, hi Gebart,

first I have to say that I have not worked with any Kinetis MCU so far, so don't nail me down on details...

As far as I see it, we have a short- and a longterm solution: For now I think the using the LPTMR seems reasonable, although it only offers a single channels if I see it right. As for the offered resolution this should be fine as long as there are no drivers and/or other application code, that needs this resolution...

For the long-term we are planning/working on a new timer infrastructure substituting the hwtmer and the vtimer. One design objective is a more flexible backend that can cope with downcounting and similar, so that the PIT timers should be usable. Addressing the power-down and sleep issues of the timers and finding a generic way to deal with this is also on the requirements list... I actually expect some serious work on this starting by mid-January, so it's only a matter of time...

About merging the Kinetis implementations: I would be careful with this, as experience has shown that even MCU's from the same or very similar families have their differences in their peripherals. This is for example true for the STM CPUs, and that's why we have them separated... But as I don't know the 'Freescale World' this concern might be for nothing?!

Cheers, Hauke

Hello Hauke, Hello Gebart,

As far as I see it, we have a short- and a longterm solution: For now I think the using the LPTMR seems reasonable, although it only offers a single channels if I see it right. As for the offered resolution this should be fine as long as there are no drivers and/or other application code, that needs this resolution...

Ok, then i will continue my work with LPTMR.

For the long-term we are planning/working on a new timer infrastructure substituting the hwtmer and the vtimer. One design objective is a more flexible backend that can cope with downcounting and similar, so that the PIT timers should be usable. Addressing the power-down and sleep issues of the timers and finding a generic way to deal with this is also on the requirements list... I actually expect some serious work on this starting by mid-January, so it's only a matter of time...

The problem with PIT is, that it is not running in low power mode. Let me know when you start it, I can help you, at least with tests :slight_smile:

About merging the Kinetis implementations: I would be careful with this, as experience has shown that even MCU's from the same or very similar families have their differences in their peripherals. This is for example true for the STM CPUs, and that's why we have them separated... But as I don't know the 'Freescale World' this concern might be for nothing?!

The Kinetis MCU's peripherals are very similar (some peripheral are taken from ColdFire :-)). I think we should try it.

> Would there be any interest in merging the K60 and the KW2x > peripherals into a single Kinetis port?

@Gebart I will finish my LPTMR implementation and attach to #2059[1]. Then i will rebase it so that you can cherry-pick and test the peripheral driver (i2c, spi ...). If it works then we can start with kinetis_common. What do you think?

Johann Fischer

[1] https://github.com/RIOT-OS/RIOT/pull/2059

See my reply inline below.

Joakim Gebart Eistec AB www.eistec.se

Hello Hauke, Hello Gebart,

As far as I see it, we have a short- and a longterm solution: For now I think the using the LPTMR seems reasonable, although it only offers a single channels if I see it right. As for the offered resolution this should be fine as long as there are no drivers and/or other application code, that needs this resolution...

Ok, then i will continue my work with LPTMR.

Take a look at https://github.com/gebart/RIOT/blob/mulle/cpu/k60/hwtimer_arch.c if there is anything you can use there. It seems to be working on my board for the default example, but I have not tested it thoroughly yet.

For the long-term we are planning/working on a new timer infrastructure substituting the hwtmer and the vtimer. One design objective is a more flexible backend that can cope with downcounting and similar, so that the PIT timers should be usable. Addressing the power-down and sleep issues of the timers and finding a generic way to deal with this is also on the requirements list... I actually expect some serious work on this starting by mid-January, so it's only a matter of time...

The problem with PIT is, that it is not running in low power mode. Let me know when you start it, I can help you, at least with tests :slight_smile:

About merging the Kinetis implementations: I would be careful with this, as experience has shown that even MCU's from the same or very similar families have their differences in their peripherals. This is for example true for the STM CPUs, and that's why we have them separated... But as I don't know the 'Freescale World' this concern might be for nothing?!

The Kinetis MCU's peripherals are very similar (some peripheral are taken from ColdFire :-)). I think we should try it.

Would there be any interest in merging the K60 and the KW2x peripherals into a single Kinetis port?

@Gebart I will finish my LPTMR implementation and attach to #2059[1]. Then i will rebase it so that you can cherry-pick and test the peripheral driver (i2c, spi ...). If it works then we can start with kinetis_common. What do you think? From what I gather in the datasheets it seems like Freescale pretty much

have a library of hardware modules that they pick and match from when they create new variants of the Kinetis controllers. I think kinetis_common is a good move, at least for the peripherals, I'm guessing that some parts such as pin muxing and core clocking might need cpu- or board-specific handling. I might find some time to work on RIOT K60 stuff later tonight.

Status of my port: - My next step for the K60 is to finish the SPI implementation and test it, maybe I will be able to reuse your implementation instead of finishing the one I started a long time ago. - I have not started working on any I2C driver yet. - UART is working, but I have only tested with one module (UART1) out of five possible (UART0-4).

Best regards, Joakim

Hi guys,

maybe you can think of creating an issue like this one [1] to sync you porting efforts? It might be useful also for other people with some Freescale HW....

Regarding the `kinetis_common`: Are there actually any other differences for the kinetis CPUs then clock config and RAM/ROM sizes? Otherwise it would maybe make sense to even create just a single `kinetis` CPU and just put some different linkerscripts to it (as the clock config can be configured from the `periph_conf.h`? Don't know, so its just thinking out loud...

Cheers and looking forward to your PRs, Hauke

[1] https://github.com/RIOT-OS/RIOT/issues/1646

Hi guys,

maybe you can think of creating an issue like this one [1] to sync you porting efforts? It might be useful also for other people with some Freescale HW....

Good idea!

Regarding the `kinetis_common`: Are there actually any other differences for the kinetis CPUs then clock config and RAM/ROM sizes? Otherwise it would maybe make sense to even create just a single `kinetis` CPU and just put some different linkerscripts to it (as the clock config can be configured from the `periph_conf.h`? Don't know, so its just thinking out loud...

I am most familiar with the K60, I have only looked at the data sheets of some of the others, but I think that the main difference between the variations of the Kinetis CPU is simply that there are different numbers of each module (e.g. number of UARTs) and some modules are not included in all controllers (CAN bus for example). I guess it could be possible to use `periph_conf.h`, or similar, to differentiate between them.

Best regards, Joakim

I posted a new Issue to track the progress.

https://github.com/RIOT-OS/RIOT/issues/2188

Joakim Gebart Managing Director Eistec AB

Aurorum 1C 977 75 Luleå Tel: +46(0)70-570 66 35 joakim.gebart@eistec.se www.eistec.se