Migration Guide (DFS V2.1)
When an existing DATAFLOW Designer project from Version 2.0 or earlier shall be migrated to Version 2.1, a few things must be done in order to adapt the project to the latest changes and new features of the DATAFLOW Software.
Component Migration
The migration of the DATAFLOW components (Code Generator / Imt.Base Library) can be done in steps:
Code Generator Versions
The generator version shipped with the DFS V2.1 installation is the version 2.5. It is also possible to use an older generator version that has been previously shipped with the DFS installation: V2.3 or V2.4.
Generator V2.3
This version was the default generator for V2.0 and initially for V2.1. It does not support generation of unit tests with googletest but ensures that the generated code is the same as before for older projects and older Imt.Base versions. It can be used for Imt.Base versions up to V4.0.
This is the last official generator version that allows generation of code with C++98/03/11. Therefore all projects that use one of this C++ versions are forced to remain on this generator version or on V2.4 below if they use Googletest for generated unit tests.
Generator V2.4
This version was the shipped with DFS V2.1.5. It added support for Googletest but did not generate backwards compatible code for older projects and was therefore not set as default. This generator version must not be used for new projects. It has been replaced by the new release V2.5 of the generator. Projects that have previously used this generator version may still use it together with Imt.Base V4.0 to ensure that the generated code is not changed.
Generator V2.5
This Generator supports MSTest and Googletest generation and supports all available Imt.Base-cpp versions. It does apply some changes to the generated code that require minor code changes in the project code:
- Minimal C++ Version: C++14 (Support for older C++ Versions has been removed).
- Use of std::array instead of C-Arrays.
- Use of constexpr where possible.
- Renamed protocol identifier file based on project name (Old name was always ProtocolIdentifier.h which may cause name conflict when library projects are used).
Imt.Base Library Versions
The DFS V2.1 installation supports the new Imt.Base V4.1. It is also possible to use an older version for existing projects together with an older generator version (see notes above) or with the the current generator V2.5 and minor changes to the project code.
Imt.Base V3.1
This is the latest version that supports C++98/03/11. Projects that use such a C++ version must remain on this Imt.Base version and can not update.
Imt.Base V4.0
This version dropped the support for C++98/03/11 and requires at least C++14 for the project toolchain. It adds support for Googletest in addition to the MS-Test unit tests.
This Imt.Base version requires the Generator V2.4 or V2.5.
Imt.Base V4.1
This version uses c++14 features to improve the library code and changes some interfaces to allow defaulting constructors and operators as much as possible.
This Imt.Base version requires the Generator V2.5.
Code Modifications
Code Generator V2.5
AP Handler
AP Handlers are not overwritten when already existing. Therefore, a few changes need to me made manually when migration to code generator V2.5 is performed:
- Make Destructors non final
- Inherit from *APHandlerIfc
Identifiers
The protocol identifier file name is now based on project name (Old name was always ProtocolIdentifier.h which may cause name conflict when library projects are used). Therfore, this must be changed in user code (APHandlers and APHandler UnitTests).
Protocols
Protocols use std::array instead of C-Array. Therefore, the get and set methods have changed. When code is generated for Imt.Base V4.0 or older, the old API is used:
void getField(uint8_t* const pData) const;void setField(uint8_t const* const pData);
To get the internal std::array, the following can be used:
constexpr const FieldType& getFieldRef() const;
MyProtocol::FieldType is a new alias provided by the protocol class:
using FieldType = std::array<uint8_t, 8UL>;
When Imt.Base V4.1 or newer is used, the new API has to be used and raw pointers are no longer allowed:
constexpr FieldType const& getField() const;
void setField(FieldType const& data) const;
To get the raw pointer of a field, the data method of std::array has to be used:
protocol.getField().data()
Enumerations
The alias for the base type has been changed to pascal case:
MyEnumLimits::ValueType;
MIN, MAX and COUNT is always generated no matter if specific values have been defined for enumerators. If specific values have been defined, there is no guarantee that an iteration from MIN to MAX will result in only valid enumerators because there could be 'holes' in the enum.
Custom Types
The alias for the base type has been changed to pascal case:
MyType::BaseType;
Tests
Unit Tests for Component Handlers are not overwritten when existing.
For AP IRQ, the static Instance variable is no longer public. Use MyAPIRQ::getInstance() instead of MyAPIRQ::Instance in the unit test.
Comments
0 comments
Please sign in to leave a comment.