Generating Data Source Files
Posted: Sun Jan 09, 2011 12:41 am
Recently, with inspiration from Dave, I have developed a fairly comprehensive mechanism for live from-the-running-firmware data layout interrogation. This is fantastic, because now all it needs is the actual field by field structure to be defined outside the ECU and the tuning software has all it needs, without overly complex unmaintainable files.
The next problem is one of maintenance also:
Duplicate data definitions.
If I keep my existing C files and write matching xml/js/json files then for every change I manually have to update both locations, make no typos and get it all perfect. If not, Dave (and users) will get angry and have less faith. It is also dirty and not at all OAOO to do this. Thus, I won't be doing this.
So, theree are two options:
2) Parse the source and generate XML/js/json files from it
1) Create and maintain XML/js/json files and parse them and output valid C (and possibly stripped down XML/js/json for use by tuner authors/programs.
Given that option 1 (Intentionally mis ordered/numbered to show bias) is far less error prone and better defined and more flexible, I strongly believe that is the best approach.
So, why a thread? I want it to be cross platform so the build will work on mac/lin/win equally well. We *could* revert to cygwin for win, but I'd prefer it stayed native too.
The first thing that comes to mind is XSLT
http://en.wikipedia.org/wiki/XSLT
But that would mean using XML, which I'm not a huge fan of. I'm not a huge fan of json either, but...
Is there something like this for json... searches :
http://goessner.net/articles/jsont/
http://goessner.net/download/prj/jsont/
How would I go about integrating that into the build process (which tools!) such that the C is generated before the compilation process?
Two or three or four transformations would need to be done:
Source data description > C headers
Source data description > C data defintions
Source data description > Simplified data description (structure)
Source data description > Simplified data description (data)
The last two aren't needed if the original rich file is suitable for parsing into an app, which it probably should be. The last one isn't needed if we don't mind pulling such default data out of a live ecu instead.
I'm not sure about the best way to proceed here, so I'd like some help, please! I know what I want, but I don't know how to achieve it. Hackers, scripters, germans, help me out! :-)
Fred.
The next problem is one of maintenance also:
Duplicate data definitions.
If I keep my existing C files and write matching xml/js/json files then for every change I manually have to update both locations, make no typos and get it all perfect. If not, Dave (and users) will get angry and have less faith. It is also dirty and not at all OAOO to do this. Thus, I won't be doing this.
So, theree are two options:
2) Parse the source and generate XML/js/json files from it
1) Create and maintain XML/js/json files and parse them and output valid C (and possibly stripped down XML/js/json for use by tuner authors/programs.
Given that option 1 (Intentionally mis ordered/numbered to show bias) is far less error prone and better defined and more flexible, I strongly believe that is the best approach.
So, why a thread? I want it to be cross platform so the build will work on mac/lin/win equally well. We *could* revert to cygwin for win, but I'd prefer it stayed native too.
The first thing that comes to mind is XSLT
http://en.wikipedia.org/wiki/XSLT
But that would mean using XML, which I'm not a huge fan of. I'm not a huge fan of json either, but...
Is there something like this for json... searches :
http://goessner.net/articles/jsont/
http://goessner.net/download/prj/jsont/
How would I go about integrating that into the build process (which tools!) such that the C is generated before the compilation process?
Two or three or four transformations would need to be done:
Source data description > C headers
Source data description > C data defintions
Source data description > Simplified data description (structure)
Source data description > Simplified data description (data)
The last two aren't needed if the original rich file is suitable for parsing into an app, which it probably should be. The last one isn't needed if we don't mind pulling such default data out of a live ecu instead.
I'm not sure about the best way to proceed here, so I'd like some help, please! I know what I want, but I don't know how to achieve it. Hackers, scripters, germans, help me out! :-)
Fred.