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.
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:
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?!
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
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?
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...
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
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).
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...
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.
