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....
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...
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
[email protected]
http://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
http://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
http://lists.riot-os.org/mailman/listinfo/devel
