Just noticed this was a reply to that older DISCUSS … sorry for that ... So right now, we have various types of encoding … String encoding, integer (signed/unsigned), float, … In our current Read/WriteBuffer we seem to set byte oder on a complex type level, but encoding only on field level. So there is no issue with this. However, if I want to configure the default encodings of a complex type (root type), I would need to set different encodings … one for signed integers, one for unsigned integers, one for floating point values and one for strings. That doesn’t work with only one „encoding“ attribute. So my proposal is to use „encoding“ the way we have before … it would be a shorthand for setting all encodings to the given one but also adding additional attributes „signedIntegerEncoding“ to only set that for signed integer values … this way the root type of a protocol could completely specify the default encoding implementations.
So I’m proposing to add more options not remove some … the ones I’m proposing to add we haven’t used before as we usually hard-code those settings in the driver. Chris Von: Christofer Dutz <[email protected]> Datum: Mittwoch, 17. September 2025 um 15:56 An: [email protected] <[email protected]> Betreff: AW: [DISCUSS] Cleanly handling encoding in mspec Sure, So in ads.mspec we have this: [type AmsTCPPacket byteOrder='LITTLE_ENDIAN' I would propose to change it to: [type AmsTCPPacket byteOrder='“LITTLE_ENDIAN"' Chris Von: Sebastian Rühl <[email protected]> Datum: Mittwoch, 17. September 2025 um 15:53 An: [email protected] <[email protected]> Betreff: Re: [DISCUSS] Cleanly handling encoding in mspec not sure about the implications yet. Could you give some mspec/code examples with before/after? That would help a bit how that change actually affects stuff. - Sebastian On 2025/09/16 22:36:42 Christofer Dutz wrote: > Hi all, > > As you know, I’m working on a new SPI implementation, that cleanly separates > the byte-order and encoding from the actual read/write buffers. > Here I have implemented a load of encoders. The Read-/WriteBuffers are > currently initialized with defaults for: > > * > Unsigned integer > * > Signed integer > * > Float > * > String > > However in our current state we only have one „option“: „encoding“ and we’re > passing that along. > Mostly do we use „encoding=xyz“ on simple fields, but in Open-Protocol I also > use it on the root to set it for all fields. > > In my re-implementation I’m using the „encoding“ option to set all types to a > given encoding and I also have „signedIntegerEncoding“, > „unsignedIntegerEncoding“, … to set individual types. > > I think it would be a good idea to generally do this this way. Because then > the mspec already contains a lot of the information that a driver developer > needs. > > The idea is to do this on the root types used in the protocol. I think we’re > currently mostly already doing something similar with the endianness. > > So, the general idea would be that per default in my new implementation the > ByteBasedRead/WriteBuffer wouldn’t know what to do. If a root type defines > this all is good, if it’s a variable, then the driver developer needs to set > defaults outside of mspec. > > What do you think? > > Chris >
