So I've been doing some further digging around to try and understand more
about the MSpec code generators and I think my initial feelings about how
to tackle this issue has evolved.
I'm now thinking about modifying the XSLT to generate a different MSpec
file that will change the type of the 16-bit float from this:
['DPT_Value_Temp' REAL
[simple float 16 value]
]
to something more like this, once I understand what needs to go into the
expressions....
['DPT_Value_Temp' REAL
[manual float 16 value '{serialization-expression}'
'{deserialization-expression}' '{length-expression}']
]
So now my plan is to dig around for some examples of manual field type
definitions and seek inspiration. If anyone has any interesting/useful
examples thereof that thye would like to point me at them I'm all ears.
Darren
On Tue, Mar 1, 2022 at 11:21 PM Darren Everley <
[email protected]> wrote:
> Hey Chris,
>
> When I say two implementations; what I mean is that the KNX spec has two
> distinct 16-bit float formats, used seemingly by different equipment
> vendors (!!?!). So we need a discriminator to route to the appropriate
> decoding method. One of these is KNX specific as far as I'm aware.
>
> For example in the following sample of generated code, the generated
> readFloat method needs to be able to discriminate the correct underlying
> data type, one of which is like I said; KNX specific.
>
> } else if (EvaluationHelper.equals(datapointType,
> KnxDatapointType.DPT_Value_Tempa)) { // REAL
>
> // Simple FieldA (value)
> Float value = /*TODO: migrate me*/ /*TODO: migrate me*/
> readBuffer.readFloat("", 16);
>
> return new PlcREAL(value);
> }
>
>
> So I believe a the tasks required to get this done are as follows;
>
> 1. update to the XSD that generates the MSpec (is that correct?). XSD is
> not really my forte, so perhaps you could help here?
>
> 2. update needs to be made to the parseFloat method of ReadBufferByteBased
> to handle the additional KNX format. This smells bad, as this is KNX
> implementation details leaking into common code. So any thoughts you have
> on how to tackle this would be helpful? Perhaps this type of issue has been
> encountered on other protocols and there is an existing pattern to be
> replicated? I will then be able to go ahead and implement the necessary
> changes.
>
> 3. then 'finally' the Freemarker template for java code generation
> (data-io-template.java.ftlh) will need to be updated to 'route' to the
> appropriate 16-bit float format as implemented in the step above. I will
> take care of this also.
>
>
> I hope all that makes sense for a relatively late night brain dump!
>
> All the best
>
> Darren
>
>
>
>
>
> On Tue, Mar 1, 2022 at 11:00 PM Christofer Dutz <[email protected]>
> wrote:
>
>> Hi Darren,
>>
>> I have also noticed that my original implementation doesn't accrually
>> work. So we need to generally fix this. I don't think we need two
>> alternative implementations, but we need to fix the one we have :-)
>>
>> If you've got an idea on how to do that, I'm Haus to help.
>>
>> Chris
>>
>> Holen Sie sich Outlook für Android <https://aka.ms/AAb9ysg>
>> ------------------------------
>> *From:* Darren Everley <[email protected]>
>> *Sent:* Tuesday, March 1, 2022 11:40:18 PM
>> *To:* [email protected] <[email protected]>; Christofer Dutz <
>> [email protected]>
>> *Subject:* KNX: DPT_Value_Temp aka that 16-bit float with 'special'
>> encoding
>>
>> Hi Chris/All,
>>
>> I've been digging around in the KNX code generation areas for the
>> aforementioned data type; DPT_Value_Temp and it's brethren. So I can see
>> how the code generators work by driving a 16-bit float to be decoded as a
>> 'half-precision' IEEE value, via the readFloat method of the
>> ReadBufferByteBased class.
>>
>> Now, with this additional and alternative 16-bit float implementation
>> needing to live alongside the existing, perhaps it's best to have a
>> discussion on the most prefered approach for handling this as it seems,
>> from my fresh and naive perspective, that changes need to be made to the
>> ReadBufferByteBased class and this will affect a whole bunch of other
>> modules.
>>
>> As always, I'm more than happy to make the required changes here, but
>> would like some advice from the more experienced developers on this project
>> before wading in.
>>
>> Many thanks
>>
>> Darren
>>
>>
>
>
>
--
*Darren Everley - Director*
*Email: *[email protected] *| Mobile:* 07891405262 *| Website:*
www.xeropoint.co.uk
*Company: *Xeropoint Ltd. Registered in England and Wales. 11101907
*Address:* Henleaze House, Harbury Road, Bristol, BS9 4PN
