Porting Kinetis MK64F

[neilh20]

I'm investigating porting to the Freescale/NXP Kinetis FRDM-K64F (proc MK64FN1 196Kram 1Mflash stdPerip USB+SDcard + ethernet )
and then a custom board with MK26FN2 (256kram 2Mflash USB*2 stdPerip+SDcard++) .
I'm really impressed with @dhylands's port to Teensy as its something I know about and working through it - though the overall micropython/STMHAL blows my mind and for its great ideas. Wow thanks for open sourcing it.

I'm looking at uPy for its customizing capability for scientists (and citizen scientists/makers) interfacing to outdoor environmental sensors
so having low power, powered by battery/solar is critical - the reason for Kinetis processor and that I have a board already.
The core of the python is to be be able to easily process ASCII command strings over the serial ports (USB and UART/RS232) and some local port control,
however it also needs to have an OS - probably FreeRTOS - with apps for managing the core realworld events.
I was thinking of starting from the teensy3/MK20DX256 code, creating a minimal machine and then adding back in the functions.
The KDS3 (Kinetis Design Studio3 / Eclipse - http://mcuoneclipse.com) is comprehensive for HAL interfaces -
protoyping access to peripherals and low power clock management framework.
- the microPython make structure works for multiprocessor projects, so I was thinking of a directory structure

Code: Select all

py
stmhal
teensy
kinetis-<processor>
       -<board eg FRDM-K64F>
        -<OS eg FreeRTOS>
        -<customApps invoked from board startup>

It seems this board/processor is being discussed with the wider STM Hal and evolution of the core pyBoard.
<OS FreeRTOS> really belongs at an equal level to Kinetis but is more custom.
The make would be initiated at the <board> and it could have an option for including the CustomApps/FreeRtos.

I was wondering if there where any thoughts on file structures and what might be usefull for possible acceptance back to the main tree.

[dhylands]

Interesting.

There are actualy 2 teensy ports. The very first one was before the pyboard was released and the peripheral API changed quite a bit,

I redid some of it (Timers, Pins) by reusing a bunch of the files from stmhal and creating an mphal layer. I've been waiting for my UDOO-Neo which has a linux core alongside a Cortex-M4 core (i.MX 6SoloX).

The MK64FN1 MCU looks much nicer than the one on the Teensy (lots more RAM/Flash). I couldn't find the SDK specifically for that chip/board (EDIT: Nevermind - I found it). Is there a similar SDK for the MCU used on the teemsy? That would make fleshing out the port much easier.

Is the SDK based on mbed? I wasn't very impressed with the peripheral support in mbed.

I'd probably look at the WiPy port to see how the FreeRTOS stuff was done (IIRC it also uses FreeRTOS).

[pythoncoder]

@dhylands Are you planning to port MicroPython to the UDOO-Neo coprocessor? It looks a great bit of kit. I do wonder how the two processors arbitrate between the onboard peripherals - there seems to be a lack of detailed tech info but perhaps I've missed it?

[dhylands]

I need to learn a bunch more about it. It looks like the M4 and the A9 share the same bus (not much different than a dma controller). The peripherals would need to be cooperatively shared between linux and the M4. So it will be interesting to see what they've done. It also looks like they expect you to run some type of os on the M4.

[neilh20]

There are actualy 2 teensy ports. The very first one was before the pyboard was released and the peripheral API changed quite a bit,

I'm looking for the most compatibility with micropython so going with your standard release - the linker files, vector map and a few other things change. The KDS300 produces the processor core files that can be copied across

The MK64FN1 MCU looks much nicer than the one on the Teensy (lots more RAM/Flash). I couldn't find the SDK specifically for that chip/board (EDIT: Nevermind - I found it). Is there a similar SDK for the MCU used on the teemsy? That would make fleshing out the port much easier.

The MK64FN1 has the benefit of standard implementation on FRDM-K64F board that has examples supported on the KSDK and mbed. Examples are a great starting point, especially with all the ARM clocking tripwires and hardfaults if you stray from the straight and narrow.
MK20DX seems to be in mostly the historical capacity - ie freescale is not a software company promoting continuity and compatibility, its promoting its latest and greatest silicon rollout. Paul's port to the Teensy3 is fantastic, creating a Cortex-M3 SOM that just works, and still great value for the device, arduino environment and support.
The MK26FN2 has two USBs Otg, with two sources of 5V for the onboard regulator. The PLL can boost the clock to 180MHz or put it to deep sleep down to uAs with the RTC running and onboard 5V regulator powered down. So can be powered from USB and/or directly off an environmentally safer LiFePO4 rechargeable battery.
It has 16 Touch sensor that can be built into the PCB for human interactions and wakeing it.
I'm planning on blogging about the final board through http://envirodiy.org/

Is the SDK based on mbed? I wasn't very impressed with the peripheral support in mbed.

The Freescale Kinetis SDK is a collection of HAL and device drivers for all the family of processors - so its a mess getting to the target processor and hell determining just what is supported for current processors/peripherals. https://community.freescale.com/docs/DOC-103288
KDS3 (Kinetis Design Studio) IDE IMHO is useful to build a BoardSupportPackage (BSP) by specifying a processor and then peripherals & pin muxing. This works well to define the BSP. An IDE helper "Processor Expert" can be used to define the options - particularly useful for clocking and power states and pin muxing functions.
The SDK does occasionally have some real gems mostly its just infrastructure, Freescale is a silicon company - and they release their software like a silicon "WaterFall" schedule - so it is what it is. For building a BSP for a specific processor it is fantastic, and then need to move away from the KDS IDE and its support idiosyncrasies to more of a stable IDE - http://mcuoneclipse.com/2015/09/04/new- ... launchbar/

I'd probably look at the WiPy port to see how the FreeRTOS stuff was done (IIRC it also uses FreeRTOS).

Ok thanks. I see the WiPy is on the hot release list - is there any visibility yet on how FreeRTOS fits in. Do you have a reference for IIRC.
I saw the STMCube literature is referencing FreeRTOS
it is one of the OS that Freescale supports
Erich Styger has a number of entries on using FreeRTOS http://mcuoneclipse.com/?s=FreeRTOS&submit=Search

[dhylands]

I've never used an IDE for embedded stuff. I'm more of a Makefile and editor person.

I placed a DigiKey order yesterday, so I threw in a FRDM-K64F board.

[neilh20]

For the FRDM-K64F you may need to update the firmware - there is an MK20DX in the FRDM-K64F that does the debugging through OpenOCD to manage the MK64FN
http://mcuoneclipse.com/2014/11/01/illu ... -firmware/
(OpenOCD is only Open hardware - the software done by P&E is proprietary)
For a first project you could download frdmk64_usb_msd.zip from
https://community.freescale.com/thread/353811 - and creates a USB MSC disk that reads from the uSD card.
- its very quick to import if you already have the KDS3 setup -
(from KDS3) File-Import-General-Existing Projects into Workspace-Select archive file- browse frdmk64_usb_msd.zip
I'm still looking for an HOST CDC example.
My pyBoard arrived today:) so I'm looking to test the USB HOST CDC on it.

I've never used an IDE for embedded stuff. I'm more of a Makefile and editor person.

Hmm its interesting. When it works it seems to be fantastic as the PE (ProcessorExpert) is the manual on the screen - which works very well for calculating tradeoffs. I'm still learning it - so I choose the FRDM-K64 as the basic project has 5 clocking modes defined - for power management. Now take an interface UART baud rate and you want to have the UART in some of those clocking modes (not say sleep) - the PE does all the calculating and defines an interface to then update the hardware. The GUI allows a visual play between the components and allows configuration of say what clocking modes can support the desired baud rate. At the end of it press a button and generates the HAL.
Also if pushing the silicon to its limit - different max clock rates apply to CORE, FLASH, RAM etc - and these have to be configured. Complicated. I'm still figuring it out but an overview is here http://mcuoneclipse.com/2014/06/14/frdm ... f-120-mhz/

I was just reviewing the stmhal structure and how it applies to the fslhal (freescale hal ) - and its somewhat similar - so the way the different boards build under stmhal makes sense.
One slight issue so far is that fslhal is defined by a KSDK (Kinetis SDK) currently 1.2, which doesn't support the MK20DX. Instead it has some other directory structures. KSDK supports MK64FN and MK26FN (from KSDK 1.2) are supported

However thats why I posted about the KDS3 being for BSP creation - I'm heading back into the micropython Make and with the project structure already defined it looks much easier to bring in the structures from the KDS3 created specific processor HALs. Still trying it.
For an analysis of the fsl_hal Prof Eric Styger of Lucerne Uni has been a promoter and critic.
http://mcuoneclipse.com/2015/07/08/tuto ... -sdk-v1-2/
This is a simpler intro
http://mcuoneclipse.com/2015/07/30/to-w ... netis-sdk/
This is an interesting tutorial on how to dive through the GUI to the hardware and create a simple interface (the TeensyLC & Paul might have got a library for the WS2812b out first)
http://mcuoneclipse.com/2015/08/03/tuto ... -concepts/

[neilh20]

I've created a fslhal - and I thought it was going to https://github.com/neilh10/micropython.git [edit] oops need a git commit[/edit]
It follows stmhal for multiboard - compiles and links two boards - just to try it.
cd stmhal
make BOARD=teensy
make BOARD=frdmk64f

The frdmk64f builds and links with a MK64FN memory map, but has had no MK64FN code customization yet.

[dhylands]

I don't see any commits from you in https://github.com/neilh10/micropython Did you push your changes? Once you commit them into your local repository, you need to push them to github in order for anybody else to see them.

You wouldn't have been able to push to github.com/micropython since you don't have priviledges to push there (neither do I).

[neilh20]

you need to push them to github in order for anybody else to see them.

Thanks that did it. A bit rusty on git-tering.
Well thats an amazing Make script - haven't worked through a make like that for eons if ever- what I tried to do was adapt it for multi-board and used the teensy as a starting point since its all Kinetis processors.
I'm making no assumptions about what might be acceptable - so I be happy for any feedback as to what you think might be a way ahead.
If you think its better to keep teensy separate I'm happy to take it out.
The link process has put sections together that look in the right ball park from the sections size parameters generated afterwards.
For the real code that tickles the FRDM-K64F I still need to change the board interface and propose to move all the boards specific parameters to
fslhal/boards/frdmk64f
fslhal/boards/teensy
So I need to understand and update
fslhal/boards/frdmk64f/teensy_pins.csv
The KDS300 project generates these files for the FRDM-K64F

Code: Select all

 board.c
  board.h
  gpio_pins.c
  gpio_pins.h
  hardware_init.c
  pin_mux.c
  pin_mux.h

which I will try and place in
fslhal/boards/frdmk64f/
and keep the basic structure as they are generated by KDS300 when registers functions are tweaked.
I have more experience of the arduinio teensy port structures than the way KDS300 generates it, and the nutter is freescale have changed it again with the "components" KSDK1.2 paradigm.
I guess there is an ARMs race going on between ARMs licensees.