This chapter describes how the size and speed of the code could be optimized by choosing right bean for the specific task. It should also give an advice how to setup beans to produce optimized code. The optimizations that will be described regard only the High or Low level beans, not the MSITStore:C:\Program%20Files\Freescale\CodeWarrior%20for%20HCS12%20V4.7\Help\ProcessorExpert.chm::/BeanCategoriesInfo.html#LevelAbstraction">Peripheral Initialization beans. Please follow to sub-chapters for more details on
This chapter describes how the size and speed of the code could be optimized by choosing right bean for the specific task. It should also give an advice how to setup beans to produce optimized code. The optimizations that will be described regard only the High or Low level beans, not the MSITStore:C:\Program%20Files\Freescale\CodeWarrior%20for%20HCS12%20V4.7\Help\ProcessorExpert.chm::/BeanCategoriesInfo.html#LevelAbstraction">Peripheral Initialization beans.
Please follow to sub-chapters for more details on
This chapter contains general hints and instructions how to setup Processor Expert and beans to generate optimized code. The following optimization regards only the High or Low level beans, not the Peripheral Initialization beans. When Processor Expert generates the code certain methods and events are enabled by default setting, even when the methods or events are not needed in the application, and thus while they are unused, its code still can take memory. Basically, the unused methods code is dead stripped by the linker but when the dependency among methods is complex some code should not be dead stripped. When useless methods or events are enabled the generated code can contain spare source code because of these unused methods or events. Moreover some methods can be replaced by more efficient methods that are for special purposes and therefore these methods are not enabled by default. Disable unused and test purpose beans or remove them from the project. Disabling of these beans is sufficient because the useless code is removed but the bean setting remains in the project. If these beans are required for later testing then add a new configuration to the project and disable these useless beans in the new configuration only (the previous configuration will be used when the application is tested again). Moreover if it is required to use the same bean with different setting in several configurations its possible to add one bean for each configuration with same name and different setting. Timed beans which depends on the CPU clock (such as timer, communication and conversion beans), may support speed modes defined in the CPU bean (in EXPERT view level). The Processor Expert allows the user to set closest values for the bean timing in all speed modes (if possible). If the requested timing is not supported by the bean, for example if the CPU clock is too low for the correct function of the bean, the bean can be disabled for the appropriate speed mode. The mode can be switched in the runtime by a CPU method. The bean timing is then automatically configured for the appropriate speed mode or the bean is disabled (according to the setting). Note, however, that use of speed modes adds extra code to the application. This code must be included to support different clock rates. See MSITStore:C:\Program%20Files\Freescale\CodeWarrior%20for%20HCS12%20V4.7\Help\ProcessorExpert.chm::/SpeedModes.html">speed mode details here. See MSITStore:C:\Program%20Files\Freescale\CodeWarrior%20for%20HCS12%20V4.7\Help\ProcessorExpert.chm::/configurationproperties.html">Configuration Inspector for more optimization settings. See chapter MSITStore:C:\Program%20Files\Freescale\CodeWarrior%20for%20HCS12%20V4.7\Help\ProcessorExpert.chm::/BeanOpts.html">Embedded Beans Optimizations for details on choosing and setting the beans to achieve optimized code.Disabling unused methods
Notice: These optimization are not usable for the MSITStore:C:\Program%20Files\Freescale\CodeWarrior%20for%20HCS12%20V4.7\Help\ProcessorExpert.chm::/BeanCategoriesInfo.html#LevelAbstraction">Peripheral Initialization Beans
Disabling unused beans
Speed modes
Notice: These optimizations are not usable for the MSITStore:C:\Program%20Files\Freescale\CodeWarrior%20for%20HCS12%20V4.7\Help\ProcessorExpert.chm::/BeanCategoriesInfo.html#LevelAbstraction">Peripheral Initialization Beans
This chapter contains general hints and instructions how to setup Processor Expert and beans to generate optimized code. The following optimization regards only the High or Low level beans, not the Peripheral Initialization beans.
When Processor Expert generates the code certain methods and events are enabled by default setting, even when the methods or events are not needed in the application, and thus while they are unused, its code still can take memory. Basically, the unused methods code is dead stripped by the linker but when the dependency among methods is complex some code should not be dead stripped. When useless methods or events are enabled the generated code can contain spare source code because of these unused methods or events. Moreover some methods can be replaced by more efficient methods that are for special purposes and therefore these methods are not enabled by default.
Disable unused and test purpose beans or remove them from the project. Disabling of these beans is sufficient because the useless code is removed but the bean setting remains in the project. If these beans are required for later testing then add a new configuration to the project and disable these useless beans in the new configuration only (the previous configuration will be used when the application is tested again). Moreover if it is required to use the same bean with different setting in several configurations its possible to add one bean for each configuration with same name and different setting.
Timed beans which depends on the CPU clock (such as timer, communication and conversion beans), may support speed modes defined in the CPU bean (in EXPERT view level). The Processor Expert allows the user to set closest values for the bean timing in all speed modes (if possible). If the requested timing is not supported by the bean, for example if the CPU clock is too low for the correct function of the bean, the bean can be disabled for the appropriate speed mode. The mode can be switched in the runtime by a CPU method. The bean timing is then automatically configured for the appropriate speed mode or the bean is disabled (according to the setting). Note, however, that use of speed modes adds extra code to the application. This code must be included to support different clock rates. See MSITStore:C:\Program%20Files\Freescale\CodeWarrior%20for%20HCS12%20V4.7\Help\ProcessorExpert.chm::/SpeedModes.html">speed mode details here.
See MSITStore:C:\Program%20Files\Freescale\CodeWarrior%20for%20HCS12%20V4.7\Help\ProcessorExpert.chm::/configurationproperties.html">Configuration Inspector for more optimization settings.
See chapter MSITStore:C:\Program%20Files\Freescale\CodeWarrior%20for%20HCS12%20V4.7\Help\ProcessorExpert.chm::/BeanOpts.html">Embedded Beans Optimizations for details on choosing and setting the beans to achieve optimized code.
Notice: These optimizations are not usable for the MSITStore:C:\Program%20Files\Freescale\CodeWarrior%20for%20HCS12%20V4.7\Help\ProcessorExpert.chm::/BeanCategoriesInfo.html#LevelAbstraction">Peripheral Initialization Beans
ByteIO bean instead of BitsIO bean should be used when whole port is accessed. The BitsIO bean is intended for accessing only part of the port (e.g. 4 bits of 8- bit port) Using the BitsIO bean results more complex code because this bean provides more general code for the methods, which allows access to only some of the bits of the port. On the other side, the ByteIO bean provides access only to the whole port and thus the resulted code is optimized for such type of access.ByteIO Bean Versus BitsIO Bean
BitsIO bean versus BitIO beans
In the case of using only a part of the port the multiple BitIO beans could be used. A better solution is to use the BitsIO bean replacing multiple calls of BitIO bean's methods. The application code consist only of one method call and is smaller and faster.
ByteIO bean instead of BitsIO bean should be used when whole port is accessed. The BitsIO bean is intended for accessing only part of the port (e.g. 4 bits of 8- bit port)
Using the BitsIO bean results more complex code because this bean provides more general code for the methods, which allows access to only some of the bits of the port. On the other side, the ByteIO bean provides access only to the whole port and thus the resulted code is optimized for such type of access.
Notice: These optimizations are not usable for the MSITStore:C:\Program%20Files\Freescale\CodeWarrior%20for%20HCS12%20V4.7\Help\ProcessorExpert.chm::/BeanCategoriesInfo.html#LevelAbstraction">Peripheral Initialization Beans
For better code size performance it's recommended do not use a bigger counter/reload/compare register for timer than is necessary. Otherwise the code size generated by a bean may be increased (e.g. For 8-bit timer choose 8bit timer register). In some cases several timing periods are required when using timers (For example the TimerInt bean). The Processor Expert allows changing the timer period during run-time using several ways (note that this is an advanced option and the Bean Inspector MSITStore:C:\Program%20Files\Freescale\CodeWarrior%20for%20HCS12%20V4.7\Help\ProcessorExpert.chm::/itemsvisibility.html">Items visibility must be set to at least 'ADVANCED'). These ways of changing the run-time period of timer requires various amount of code and thus the total application code size is influenced by the method chosen. When the period must be changed during run-time, use fixed values for period instead of an interval if possible to save code. There are two possibilities ( See chapter MSITStore:C:\Program%20Files\Freescale\CodeWarrior%20for%20HCS12%20V4.7\Help\ProcessorExpert.chm::/beantiming.html">Timing Dialog for details. ): If the application requires only a few different timing periods, even if the functionality is the same for both cases, the correct usage of list of periods produces smaller code compared to code using an interval.
For better code size performance it's recommended do not use a bigger counter/reload/compare register for timer than is necessary. Otherwise the code size generated by a bean may be increased (e.g. For 8-bit timer choose 8bit timer register).
In some cases several timing periods are required when using timers (For example the TimerInt bean). The Processor Expert allows changing the timer period during run-time using several ways (note that this is an advanced option and the Bean Inspector MSITStore:C:\Program%20Files\Freescale\CodeWarrior%20for%20HCS12%20V4.7\Help\ProcessorExpert.chm::/itemsvisibility.html">Items visibility must be set to at least 'ADVANCED').
These ways of changing the run-time period of timer requires various amount of code and thus the total application code size is influenced by the method chosen. When the period must be changed during run-time, use fixed values for period instead of an interval if possible to save code. There are two possibilities ( See chapter MSITStore:C:\Program%20Files\Freescale\CodeWarrior%20for%20HCS12%20V4.7\Help\ProcessorExpert.chm::/beantiming.html">Timing Dialog for details. ):
If the application requires only a few different timing periods, even if the functionality is the same for both cases, the correct usage of list of periods produces smaller code compared to code using an interval.
Notice: These optimizations are not usable for the MSITStore:C:\Program%20Files\Freescale\CodeWarrior%20for%20HCS12%20V4.7\Help\ProcessorExpert.chm::/BeanCategoriesInfo.html#LevelAbstraction">Peripheral Initialization Beans
Communication beans should be used with the smallest possible buffer. Thus the user should compute or check the maximum size of the buffer during execution of the application. For this purpose the method GetCharsInTxBuffer/GetCharsInTxBuffer (AsynchroSerial bean), which gets current size of a used buffer, can be used after each calling of the SendBlock/RecvBlock method. Use interrupts if you require faster application response. The interrupt routine is performed only at the event time, i.e. the code does not check if a character is sent or received. Thus the saved CPU time can be used by another process and application is faster. Use polling mode instead interrupts if you require less code because usually overhead of interrupts is bigger than overhead of methods in polling mode. But the polling mode is not suitable for all cases. For example when you use the SCI communication for sending of the data only and a character is sent once in a while then it is better to use the polling mode instead of using interrupt because it saves the code size, i.e. when the interrupt is used an interrupt subroutine is needed and code size is increased. A module of an application sends once in a while one character to another device through the SCI channel. If the delay between two characters is sufficient to sent one character at a time then the polling mode of the SCI (the AsynchroSerial bean) should be used in this case. A module of an application communicates with another device, i.e. it sends several characters at one time and receives characters from the device. Thus the interrupt mode of the SCI (the AsynchroSerial bean) should be used in this case because when a character is received the interrupt is invoked and the underlying process of the application need not check if a character is received. When a buffer for sending is used, the characters are saved into the buffer and AsynchroSerial's service routine of the interrupt sends these characters without additional code of the application. Note: The polling mode of the bean is switched on by disabling of the Interrupt service of the bean (AsynchroSerial, AsynchroMaster, AsynchroSlaveExamples:
Communication beans should be used with the smallest possible buffer. Thus the user should compute or check the maximum size of the buffer during execution of the application. For this purpose the method GetCharsInTxBuffer/GetCharsInTxBuffer (AsynchroSerial bean), which gets current size of a used buffer, can be used after each calling of the SendBlock/RecvBlock method.
Use interrupts if you require faster application response. The interrupt routine is performed only at the event time, i.e. the code does not check if a character is sent or received. Thus the saved CPU time can be used by another process and application is faster.
Use polling mode instead interrupts if you require less code because usually overhead of interrupts is bigger than overhead of methods in polling mode. But the polling mode is not suitable for all cases. For example when you use the SCI communication for sending of the data only and a character is sent once in a while then it is better to use the polling mode instead of using interrupt because it saves the code size, i.e. when the interrupt is used an interrupt subroutine is needed and code size is increased.
A module of an application sends once in a while one character to another device through the SCI channel. If the delay between two characters is sufficient to sent one character at a time then the polling mode of the SCI (the AsynchroSerial bean) should be used in this case.
A module of an application communicates with another device, i.e. it sends several characters at one time and receives characters from the device. Thus the interrupt mode of the SCI (the AsynchroSerial bean) should be used in this case because when a character is received the interrupt is invoked and the underlying process of the application need not check if a character is received. When a buffer for sending is used, the characters are saved into the buffer and AsynchroSerial's service routine of the interrupt sends these characters without additional code of the application.
Note: The polling mode of the bean is switched on by disabling of the Interrupt service of the bean (AsynchroSerial, AsynchroMaster, AsynchroSlave
| 欢迎光临 电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/) | Powered by Discuz! 7.0.0 |