See my reply inline below. Joakim Gebart Eistec AB www.eistec.se
On 12/12/2014 02:36 PM, Johann Fischer wrote: > 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 :-) > >> 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 > > Johann Fischer > > [1] https://github.com/RIOT-OS/RIOT/pull/2059 > _______________________________________________ > devel mailing list > [email protected] > http://lists.riot-os.org/mailman/listinfo/devel _______________________________________________ devel mailing list [email protected] http://lists.riot-os.org/mailman/listinfo/devel
