gotcha. - Sebastian
On 2025/09/17 14:08:20 Christofer Dutz wrote: > 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 > > >
