None in KDS
None in SDK.
None in PEx.
File KL05-SC.zip is outdated and has limited non-blocking functions
uTasker is an option, but not what I want.
mbed has support for FRDM-KL05, but the mbed compiler is not reliable. And it only supports the Freedom Board.
Why no support? The KL05 product has been out for a long time.
Hello
Keil MDK has KL05 support. www.keil.com/NXP
There are two examples - Blinky with and without an RTOS. They are for the KL02 and KL03 boards but using it on a KL05 ought to be easy.
As far as an RTOS: Keil RTX is now open source. RTX has a BSD license and the new RTX5 has Apache 2.1.
All sources are provided. RTX5 is on GitHub: https://github.com/ARM-software/CMSIS_5
Bob Boys
ARM
Hello BC Stewart,
Actually KL05 is very simple.
If you want to get the sample code, you can refer to KL05_SC:
FRDM-KL05Z Sample Code Package
Even it is outdated, but you still can use it.
The new KSDK didn't contain the KL05.
I don't what the other module code you want to use which is not contains in the KL05_SC.
Actually, you also can refer to KL25 for the code which KL05_SC don't have.
If you still have question about it, you also can create the question post in the community, we will help you about it.
Wish it helps!
Any further question, please just let us know.
Have a great day,
Kerry
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi
Please can you explain what the problem is with uTasker so that it is not an option?
Note that it now also allows dual operating system uTasker + FreeRTOS to run on the KL05 with the best mix of co-operative, non-block and pre-emptive behavior with optimal memory requirements.
Anything developed for the KL05 can then be run with virtually no effort on any other Kinetis (KV, KE, KEA, KM, KW or K), built with virtually any IDE/compiler - can be used together with NXP libraries where required, plus it has outlived all Freescale and NXP platforms since 2005 (InterNiche, OpenTCP, various USB stacks that have come and gone, MQX, PE, which is being phased out, etc.) and so remains constant and compatible since then and - if all continues to plan - for the next 20 years too.
Regards
Mark
Sure. Client doesn't want to use any commercial or open source
software. It has to be bare-metal. Processor Expert provided basic
peripheral initialization code which has a very small memory footprint.
But it's not included in KDS. Also, memory size of KL05 specified by
client is 8K Flash, 1K SRAM, so not much room for RTOS overhead. There
is no USB on this device, so advanced stacks are not needed.
I am very familiar with uTasker and consider it the best solution for
an embedded RTOS in more advanced MCUs.
Brad
Brad
Thanks for the clarification - yes, when 1k of SRAM is available one may well have to sacrifice luxuries to minimise the footprint. FreeRTOS is, for example, not really feasible on such a device.
One can still do a fair amount with the uTasker OS but buffers need to be kept small and RAM utilisation carefully monitored.
I do have a reference on the KEA8, which also has only 8k Flash and 1k SRAM:
http://www.utasker.com/kinetis/TRK-KEA8.html
where it runs the OS with a few application functions (buffered UART, low power modes, keyboard interrupts) including precise memory monitoring (6.23k Flash / 965 bytes SRAM used in worst case).
At the end of the day it depends on quantities - with OS the development cycle to achieve the required functionality and reliability may be much shorter. At some point - when quantity gets high enough - the silicon price saving from a chip with 16k Flash and 2k SRAM (chosen for fast design with OS) to the one with 8k Flash and 1k SRAM (no OS) will compensate the engineering time to achieve and maintain a pure bare-metal design will cut in. The question is where the cross-over is since that is difficult to estimate/predict. What should however be avoided is investing $10k in engineering to save $1k in HW costs, which unfortunately often occurs when the "big picture" is not considered.
Regards
Mark