[riot-devel] kinetis common - differences between families

Joakim Gebart joakim.gebart at eistec.se
Sat Mar 14 22:24:50 CET 2015


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" <maslo at 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.gebart at 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.petersen at 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 at riot-os.org
> >>> http://lists.riot-os.org/mailman/listinfo/devel
> >>
> >>
> >> _______________________________________________
> >> devel mailing list
> >> devel at riot-os.org
> >> http://lists.riot-os.org/mailman/listinfo/devel
> > _______________________________________________
> > devel mailing list
> > devel at riot-os.org
> > http://lists.riot-os.org/mailman/listinfo/devel
>
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20150314/af58699d/attachment-0001.html>


More information about the devel mailing list