I created my first MQX_KSDK project with PE on a TWR-K65F180M board following this great tutorial:
https://community.freescale.com/docs/DOC-103429
I am using KDS 3.0.0 and KSDK 1.3.0.
I selected MQX Standard in the MQX_KSDK Configuration parameters.
Now I see the systick timer is configured with a 5 ms period. I would like a 1 ms systick, but the systick timer (fsl_hwtimer) configuration is unchangeable. Why? It is not allowed to modify the fsl_hwtimer_InitConfig0 configuration nor to add a new one.
In the fsl_hwtimer1.h file generated by PEx the macro FSL_FSL_HWTIMER1_PERIOD_CNF0 is set to 5000: I think the systick timer period in microseconds is set with this macro, right?
Is manually changing that macro the only way to get the desired systick period for MQX RTOS component ?
The MQX RTOS component also inherits one UART as debug console.
What if my custom board has no available UART to assign as debug console?
I think it is better a RTOS componenet that inherits only the systick timer with a changeable configuration (tick period) and optionally a debug console UART (which is already configurable in baud rate and hardware pins; but what if I have only a RS485 serial port on my custom board?)
已解决! 转到解答。
Hi Alessandro,
Let me answer your questions first then I will add a comment or two.
Q1) In the fsl_hwtimer1.h file generated by PEx the macro FSL_FSL_HWTIMER1_PERIOD_CNF0 is set to 5000: I think the systick timer period in microseconds is set with this macro, right?
A1) No and yes ;-). No that the this is not the correct method to modify the systick timer period and yes it is a MACRO PE generates. But for MQX it is not used! Go figure...
Q2) Is manually changing that macro the only way to get the desired systick period for MQX RTOS component ?
A2) The answer would be yes if the macro were used...but it is not for MQX. If it were being used by MQX then you could have manually changed it and then disabled the fsl_hwtimer from Code Generation by right clicking the component and saying "Don't write Generated Component Modules". But since this macro is not used you don't need to do that.
Q3) The MQX RTOS component also inherits one UART as debug console.
What if my custom board has no available UART to assign as debug console?
A3) when you use KSD/KSDK+PE and select MQX as the RTOS, you want to remove the fsl_debug_console Component as it is not needed with MQX. Then in the wizard for the MQX_KSDK Component, have the Inherited components debug console select "KSDK 1.3.0/fsl_uart". You can then configure that fsl_uart Component to use whatever UART you want.
Comment:
No idea why PE wouldn't be used to change the systick value. Maybe next release of KDS/KSDK will allow that.
To change the systick to 1ms do the following:
In bsp_config.h make the following modifications:
#ifndef BSP_ALARM_FREQUENCY
#define BSP_ALARM_FREQUENCY (1000) //DES was (200)
#endif
/*
* HWTimer period
*/
#ifndef BSP_ALARM_PERIOD
#define BSP_ALARM_PERIOD (1000) //DES was (5000)
#endif
Do a clean, re-compile, then debug.
Regards,
David
Hi Alessandro,
Let me answer your questions first then I will add a comment or two.
Q1) In the fsl_hwtimer1.h file generated by PEx the macro FSL_FSL_HWTIMER1_PERIOD_CNF0 is set to 5000: I think the systick timer period in microseconds is set with this macro, right?
A1) No and yes ;-). No that the this is not the correct method to modify the systick timer period and yes it is a MACRO PE generates. But for MQX it is not used! Go figure...
Q2) Is manually changing that macro the only way to get the desired systick period for MQX RTOS component ?
A2) The answer would be yes if the macro were used...but it is not for MQX. If it were being used by MQX then you could have manually changed it and then disabled the fsl_hwtimer from Code Generation by right clicking the component and saying "Don't write Generated Component Modules". But since this macro is not used you don't need to do that.
Q3) The MQX RTOS component also inherits one UART as debug console.
What if my custom board has no available UART to assign as debug console?
A3) when you use KSD/KSDK+PE and select MQX as the RTOS, you want to remove the fsl_debug_console Component as it is not needed with MQX. Then in the wizard for the MQX_KSDK Component, have the Inherited components debug console select "KSDK 1.3.0/fsl_uart". You can then configure that fsl_uart Component to use whatever UART you want.
Comment:
No idea why PE wouldn't be used to change the systick value. Maybe next release of KDS/KSDK will allow that.
To change the systick to 1ms do the following:
In bsp_config.h make the following modifications:
#ifndef BSP_ALARM_FREQUENCY
#define BSP_ALARM_FREQUENCY (1000) //DES was (200)
#endif
/*
* HWTimer period
*/
#ifndef BSP_ALARM_PERIOD
#define BSP_ALARM_PERIOD (1000) //DES was (5000)
#endif
Do a clean, re-compile, then debug.
Regards,
David
Hi David,
There are two bsp_config.h files. One in my project which when I change, gives me the 1kHz clock, but there is also one located in rtos/mqx/mqx/source/bsp. Are we to change this and rebuild mqx and other libraries (mqx_stdlib, rtcs, usb, etc.)? I ask only because there is a document entitled 'Using the MQX Timers.pdf' (Using the MQX timers ) that points to the mqx path version of bsp_config.h
Also, they note the following:
"In conclusion if you want to have smaller ticks it is necessary to modify the BSP_ALARM_FREQUENCY value, however it is necessary to remember, we cannot guarantee the correct behavior if you modify original settings. Some of drivers, for example USB, Ethernet PHY, ESDHC, etc, use commands like _time_delay; if the resolution is changed then we could get unexpected behavior of these drivers."
Is this something that has occurred with these drivers?
Thanks,
-Raj
Thank you David.
OK for systick value.
About MQX debug console.... OK, I can select and configure whatever UART I want in the MQX_KSDK Component wizard. But to have a debug console in a MQX application developed with KSDK is mandatory? It seems the wizard does not let me have no debug console, because the debug console is an inherited component.... The inherited components must always exist and be properly configured?