Hi Chris,

first, thanks for the update here.
I already checked your results this morning with Volker and have to say THANK 
both of you for your effort, we are pretty close on closing this off : )

For the rest... I agree with your suggestions. Perhaps instead of 'virtual' we 
could use 'external', as we call external code.
It would be good for us to also generate Interfaces for those externals as this 
would make it easier to add everything in another language, if we generate the 
"skeleton" like that.


Am 07.08.19, 11:04 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:

    Hi all,
    yesterday Volker and I meet in our codecentric office in FFM and worked on 
a DF1 driver based on mspec and generated code.
    Here we learned that we need to extend the arrayField to support a 
“terminated” type in addition to the existing “count” (Explicit number is 
specified before the array in the data) or a “length” (the length of the 
payload in bytes is specified before the array in the data).
    For the DF1 protocol we also need to be able to continue adding elements 
until a termination condition is true (In this case reading the 0x10 0x03 byte 
sequence). So I’ll be extending the spec format with this feature. I would 
suggest not to use some sort of termination characters, but to call a function 
which tells the array to read another element or not.
    Also did we encounter a situation where byte data is escaped … so in this 
case if the data contains the byte 0x10, this has to be escaped by duplicating 
it to 0x10, 0x10. This makes things a little tricky as we have to ignore the 
second 0x10 for the termination condition.
    Last thing we noticed: for calculating the CRC checksum, it would be good 
to have a new type of field in the spec. One that isn’t used for parsing or 
serializing, but for referencing it (in expressions for example) … Not sure how 
to call it tough … was thinking of “virtual”

Reply via email to