Yes it works cause the error and function bits are declared as
discriminators. Try making response bit first in type switch. Then its
gonna fail. This is because you need to explicitly declare a first
discriminator field.
It is not a big deal, however when we have header and payload parts one
is rather constant and other is rather dynamic and in case of CAN some
information comes from header and influence how parsing of payload
should be made.
See below:
[type 'SocketCANFrame'
[simple int 32 'rawId']
[virtual int 32 'identifier'
'STATIC_CALL("..", rawId)'
]
[virtual bit 'extended'
'STATIC_CALL("..", rawId)'
]
[virtual bit 'remote'
'STATIC_CALL("..", rawId)'
]
[virtual bit 'error'
'STATIC_CALL("..", rawId)'
]
[implicit uint 8 'size' 'COUNT(data)']
[CANOpenPDU 'data' ['remote', 'extended']]
[typeSwitch 'extended'
['true' ExtendedFrame
// flags
]
['false' StandardFrame
// padding
]
]
]
[type CANOpenPDU [bit 'remote', bit 'extended']
[typeSwitch 'remote', 'extended'
// this wont generate
['true', 'true' ExtendedRemotePDU
]
]
]
Best,
Łukasz
On 26.08.2020 10:32, Christofer Dutz wrote:
> Here the part in the modbus.mspec I was talking about:
>
> [discriminatedType 'ModbusPDU' [bit 'response']
> [discriminator bit 'error']
> [discriminator uint 7 'function']
> [typeSwitch 'error','function','response'
> ['true' ModbusPDUError
> [simple uint 8 'exceptionCode']
> ]
>
> // Bit Access
> ['false','0x02','false' ModbusPDUReadDiscreteInputsRequest
> [simple uint 16 'startingAddress']
> [simple uint 16 'quantity']
> ]
> ['false','0x02','true' ModbusPDUReadDiscreteInputsResponse
> [implicit uint 8 'byteCount' 'COUNT(value)']
> [array int 8 'value' count 'byteCount']
> ]
>
> So the input values in the "typeSwitch" are actually expressions that are
> evaluated. It doesn't really care about if something's a discriminator.
> A discriminator is only interesting when serializing as in this case it
> doesn't store the value in the pojo but gets the value from the type instead.
>
> Chris
>
>
>
> Am 26.08.20, 10:29 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
>
> Hi Lukasz,
>
> It would be pretty simple to extend the code generation to make the
> virtual fields available in the parser ...
> I just didn't do it as I then didn't see the need. Should be extremely
> simple to implement. (Sort of just a copy+paste of the pojo template)
>
> You can use type-arguments in typeSwitches ... just have a look at the
> modbus mspec.
>
> What do you mean with "undeclared discriminators"?
>
> Chris
>
>
>
> Am 26.08.20, 01:22 schrieb "Łukasz Dywicki" <l...@code-house.org>:
>
> I been trying to write new mspecs and I found that discriminator
> handling is quite limiting in current form.
>
> For example it is possible to declare a type argument, but it is not
> possible to use it as a divider.
> It is also not possible to use a virtual or manual field as a
> discriminator which could very well be source for type information. I
> am
> aware that virtual field is computed at runtime with given expression.
> I am not entirely sure of all implications for changing the handling.
> Currently discriminator is a simple field which gets registered in
> discriminator set.
>
> What do you think about making a `discriminator` rather an modifier
> which could be placed for type arguments and also in other places? At
> the moment any use of [typeSwitch] with undeclared discriminator
> causes
> null pointers in freemarker templates and failure.
>
> Cheers,
> Łukasz
>
>
