You can find the new command Perform Sanity Check at the main menu entry Options. Amongst others the following things will be checked if you use the sanity checker:
You can choose to perfom a sanity check automatically during a user defined build process and the switch-case generation. To do this you have to enable the checkbox at the menu Options->Statechart Settings->Validation/Constraints.
Until EasyCODE 8.5.3 you had to change the code generation settings for every single statechart again. Now it's possible to choose your settings project-dependant. You can do this at the new menu option "Project->Settings for the current project->code generation from statecharts". This settings are used for all in the project included statecharts and will come to use when the command „Generate source code from all statecharts in project" is included within a user defined build process(all code generation settings that are done in the options of the sole statecharts will be ignored). If you use the command "Generate source code files" from the options menu a message box will appear to ask you which settings you want to use. In all sample projects(in the EasyCODE sub-directory "samples") are from now on project-wide code generation options in use.
It is now possible to define insert-marks(begin and end) for a target file in the code generation settings.(until now this was only possible in a limited way during the user defined build process). This insert marks allow to:
The possible modes of operation during the code generation are:
(Take a look at help chapter 13.6. for further information)
It’s now possible to use C# scripts files instead oft he XSLT-scripts that are used for the code generation. The new component ECCodeGenerator is used to compile and execute C#-Scripts. It is used automatically if the extension of a script file in the code generation is ".cs" instead of ".xsl". Optionally you can attach the name of a method in the script(that will be called by EasyCODE to start the code generation) to the file name if you insert a colon between the script file name and the method name. The given c#-file will be compiled at runtime. All errors will be reported in EasyCODE(in the output window during the user defined build process, and in all other cases with a message box). If a compilation has been created it will be reused as long as the EasyCODE Instance stays open and the script file remains unchanged. In the EasyCODE sub-directory EcFramework you can find for every XSLT-script ("*.xsl") a C#-pendant("*.cs") C# scripts are especially interesting if you want to adjust the code generation to your requirement. C# code is much easier to read and create than XSLT-Code and offers more comfortable and extensive possibilities to process the data received from an XML-tree. Additionally you get much better understandable error-codes from the C# Compiler.
(Take a look at help chapter 13.6. and 13.11 for further information)
The function "Generate All" generates all SPX-files into a directory given with the command line parameter "GI=". The generated files will be saved to the same directory if you don’t use the parameter "GO=" to set a output directory.
If you enable the Multithreading mode with the USE_MULTITHREADING macro the included sub-machines don’t longer run in an extra thread but in the thread of the container machine.
During the code generation all deactivates events, guards and action will be exported with the attribute disabled into the XML file. The code generation scripts were adjuste to generate only event, guards and actions that don’t have the attribute disabled.
The view of the state variable, trigger variable and the transition code below the statechart can now be deactivated. This details are only important for the switch-case generation. To deactivate this view you can disable the checkbox at the menu "Options->Statechart Settings->View". This setting is saved within the respective statechart. Optionally you can define this settings as a standard value for all new statecharts you create.
EasyCODE analyses most of the existing pre processor statements (like #ifdef, #ifndef, #else or #endif) during the open- and parse-process of a C/C++ file by default and displays them as a structure diagram element. Sometimes its better to ignore this statements if they are too complex to read in or if they are saved with a very old version of EasyCODE(like the 15 Year old V6.8). This old version were not able to read pre processors and saved them most of the time as potential structure-destroying text which forces all parser versions of easycode to ignore this text at all because it’s highly possible that this text prevents a whole file from being parsed. But sometimes this old version sees no problem in such a statement which leads to a parser problem: the pre processors are partially marked as structure destroying and partially not. The parser is in this cased for example forced to read a "#ifdef" but also forced to ignore the related "#endif. In this case it’s better to disable the pre-processor parsing. You can find this option in the EasyCODE Configuration ->"CPP" ->Section:"Settings"->"Parse Pre Processer Statements...".
You are now able to define a exit code for ever build step. If the exit code of the give process is not the same as the defined exit code the outcome of the process will be considered as erroneous which leads to a error icon in the output window and an additional error in the build-process conclusion. All build step where the option "Execute step only if no error occurred in the steps before..." is set will be left out.
If a document windows is moved or resized by the user the size and position will be saved automatically in order to restore them when the user open the document the next time. This data is saved in the registry for the last 20 moved or resized documents.
Changes in the generation script statemachine.xsl(in all kinds): the static local array chain is now explicitly initialized with 0:
The ANSI C standard defines that static variables are automatically initialized with zero. However: some easycode users noted that this is not the case by all of their compilers.
EasyCODE collects now line numbers during the code generation in SPX diagrams. This is a important requirement if you want to use the EasyCODE debug interfaces with SPX structure diagrams. Additionally you’ll be asked if you want to save a SPX structure diagram immediately after the source generation to save the collected line numbers.
Until now the generation order of the statecharts in a project were important. It was necessary to generate statecharts that are included in other statecharts at first. This is no longer a necessity in cause of some changes we’ve done in the generation scripts.
EasyCODE checks now during the automatic read process of the signal-batch file if all values are fitting to the identifiers.(the identifier-value assignment can change if a statechart is removed from a project or if the sequence is changed in the project). If that’s the case the value will be adapted to the identifier. While closing the SimulationController the changed signal-batch will be saved automatically.
Some C/C++-Compiler accept enums or unions as a return value of a function. Following the C/C++ standard EasyCODE has tried to construct a enum/union declaration which resulted in an error during the parse process of such files. The parser where extended to support this elements as function return values.
It‘s from now on possible to scroll with CTRL+Home to the start and with CTRL+End to the end of the current structure diagram level.
If you push CTRL+Tab to switch between open files while a project is open and hold the CTRL key EasyCODE will now show the "Views" window until you release the CTRL-Key. This should make the navigation through open documents much easier.
*.exp is now a file extension that is by default handled by the EasyCODE SPS component.
You now can create a new file (with the standard extension for this type) easily in the "File->New" dialogue if you double click on the list to the left.
The EasyCODE Version number is now shown in the main window title bar.
From version 4 of uVision you have to set the port of the UVSOCK interface on another place than up to now: In the Keil uVision menu "Edit->Configuration->Other" you have to activate the checkbox "Enabled". The EasyCODE dialogue „Connection to uVision via UVSOCK" , that appears when the UVSOCK Interface is activated in EasyCODE, has been actualized with this information.
The biggest changes and extension are made to the chapters about statecharts. The chapters 13.14(Junctions) and 13.15(Sample Projects) were added. There are also many big changes in the chapters about code generation and the framework. Most other statechart help chapters have received many but smaller changes.
The behaviour of the DeepHistory states were not completly as expected if a parent state was including another statechart as a sub-machine. The generation scripts and the framework were changed to fix this problem.
Some included statemachines sometimes didn’t handle clock ticks correctly. The generation scripts and the framework were changed to fix this problem.
A error was removed that led to an crash of EasyCODE when a structure diagram was closed.
The addition and deletion of files in the version control system wasn’t working anymore in some cases in cause of a change to the project file name handling.
Sometimes the opening of a EasyCODE Project with a source save connection took a very long time because EasyCODE searched in files that were not permanently deleted but remained invisible and marked with the flag "deleted". This also was the cause of a crash in the EasyCODE VCS-Environment.
A line of the following function has been changed in all variants of the Framework-file EcBaseStatemachine.c/cpp:
while ( NULL == INIT_STATE(s) )
while ( NULL == INIT_STATE(s) && s != m_stateFunc /*maybe changed by INIT_STATE()*/ )
Without this change an infinite loop/deadlock occurs when a state who is target of a initial transition includes another statechart.
While moving a state it occurred in some cases that the enclosed junctions or the starting/ending points of the transitions connected with this junction were not moved, too.
If there is no path for the macro %FRAMEWORK_DIR% given in a build configuration the standard framework directory should be used instead. This didn’t happen in every situation where it was needed.
In some cases SPS created wrong indents during the saving-process. The files should now be saved properly.