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 >
