The following section describes the options available on the General tab.
Generate extensive code documentation By default, the MicroC Code Generator includes basic commenting in the generated code. If you would like more extensive commenting in the generated code, select this check box.If this option is selected, comments will be included for all of the following: body of activity functions, statechart/flowchart implementation functions, state transitions, static reactions in a state, data declarations, and headers and footers for all generated files. In addition, the following will be included:
• Information regarding the code generation profile used, such as profile name, date, version This option allows you to generate code while ignoring any external bindings specified in the model. This means that you can ignore these external elements without having to make any changes to the model—you just have to use a profile where this option is selected. Enable Events Broadcasting This means that if an event is generated anywhere in the model, then a duplicate event will be generated for each task waiting for that event (other than the task that “owns” the event), enabling them to react to the event.The duplicated events will have the name<original-Event-
name>_<task-name>
. For example, if the event EV is duplicated for a task named T1, the duplicated event will be given the nameEV_T1
. (If this creates a naming conflict, a number will be added to the end of the name.) Wherever the original event was used as a trigger, the name of the corresponding duplicated event will appear in the code. Wherever the original event was used in an action, the original event name will appear in the code.The duplicated events will be generated in the “new buffer” of their task event buffer. However, it is possible to useGEN_IN_CURRENT
for the duplicated event if the following env-var is used:set AMC_GEN_IN_CURR_FOR_EV_BROADCAST=ON
If this option is selected, a report file will be generated, using the file name that you provide.This report does not include messages generated during code generation. Rather, it provides information regarding the model.
• Task description section, which includes description of all Tasks in the model and of the “Global” task.
For each Task there is information about:
Task's attributes like: Type, ID, priority etc.
Data related to it, like: Dataitems Conditions and Events related to the Task, and their attributes like: double-buffer etc.
•
• Generated code description:
A data-base like description of the elements that were used in the code generations: Activities, Conditions, Dataitems, Events, User-defined types, Actions and Functions.
Each element has a different set of fields in its description structure according to the available information about the element in the following format:The messages generated during code generation can be found in a file called wrn.err. If any problems are encountered during code generation, the information in this file is displayed to the user.
• Makefile Template
Enter in the text box (or locate with the ... button) the template file to use for the creation of the makefile.
The keywords used in the template file will be replaced with concrete information regarding the model files and objects.
•
• Data Items
If selected, a macro will be used (rather than a full C expression) when referring to a data item.
• Activity Implementation
If selected, macros will be used (rather than functions) for activity implementation.
• Miscellaneous
If selected, macros will be used (rather than full expression / function) for elements such as actions.
• Conditions and Bit Data Items
If selected, macros will be used (rather than full expressions) for Conditions and Data Items of type Bit.
• Control Activity Implementation
If selected, macros will be used (rather than functions) for control activity implementation.
•
• Condition
If selected, single bit with bit mask will be used for conditions, rather than a whole byte. The radio buttons provided for this option allow you to select the task/ISR run mode (single step or superstep, as well as specifying when objects should be checked for value changes.
• In this mode, each task/ISR performs a single step and then returns control to the operating system.
• When single step mode is selected, the value checking options available are:
once, before logic execution
once, after logic execution
• In this mode, each task/ISR performs as many steps as needed to reach a stable state (reached when there are no more pending events and no transition occurred in the last step)
• When superstep mode is selected, the value checking options available are:
once, before logic execution
after, each logic execution
• This means that values are checked for changes on each pass through the execution loop until a stable state is reachedWhen superstep mode is selected, care should be exercised when using the once, before logic execution option. This is because there are situations where your system will remain in a certain state until a certain value changes. If the values are only checked once, before the logic is executed, then in many cases the system will never detect the value change that takes the system out of that state. This may result in a task running indefinitely.