For the kw01 you should look at the PR that the Phytec guys are working on (Johann Fischer and Jonas Remmert et.al.) which can be found at https://github.com/RIOT-OS/RIOT/pull/2328
Best regards, Joakim On Mar 14, 2015 2:00 PM, "Jozef Maslik" <ma...@binarylemon.com> wrote: > Hi, > > @Joakim, It is not easy question :) > > In short, we can say, there are differences between families based on core > type but it is not true for all options. MCUs with core Cortex M4 have > different modules compare to Cortex M0+ and here is difference compared to > L0x family which use some modules from FSL 8bit parts (SPI, UART, timers…) > > Some example with major differences: > SPI has min 3 variants: DSPI (K family), SPI (L, M family), SPI(L0x family) > UART has min 3 variants: 1. K, M family, 2. L family, 3. L0x family > low power UART is in L families (except L0x) > > Some functionality (as @Joakim wrote) can be handled by conditional > compilation like KINETIS_UART_ADVANCED, but I think, some extended > functionality can be omitted because it is not interesting for our use case. > > But I think, best way is to say, which families are interesting for RIOT > OS and compare only these. Maybe wiki page can be helpful for this task. > > At this moment, I’m working with Cortex M0+ families (which are not > supported on RIOT yet) - I have port on KL02 and in future I want to do > port for KW01 (if someone else do not do it). > > From my point of view, best option is to have one common kinetis_family > directory with all driver regardless of the family. > > Jozef > > > On 14 Mar 2015, at 09:49, Joakim Gebart <joakim.geb...@eistec.se> wrote: > > > > We have used some conditional compilation in drivers where the > > differences have been somewhat manageable. See the UART driver for > > example. If the entire module is different then I guess I would prefer > > to have two separate C-files for the two solutions rather than forking > > the entire kinetis_common directory, because there are still many > > other modules which are the same between the processors. We have used > > such an approach for the RNGA, RNGB modules which are two different > > RNG modules which are present in the Kinetis processors. In the long > > run I think we will benefit more from each others' work if we try to > > keep all of the Kinetis code concentrated to one directory. If you > > look at the stm32fx cpu implementations you will find that there are > > some features only implemented in one of them and it is difficult to > > say which one is most up-to-date since different developers are using > > different CPUs to test their design and then they don't always port it > > to the other CPUs within the same family. > > > > Jozef: Do you know which modules are different and will need new > > drivers rather than only cpu-conf.h modifications? > > > > Below is a list of the currently implemented hardware drivers, as far > > as I know, they are fully functional on K60, KW22 (K20 with built-in > > transceiver), KW02 (based on some K0x, with built-in transceiver), and > > another K20 (unknown exact model): > > - ADC > > - CPUID (called UID in SIM module reference manual) > > - GPIO > > - hwtimer (uses LPTMR module) > > - I2C > > - MCG (supports all of PLL, FLL, fast and slow internal ref) > > - PWM (uses FTM module) > > - RNGA > > - RNGB > > - RTT (RTC module) > > - RTC (wrapping RTT) > > - SPI (DSPI module) > > - Timer (PIT module) > > - UART (conditionally compiling for some extra features present in > > the K60, K20, but not present in the KW0x, via #define > > KINETIS_UART_ADVANCED) > > > > Out of the supported CPUs, the KW0x is the oddest one since that has a > > M0+ core instead of an M3/M4. > > > > Best regards, > > Joakim Gebart > > Eistec AB > > www.eistec.se > > > > On Mar 13, 2015 7:57 PM, "Hauke Petersen" <hauke.peter...@fu-berlin.de> > wrote: > >> > >> Hi Jozef, > >> > >> I have to say I was more or less expecting these slight differences... > >> > >> The RIOT way to go would be option 3. This is already done for the > STM32Fx CPUs. > >> > >> Of course this leads to some duplication of code, but in the end it > leaves the overall folder structure very clean and it is always clear, > where the code you are currently building is coming from. In my opinion a > finer grained dependency-tree like kinetis-common -> kinetis-k-common -> > k60 on so on would lead to a structure that is as hard to maintain as some > duplicated code... > >> > >> @gebart and @jfischer: would that solution work for you? > >> > >> Cheers, > >> Hauke > >> > >> On 13.03.2015 19:47, Jozef Maslik wrote: > >>> > >>> Hi, > >>> > >>> How we want deal with the difference between variants of peripherals > in Freescale Kinetis families (I mean, what is RIOT OS prefered way)? Here > is difference between families - for example between K family vs L family. > And if I remember correctly ;), there can be difference between specific > chips in same family, too. > >>> > >>> For example SPI, kinetis_common contain driver spi.c but module on K60 > is different compare to KL02 or KL10, etc. > >>> Here can be few options (minimal three ;)): > >>> 1. rename spi.c to real module name, at this situation it can be > “DSPI” for K family and “SPI” for L family. > >>> - exact name for K60 SPI module is “DSPI", then rename spi.c to dspi.c > solve this major issue > >>> - module name for SPI on L family is simply “SPI” > >>> - I prefer this solution… > >>> > >>> 2. conditional compilation for different MCUs (one spi.c file) > >>> - this will be mess in code, because modules are too much different > >>> - I do not like this solution > >>> > >>> 3. another “common” directory - for each family > >>> - this can produce code duplication > >>> > >>> Regards, > >>> Jozef > >>> _______________________________________________ > >>> 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 >
_______________________________________________ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
