On 09/10/18 02:55, Chip Wachob wrote: > This bit stream is complicated in that I have to reverse the bytes as > well since I'm reading off the 'end' of a bunch of registers. So, the > MSByte comes to me first and goes into the [0] location and the extra > bits get added to the '0th' end of the LSByte. It is a very unhandy > hardware setup but one that I don't have any control over.
I'm not sure I understand this fully. Do you mean that each byte has extra bits added or that only the last (LSByte) has extra bits? If it's the latter then it becomes a fairly trivial exercise of slicing the data off rather than shifting. But then you get left with a non-byte. If it's the former then I don't understand how you can determine "byte" boundaries! Also when you say you have to "reverse" the bytes do you mean the bits within each byte need to be reversed? Or merely that the bytes themselves come in the reverse order? If its the latter then the bytearray.reverse() method should suffice to fix that issue. Finally, just to clarify what's happening. It sounds like you have an API that delivers 8 bits(octets) at a time? (Not necessarily actual bytes, just groups of 8 bits, is that correct? And that potentially your actual data is not an even number of octets long (say 14 bits?) and thus you get a few random bits of cruft at the end. Is that the case? If so, how do you know the real length of the actual data? -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor