Dave,
a bit of newbie question - I'm wondering what the thoughts behind the xxx_pins.csv , pins_defs_xxx.c|
There is going to be some need to resolve the Freescale SDK method - which allows customization of pins configuration in KDS300 v the runtime configuration (I think) of pins_defs_xxx.c
It may be possible to just compile a framework for the time being xxx_pins.csv and then decide how much to flesh out all the alternatives later.
I'm putting up the FRDM_K64F files in fslhal\boards\frdmk64f\MK64FN1M0VLL12 files
To follow the freescale method (and stmhal) probably means creating a tree
fslhal\SDK\
The SDK I think covers what is inside the processor - but not all the peripheral chips on the FRDM-K64F board
SDK\platform\devices\MK64F12\include
SDK\platform\CMSIS\include
SDK\platform\hal\inc
I'm watching the discussion on where to place the hardware definitions on github/micropython and for the moment I propose to put all the freescale files in frdmk64f to see how many and how they hang together. The disadvantage in the short term is won't be able to compare a SDK tree structure to see what has changed.
freescale doesn't support MK20DX for the SDK so headers/arduino customizations are in fslhal\boards\teensy
Does that work.?
Porting Kinetis MK64F
Re: Porting Kinetis MK64F
Initially, I was using the toolchain and the downloader from Arduino.
Eventually, I got things to the point where I could build the teensy port using the same toolchain as we use for the stmhal.
However, you still need to be able to flash the image to the teensy board. So for that, you need the teensy_post_compile and teensy_reboot programs, which are only distributed with the arduino package for the teensy.
I was able to get a hello world program (no micropython) flashed to my FRDM-K64F board by using the file system flasher that they provide. The way that this works is like how the original mbed works. The second processor (through the OpenSDA USB connector) presents a file system and you copy your .bin file ot it. It then flashes the K64F using the JTAG link.
So for the K64F we definitely don't need the arduino toolchain.
As for the pins stuff, the way that the SDK method isn't generic enough for our needs, so I imagine that we'll just ignore it (STM has similar tools for stmhal which we also don't use). The way that we use the pins, is that we have a .csv file which defines the pins for an MCU (like mk20dx256_af.csv) and then for each board we have a pins.csv file which describes the pin names for a particular board. make-pins.py then processes those and generates some C & H files which are used in the micropython build.
As for the hal, we should only copy in the fslhal files which are actually needed. We definitely don't want to put the entire sdk into the repository (that penalizes everybody else that isn't using fslhal).
I'll probably start my own branch, but I'll start with a minimal port and add stuff incrementally. I'll be travelling over the next few days, so I'll have a bit of time to play, but I'll have to wait and see.
Eventually, I got things to the point where I could build the teensy port using the same toolchain as we use for the stmhal.
However, you still need to be able to flash the image to the teensy board. So for that, you need the teensy_post_compile and teensy_reboot programs, which are only distributed with the arduino package for the teensy.
I was able to get a hello world program (no micropython) flashed to my FRDM-K64F board by using the file system flasher that they provide. The way that this works is like how the original mbed works. The second processor (through the OpenSDA USB connector) presents a file system and you copy your .bin file ot it. It then flashes the K64F using the JTAG link.
So for the K64F we definitely don't need the arduino toolchain.
As for the pins stuff, the way that the SDK method isn't generic enough for our needs, so I imagine that we'll just ignore it (STM has similar tools for stmhal which we also don't use). The way that we use the pins, is that we have a .csv file which defines the pins for an MCU (like mk20dx256_af.csv) and then for each board we have a pins.csv file which describes the pin names for a particular board. make-pins.py then processes those and generates some C & H files which are used in the micropython build.
As for the hal, we should only copy in the fslhal files which are actually needed. We definitely don't want to put the entire sdk into the repository (that penalizes everybody else that isn't using fslhal).
I'll probably start my own branch, but I'll start with a minimal port and add stuff incrementally. I'll be travelling over the next few days, so I'll have a bit of time to play, but I'll have to wait and see.
Re: Porting Kinetis MK64F
Ok thanks for the info. Great to hear you got a FRDM-K64F target operational.
How about I leave the make compiler section alone - and you are more the expert in make than I am.
I have had a number of FRDM-K64 projects work generated by the KDS3/Eclips IDE make & flashed through Eclipse Debugger OpenSDA as well as being able able to directly program it through the Eclipse Debugger multilink/JTAG so I have some basic configuration templates.
The KDS3/IDE has been pretty fantastic for demo projects - but it hides all the details - so having to work through them now.
The reference project I'm using configures the FRDM-K64F for USB dev MSD and rw to the microSD - so it configures those ports.
I'll work on getting the K64F section to startup, configure the clocks and print out on a debug port - so that should be generic starting point to play with knitting in the microPy env.
How about I leave the make compiler section alone - and you are more the expert in make than I am.
I have had a number of FRDM-K64 projects work generated by the KDS3/Eclips IDE make & flashed through Eclipse Debugger OpenSDA as well as being able able to directly program it through the Eclipse Debugger multilink/JTAG so I have some basic configuration templates.
The KDS3/IDE has been pretty fantastic for demo projects - but it hides all the details - so having to work through them now.
The reference project I'm using configures the FRDM-K64F for USB dev MSD and rw to the microSD - so it configures those ports.
I'll work on getting the K64F section to startup, configure the clocks and print out on a debug port - so that should be generic starting point to play with knitting in the microPy env.
Re: Porting Kinetis MK64F
Hi Dave
I was wondering if you had a change to look at the environment I created.
I've updated the .csv files for FRDM-K64F/MK64F
It builds in ubuntu to where it invokes the pins .py files - and then the output has a namespace collision of the peripherals - UART with the standard arm/freescale sdk.
Just wondering if you have any thoughts. ?
Cheers
I was wondering if you had a change to look at the environment I created.
I've updated the .csv files for FRDM-K64F/MK64F
It builds in ubuntu to where it invokes the pins .py files - and then the output has a namespace collision of the peripherals - UART with the standard arm/freescale sdk.
Just wondering if you have any thoughts. ?
Cheers
Re: Porting Kinetis MK64F
Hey Neil,
I have a copy of your tree and was able to do a build from it.
I just refetched it this morning, but the latest change I see is from Sept 24, so I don't think it has your csv file changes.
If you push your changes, then I can see them (could be on the same or a different branch), and I'll see if I can reproduce the problem. Perhaps email me a copy of the build errors, preferrably by running make V=1. You can email to dhylands at gmail dot com.
I have a copy of your tree and was able to do a build from it.
I just refetched it this morning, but the latest change I see is from Sept 24, so I don't think it has your csv file changes.
If you push your changes, then I can see them (could be on the same or a different branch), and I'll see if I can reproduce the problem. Perhaps email me a copy of the build errors, preferrably by running make V=1. You can email to dhylands at gmail dot com.
Re: Porting Kinetis MK64F
Well I've been digging into the startup with the micropython and I've realized it's incompatible with the Freescale KSDK USB licensing.
The USB method - serial and power - is very easy for starting a board - one cable.
A lot of skillful code has gone into making this so very simple.
The REPL serial RX/Tx char is integrally designed to the USB method. USB_LS in device mode is integral to receiving characters (though no doubt it could be redirected to only use a UART - but that is giant leap backwards).
For Freescale it turns I had missed out on some licensing conditions.
The current release of Freescale Kinetis peripheral access software is called "KDSK1.3" and at the top level there is a file "SW-Content-Register-KSDK-1.3.0.txt" which in it says
USB Description: Freescale USB stack. This is a version of the USB stack that has been integrated with the Kinetis SDK.
Author: Freescale
License: Proprietary. See Freescale EULA
LA_OPT_FSL_OPEN_3RD_PARTY_IP, Appendix A, MQX RTOS Code.
Appendix A, MQX RTOS Code
MQX RTOS source code may not be re-distributed by any FSL Licensee under any circumstance, even by a signed written amendment to this Agreement
I'm very pro the ease of use that the USB interface brings, and so until there is a Kinetis open source of USB stack (mbed?), it doesn't seem to make a lot of sense to try and port it to the Kinetis processor line.
My qu on the freescale forum is here: https://community.freescale.com/thread/376664
The USB method - serial and power - is very easy for starting a board - one cable.
A lot of skillful code has gone into making this so very simple.
The REPL serial RX/Tx char is integrally designed to the USB method. USB_LS in device mode is integral to receiving characters (though no doubt it could be redirected to only use a UART - but that is giant leap backwards).
For Freescale it turns I had missed out on some licensing conditions.
The current release of Freescale Kinetis peripheral access software is called "KDSK1.3" and at the top level there is a file "SW-Content-Register-KSDK-1.3.0.txt" which in it says
USB Description: Freescale USB stack. This is a version of the USB stack that has been integrated with the Kinetis SDK.
Author: Freescale
License: Proprietary. See Freescale EULA
LA_OPT_FSL_OPEN_3RD_PARTY_IP, Appendix A, MQX RTOS Code.
Appendix A, MQX RTOS Code
MQX RTOS source code may not be re-distributed by any FSL Licensee under any circumstance, even by a signed written amendment to this Agreement
I'm very pro the ease of use that the USB interface brings, and so until there is a Kinetis open source of USB stack (mbed?), it doesn't seem to make a lot of sense to try and port it to the Kinetis processor line.
My qu on the freescale forum is here: https://community.freescale.com/thread/376664
Re: Porting Kinetis MK64F
Sorry to resurrect a dead topic, but I have some news which might make this port viable again.
Kinesis recently released a new 2.0 version of their SDK. I grabbed a copy from their site, and found that the usb middleware stack is now licensed under simple 3-clause BSD. It's not dependent on the MQX RTOS at all.
Neil, would this news make you interested in picking up this port again? If not, would you have any objections if I started work on it myself?
Kinesis recently released a new 2.0 version of their SDK. I grabbed a copy from their site, and found that the usb middleware stack is now licensed under simple 3-clause BSD. It's not dependent on the MQX RTOS at all.
Neil, would this news make you interested in picking up this port again? If not, would you have any objections if I started work on it myself?
Re: Porting Kinetis MK64F
Hi GalenHz, sorry for not seeing your question.
Freescale seemed to have changed the license before they where purchased by Nxp, possibly because of a question I asked about it.
So I'd be interested if you have got very far with this.
I have been digging into how to have open source USB/OTG Host. OTG has a lot of layered high speed functionality - a deep pit. For USB Host to function, the requirement is a deterministic response which kinda leads to a number of separate OS tasks for USB Host classes. Also it appears that the USB Hub function is another routing layer from the host class function.
I've been chewing away under the nuttx.org for some of these functions. uP can be incorporated as an interpreter in Nuttx project, but I haven't tried it yet.
Nuttx has the USB Hub/Host architecture and working for STM32F4 Host MSC, but problematic for CDC. The enumeration algorithm is hard coded around MSC, which could be challenging. So there is a lot of good code there - but requires specific tests instance to be defined to verify/debug functions.
For Kinetis K series, the drivers are limited - based around FRDM-K64F - include ethernet, SDIO, usbdev but not usbhost. Technically porting the Freescale USB Host stack to this environment would be very scaleable.
Nuttx as a whole is a lot of functionality, POSIX OS, very scaleable, across a wide range of ARM and other processors with a difficult squirrely list server through yahoo.
The Nuttx Apps examples are pretty simplistic. I find it has a pretty narrow stability zone, but potentially very scaleable. I have had some test software running for weeks, and described some of it here http://nuttxworkflow.blogspot.com/
It is open source on https://bitbucket.org/nuttx/ with a small group of very able software engineers using it for various functions including the drone PX4 control sw, new sony audio product, and a google modular phone that has recently been cancelled.
Freescale seemed to have changed the license before they where purchased by Nxp, possibly because of a question I asked about it.
So I'd be interested if you have got very far with this.
I have been digging into how to have open source USB/OTG Host. OTG has a lot of layered high speed functionality - a deep pit. For USB Host to function, the requirement is a deterministic response which kinda leads to a number of separate OS tasks for USB Host classes. Also it appears that the USB Hub function is another routing layer from the host class function.
I've been chewing away under the nuttx.org for some of these functions. uP can be incorporated as an interpreter in Nuttx project, but I haven't tried it yet.
Nuttx has the USB Hub/Host architecture and working for STM32F4 Host MSC, but problematic for CDC. The enumeration algorithm is hard coded around MSC, which could be challenging. So there is a lot of good code there - but requires specific tests instance to be defined to verify/debug functions.
For Kinetis K series, the drivers are limited - based around FRDM-K64F - include ethernet, SDIO, usbdev but not usbhost. Technically porting the Freescale USB Host stack to this environment would be very scaleable.
Nuttx as a whole is a lot of functionality, POSIX OS, very scaleable, across a wide range of ARM and other processors with a difficult squirrely list server through yahoo.
The Nuttx Apps examples are pretty simplistic. I find it has a pretty narrow stability zone, but potentially very scaleable. I have had some test software running for weeks, and described some of it here http://nuttxworkflow.blogspot.com/
It is open source on https://bitbucket.org/nuttx/ with a small group of very able software engineers using it for various functions including the drone PX4 control sw, new sony audio product, and a google modular phone that has recently been cancelled.
Re: Porting Kinetis MK64F
I'm in the process of adding support for Teensy 3.6 (K66) using the Teensyduino code. I'll also be adding Teensy 3.5 which is k64.
I have my preproduction 3.6 booting to the REPL (usb-serial). I'm currently working on UART support.
I have my preproduction 3.6 booting to the REPL (usb-serial). I'm currently working on UART support.
Re: Porting Kinetis MK64F
Wow Nice
https://www.pjrc.com/store/teensy36.html
MK66FX1M0VMD18 ram256k eeprom4k flash1023K 2Otg Vreg 6uarts SDHC8bit 6SPI ADC16+Vref
Look forward to hearing about it and I'll put it in an order for the Teensy3.6
https://www.pjrc.com/store/teensy36.html
MK66FX1M0VMD18 ram256k eeprom4k flash1023K 2Otg Vreg 6uarts SDHC8bit 6SPI ADC16+Vref
Look forward to hearing about it and I'll put it in an order for the Teensy3.6