Re: [riot-devel] kinetis common - differences between families
Am Sat, 14 Mar 2015 13:59:06 +0100 schrieb Jozef Maslik : Hi Jozef, > 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) We currently have the conflict in spi. The driver for the SPI at KL0x (or KW01) can simply mean spi_kl.c, etc... > 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. We have done so for uart. > 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. Coordination: "RIOT port for Freescale Kinetis CPUs": https://github.com/RIOT-OS/RIOT/issues/2188 > 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). "RIOT port for the KW01Z128 SiP", outdated, I'll update it in the next days: https://github.com/RIOT-OS/RIOT/pull/2328 > From my point of view, best option is to have one common > kinetis_family directory with all driver regardless of the family. > > Jozef > -- Johann Fischer ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] kinetis common - differences between families
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" 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 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" > 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
Re: [riot-devel] kinetis common - differences between families
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 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" 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 c
Re: [riot-devel] kinetis common - differences between families
Hi, On 03/13/15 19:59, Hauke Petersen wrote: 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. No. Code duplication is evil. It leads to regressions, features in only half the actual codefiles, ... It makes fixing bugs harder as the same bugfix has to be applied n times. It makes diffs harder to debug as one hunk will appear multiple times, with slight differences very similar to the mistakes a review is supposed to find. Rarely one developer will have all platforms available, so testing will often only be performed for the code version a developer has the board lying around, all other modifications in duplicated code being in a "should work" state. In short, duplicating (multiplying) code multiplies corresponding maintanance overhead. If the price for avoiding code duplication is a somewhat more nested folder structure, IMHO it is more than worth it. Check out "cpu/stm*/syscalls.c" as an example where "let's just copy the file for now" leads to. Those files are *mostly* identical, they could be the same file, but they do have minor differences. This is totally unnecessary code duplication with all the implied disadvantages. Kaspar ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] kinetis common - differences between families
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" 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
Re: [riot-devel] kinetis common - differences between families
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
[riot-devel] kinetis common - differences between families
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
