[riot-devel] kinetis common - differences between families

Joakim Gebart joakim.gebart at eistec.se
Sat Mar 14 09:49:54 CET 2015


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


More information about the devel mailing list