On 12/12/2014 04:51 PM, Hauke Petersen wrote: > 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 > > Cheers and looking forward to your PRs, > Hauke > > [1] https://github.com/RIOT-OS/RIOT/issues/1646 > > > > On 12.12.2014 14:57, Joakim Gebart wrote: >> 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 > > _______________________________________________ > 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
