[Tutor] [spoiler] Re: Shifting arrays as though they are a 'word'

Alan Gauld alan.gauld at yahoo.co.uk
Tue Oct 9 04:13:01 EDT 2018


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




More information about the Tutor mailing list