Hi Sebastian, I ended up extending the readBits to have a second argument. With this, the user can define, if he wants the bits to be alligned to the right, or not. The main reason is that all other methods such as „readShort“ internally use that method. So if I want to make a short out of one or two bytes, the input needs to be right-alligned.
Also did I implement the Endianess in a service-manager way, as we do it in the other parts of PLC4X (Not sure about the implications for OSGI though). Here each implementation has a byte[] process(byte[]) method. The implementation for BigEndian simply returns the bytes passed in. So in every case I have the selected endianess post process the byte array returned by readBits before they are processed any further. In the next step I’m planning on implementing a similar Encoding-Manager, however I’m still a bit unsure, if I should have one big interface with all supported types and simply implement non-matching ones with an „unimplemented“ exception. Just as an example: * UnsignedInteger (default for unsigned integers) * TwosComplementInteger (signed) (default for signed integers) * IEEE754FloatingPoint (default for float and double) * The various String encodings * VarLengthSigned/unsigned integer * KNXFloat * ... I guess extending the mspec or another part to profide default encodings for various field types, might be a good idea and make it possible to override on occasion. Possibly defining groups „signed-int“, „unsigned-int“, „floating-point“, „string“ might make sense. Chris Von: Sebastian Rühl <sru...@apache.org> Datum: Montag, 14. Juli 2025 um 09:23 An: dev@plc4x.apache.org <dev@plc4x.apache.org> Betreff: Re: [SPI 3.0] Questions about endianess Hi Chris, I would expect readBits and readByte (using byte as a synonym for octet here) to always read from left to right. Also endianess is more about higher order data types which bits and bytes do not care about itself IMHO. just my 2ct - Sebastian On 2025/07/13 16:27:32 Christofer Dutz wrote: > Hi, > > I’m currently spending some time writing a new SPI. One where not everything > is mixed up together, as we currently have it. > > I’m particularly trying to create a new ReadBufferByteBased and > WriteBufferByteBased, which correclty supports a pluggable system for > providing custom endianess and encodings. > > Nuw the core of my current implementation is a method: > byte[] readBits(int numBits, boolean alignToByteBoundary); > > This simply returns a byteArray with all the bits required to be read. > > I’m a bit torn about the Endainess and the Encoding as both are sort of > tightly coupled. > However I finally decided to have them separated. Now I have a > ByteOrderBigEndian, and ByteOrderLittleEndian. > > In paralell I’ll have „Encoding“ implementations, that should take care of > the real decoding of the byte data. > Now I’m currently a bit unsure about how I should handle LittleEndian > (Encoding in general). > > Should I apply the endianess first and then read the bits, or the other way > around? > > Little example … I’m at bit 4 of the current byte and now want to read 16 > bits Little Endian. > So I rearange the bytes first and then read the bits, or do I read the bits > first and then reverse them. > In one case the order in the resulting byte array will be reversed in the > middle of the bytes, in the other case they will be reversed within the > output bytes. > > Any ideas? > > Chris > > >
