comFramework Activity
Framework for CAN communication interfaces including code generator
Brought to you by:
vranken
Activity for comFramework
-
comFramework updated /readMe.md
-
Peter Vranken committed [r559] on Code
Announcement: End of project maintenance at SourceForge. Project is from now on hosted at GitHub, see https://github.com/PeterVranken/comFramework
-
-
Minor modifications, mostly documentation and Javadoc repairs.
-
Fix: Bad display of extended CAN ID repaired. Now it is shown with suffix x as done at most other locations
-
Fix: Javadoc errors
-
Minor format errors
-
New document style chosen, TOC as side-bar.
-
Typos, minor corrections
-
Fix: Missing file added to source control
-
Severity level of message lowered. The message:
-
Fix: The group of signals used to contain a reference to all signals in the DBC file although we have API variables only for those, which are either sent or received by the ECU in progress. The bad references have now been removed
-
Documentation only
-
Cleanup: Needless import removed
-
Cleanup: Needless import removed
-
Generation of ASAP2 data description file adopted from other sample "arduinoSampleIntegrationEmbeddedCoder"
-
Updated year designation in copyright notice after re-running the sample
-
Generation of ASAP2 data description file for generated CAN stack merged from sample "EmbeddedCoderAPIWithBusStruct" of the code generator
-
Updated year designation in copyright notice after re-running the sample
-
Redesign of ASAP2 file for CAN interface. Now, we have a structure of nested groups. All Rx and all Tx signals are offered in two large groups. A tree of groups offers the signals in hierarchical view: The buses are presented as root level groups, separately for Rx and Tx. A bus related groups contains a message sub-group for each message transmitted on that bus. A message sub-group contains the transmission status and another sub-group, which bundles all signals of the message
-
New year designation in copyright notice after re-running the sample
-
ASAP2 file generation modernized:
-
Library of standard templates: The check, that a template is used with a code generator (or excelExporter) executable of appropriate version, i.e., the check of the executable's data model revision, has been generalized. Before, it had been implemented specifically for the library templates found in group file mod.stg. Now it is a new, generally useable template, isAtLeastVersionDataModel(neededVersion, templateName), that can be applied for any template to ensure its individual pre-requisite
-
Data model extended: The DBC file attributes, if numeric, can now be rendered either as floating point or as integer. So far, the type had been decided only on the attribute definition in the DBC file. Although this is basically correct and wanted, it turned out that real existing DBC file tend to use improper attribute definitions. This let to problems for attributes, which hold countable quantities but were defined as floating point. Without explicit formatting, the generated text output lo...
-
excelExporter demonstrates the use of the new standard for- and while-loops. Sample withoutInput generates the multiplication table now with three different, alternative template implementations.
-
Stack size of JVM increased to supported deeper recursions of templates (which is useful for the new loop implementations)
-
Templates library: New library file loops.stg offers an implementation of standard for and while loops, which support repeated expansion of one and the same sub-template
-
Typos in Javadoc
-
New feature: Text cells can be rendered as JSON String contents. All needed control character escaping is done. Can be used for C code generation in most situations, too
-
Fix: Internally used class StringSupport needed to be made public in order to bring the documentation of this user-relevant element of the data model into the Javadoc. Before, it was operational but the user had no indication how to use it.
-
Documentation only
-
Update of data model from 1.1 (1001) to 1.2 (1002): Revision 524 had brought the string comparison operations (e.g., to match cell contents against a regular expression) already into the Java source code. This revision publishes the compiled jar, which requires an update of the version designation of data model (and thus the tool itself) and which has some impact on the documentation
-
Preliminary commit of binaries of new excelExporter 1.2
-
Preliminary commit of binaries of new excelExporter 1.2
-
Preliminary commit of binaries of new excelExporter 1.2
-
Documentation only
-
Compiler warning complaining about type-punned pointer removed. Emitted machine code is identical
-
New support of string comparison operations merged from codeGenerator to excelExporter
-
Fix: Wrong file had been committed
-
Fix: Wrong file had been committed
-
Binaries of first build of upcoming release 1.12 of the code generator
-
String comparison operations provided to ST4 template expressions. <info.str> is a new attribute, which offers some comparison operations, including matching to regular expressions. In connection with a bunch of new library iteration templates, it becomes straight forward to iterate various possible sets of objects, be it frames, signals or else. See new sample stringCompare to get an overview.
-
Typos
-
mod.stg:
-
Will modified a comment on discussion General Discussion
I've found another inconsistency with Vector's DBC specification (1.0.5) relating to extended signal information (SIG_VALTYPE_). The current dbc.g4 specifies: signalExtendedValueTypeList : EOL+ 'SIG_VALTYPE_' msgId=Integer signalName=ID signalExtendedValueType=Integer ';' But there's actually an extra colon after the signal name: signalExtendedValueTypeList : EOL+ 'SIG_VALTYPE_' msgId=Integer signalName=ID ':' signalExtendedValueType=Integer ';' This is confirmed using Vector's CANdb++ program, which...
-
I've found another inconsistency with Vector's DBC specification (1.0.5) relating to extended signal information (SIG_VALTYPE_). The current dbc.g4 specifies: signalExtendedValueTypeList : EOL+ 'SIG_VALTYPE_' msgId=Integer signalName=ID signalExtendedValueType=Integer ';' But there's actually an extra colon after the signal name: signalExtendedValueTypeList : EOL+ 'SIG_VALTYPE_' msgId=Integer signalName=ID ':' signalExtendedValueType=Integer ';' This is confirmed using Vector's CANdb++ program, which...
-
I've found another inconsistency with Vector's DBC specification (1.0.5) relating to extended signal information (SIG_VALTYPE_). The current dbc.g4 specifies: signalExtendedValueTypeList : EOL+ 'SIG_VALTYPE_' msgId=Integer signalName=ID signalExtendedValueType=Integer ';' But there's actually an extra semicolon after the signal name: signalExtendedValueTypeList : EOL+ 'SIG_VALTYPE_' msgId=Integer signalName=ID ':' signalExtendedValueType=Integer ';' This is confirmed using Vector's CANdb++ program,...
-
Fix: Missing closing html tags
-
Documentation
-
The port object's two-step way of writing an event, first memory allocation and reservation and only later submission of the event, is now supported by the API of the event sender object, too. (The sender object basically is a wrapper around the sender port functionality.)
-
Fix: The index i0 of bus objects inside the collection cluster of those had been wrong calculated. This is an ages old bug; probably the template expression \<bus.i0> won't ever have worked correct in the past
-
Migration of samples for MathWorks' Embedded Coder migrated to R2021b
-
Migration of samples for MathWorks' Embedded Coder migrated to R2021b
-
Migration of samples for MathWorks' Embedded Coder migrated to R2021b
-
Integration of antlr-4.12.0-complete.jar, including StringTemplate V4 4.3.4.
-
New version of excelExporter: 1.1 (with new data model 1001). See SVN revision 506 for details
-
Output of samples re-generated in order to reflect the new tool version designation in some comments
-
More books added to the list, output re-generated
-
New feature: The data model (now 1001) became the new filed CellObject.is, which allows checking the cell contents for a specific (text) content. Use case are cells, with particular, known, enumerated strings contents, which can be queried in a templated, e.g., to implement switch/case constructs in the template
-
Bug fixes: The implementation of the binary-search-handle-map used to be platform dependent (an invalid assumption about the order of bit fields in binary code had been made) The code generator suffered from a null pointer exception when a template demanded frame sorting for a DBC file without any contained message. The exception was caught and reported but this hindered from completing the code generation and didn't lead to a meaningful error message More details can be found in the project's SVN...
-
Update documentation
-
-
-
Fix: Bad year corrected
-
Folder renamed according to update of software revision
-
Version designation adjusted according to merge of recent improvements in previous commit
-
The release folder is updated with recent modifications made in the trunk, revisions 487-500 of the trunk folders of components canInterface, codeGenerator and excelExporter have been merged into this release folder. Main reason were two fixes:
-
Fix: An empty DBC file without any message definition let to a (caught) null pointer exception if a template made use of frame sorting
-
New constructor for timers added. The new constructor allows to control the phase of a regular, periodic timer
-
Binary search handle map has been migrated to the fixed interface of the required lookup tables. Before the interface definition and thus the map implementation used to contain a platform dependency (see previous commit). Now, it's generic source code, which will succeed on all platforms
-
Fix: New convenience macro contained a syntax error
-
Fix: Unwanted and undocumented platform dependency of implementation eliminated. The implementation used to depend on the order in which the compiler organizes its bit fields, while this is not a guaranteed, safe order; the C standard leaves it open, which order a compiler may choose. So there was a significant chance that the implementation would have failed on a given platform. Now, the implementation uses explicit bit operations to ensure that the data is ordered correctly (rather than rel...
-
Documentation
-
More convenience macros for the use of the interfaces
-
Proper name of output file
-
Documentation
-
Recursive search for source files adopted from other branches
-
Typo
-
Fix: Still an HTML link with missing closing tag </html>
-
Update of references to the required Java packages
-
Typo
-
Wiki page "CAN Interface" modified with respect to the architectural redesign in revision 2.0
-
The CAN interface has undergone a redesign. The monolithic structure has been broken up into a now user-visible object structure with publicly defined interfaces. This allows to exchange all cooperating elements with interface-compatible other ones, which may be either chosen from the palette of available implementations or be self-made if specific platform or environment requirements hinder from using the pre-defined ones. The new concept widens the flexibility in integrating the interface in various...
-
Upload of last bug fix release of comFramework before redesign of API of CAN interface in upcoming release 2.0. Bug fix CAN interface in dispatching of events from custom sources. Many corrections in doxygen and source code documentation. No functional changes of code generators.
-
Fix: Many HTML links suffers from a missing closing tag </html>
-
Fix: Many HTML links suffers from a missing closing tag </html>
-
New revision announced
-
Fix: Many HTML links suffers from a missing closing tag </html>
-
-
-
Release of comFramework 2.0
-
Still some problems with the build.xml. The revised folder (slightly modified from 1.5 to 2.0) had not yet been considered correctly in ant build tasks distribution
-
Several corrections in documentation
-
Fix: Build scripts needed adjustment to altered ST4 and ANTLR jar file names
-
Very draft update of the architecture overview image
-
Preparation of comFramework release 2.0: JavaDoc documentation updated, samples re-run, etc.
-
Typos
-
Improved, more convenient user feedback from template expansion process offered
-
Typos
1 >
