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.geb...@eistec.se www.eistec.se On 12/12/2014 08:56 PM, Joakim Gebart wrote: > 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 >>>> devel@riot-os.org >>>> http://lists.riot-os.org/mailman/listinfo/devel >>> _______________________________________________ >>> devel mailing list >>> devel@riot-os.org >>> http://lists.riot-os.org/mailman/listinfo/devel >> _______________________________________________ >> devel mailing list >> devel@riot-os.org >> http://lists.riot-os.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
