KL46Z: Added Sleep, LED3 and LED4 definitions, switches

[Sissors]

Sleep = KL25Z sleep (verified to work correctly)

LED3 = LED1, LED4 = LED2 (for compatibility, similar to LED3 = LED4 in
KL25Z code)

SW1 and SW3 for the two switches (SW2 is reset switch, pull-up needed in code to use them)

Extra one, also: https://mbed.org/questions/2309/spifrequency-for-KL25Z/ fixed

[bogdanm]

@0xc0170 OK then, I'll hold this pull request until all the changes you need are added.

Thanks,
Bogdan

[Sissors]

KL25 changes quite done, but mainly now so people can comment on it while I do the KL05/KL46 soonish, after that it can be pulled in :).

In general the commit shows what I did, however one point:
The LPTimer runs directly from the 8MHz crystal, and uses a /8 prescaler for that. Anyone an idea how to do that non-hardcoded? Options I see:
a. Always clock it from the internal 4MHz oscillator. It is a known, but it costs accuracy.
b. Reverse calculate the crystal oscillator from the core clock frequency, pll settings, bypass settings, etc.

[0xc0170]

Hello,

I am inclined to the b. option. Where would be this function implemented?
I wonder if this type of functions (clock related) is not needed in HAL to be added, as we can see from this commits, the following functions should be added - get SystemClock, get bus clock, get crystal freq (if any used),. To have some kind of basic clock manager? Just one file which would contain these functions. What do you say?

Regards,
0xc0170

[Sissors]

Regarding the clkdiv in PWM, yep you are correct, that one is supposed to set the prescaler. (The loop keeps dividing the PWM clock until the clock becomes roughly where it needs to be).

Your second points: I considered the CMSIS folder where the clock options are set, and also the SystemCoreClock is currently calculated. There the crystal freqs are now already defined, and core clock is calculated, so it would be easy to also include functions for bus clock and crystal freq. However I don't know if that one is supposed to be editted: https://github.com/Sissors/mbed/blob/master/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KL25Z/system_MKL25Z4.h.

One alternative would be to just add it for the KL25Z in its target hal folder. Or do you mean to add the function definitions in the common hal folder?

[0xc0170]

The cmsis system file is generated and it's template is set by standard I assume, so that one should not be changed. I also had a same though for a second when I saw those macros there that it would be easy

Create a new file in the HAL folder for each Freescale target. Thanks! This update will be welcomed by users who have different setup.

0xc0170

[Sissors]

Mainly see commit. Few notes:

When it runs its FLL on the internal 32kHz oscillator stuff won't work yet (for one, the internal 4MHz oscillator then isn't available for the interrupt timer). UART0 will now switch to external oscillator if the PLL/FLL isn't enabled, so the clock setup that runs directly on the 8MHz crystal should work completely.

And unless someone has comments on the last commit, for me this one can be pulled in: Then this is included, and unless someone else wants to copy it to the KL46Z/KL05Z stuff I will do it, but that will be in the future: Fixing the SPI frequency kinda escalated into alot more work ;)

Erik

[0xc0170]

I can apply this clock fixes to all targets, have also K20 branch with some fixes. I will need to take a closer look anyway. If you don't mind, I'll spread it to all freescale targets.

Thanks for all this commits! I consider this pull request a great improvement.

Regards,
0xc0170

[Sissors]

Sounds like a good idea :)

Now do you think bogdanm is reading these comments ;)

[bogdanm]

@Sissors Yes, bogdanm is reading these comments :) You guys know much more than me about the internal peripherals in the KL MCUs, but before merging this, I have one more question: how did you test these changes?

[Sissors]

Primary test was simple printf the baudrate/divider register values with the original library, change it, check if it stayed the same. That at least showed it stayed the same with the default implementation.

I don't have a logic analyzer, so didn't check the actual baudrate of i2c for example, then again for spi that also wasn't done in the original implementation apparantly ;). Getting bus clock, crystal clock was also just matter of printing the result. Considering printing via serial works the uart also works (at different rates).
Timing library I checked simply by letting it toggle an LED every 0.5 seconds via wait, and every second via interrupt, with standard clock setup and directly clocked on the 8MHz crystal. (Besides printf'ing the prescaler).

So it isn't extensively tested in a special setup, but still I would consider it a fairly small chance there now is a bug in it larger than the original spi clock error.\

Only 'error' I am aware of currently is that uart0 doesn't seem to work yet when running on the clock setup when it uses the FLL, however: that was also the case before, now it at least works when running directly from 8MHz, and the normal FLL setup is unusable anyway since there is no clock source for the interrupt timer. It is something I am planning to look at when I feel like it, but not really an issue to not pull this imo.

[bogdanm]

Good enough for me, thanks!