Alan,
Yes, 2.7 here. I wanted to use 3, but the API only supports 2.7.
And, I'm not about to get into rewriting an API. :)
So, octets it is. Thank you for the clarification.
Yes, my background is C, let me look into your suggested method.
It is the shifting across those byte boundaries that
On 10/09/2018 12:13 PM, Alan Gauld via Tutor wrote:
> Quite.
> I should, of course, have said there is no long in Python v3...
>
> We have since established that Chip is using 2.7 so there
> is indeed a long type.
>
> I pretty much stopped using v2 about 3 years ago so I
> tend to forget about
On 09/10/18 17:32, Mark Lawrence wrote:
> On 09/10/18 17:10, Alan Gauld via Tutor wrote:
>> On 09/10/18 13:45, Chip Wachob wrote:
>>
>>> Another related question. How do I know I want to do dir(int) vs.. I
>>> don't know dir(long)?
>>
>> Because you want to convert the byte array into an int.
>>
On 09/10/18 17:10, Alan Gauld via Tutor wrote:
On 09/10/18 13:45, Chip Wachob wrote:
Another related question. How do I know I want to do dir(int) vs.. I
don't know dir(long)?
Because you want to convert the byte array into an int.
And there is no long in Python...
Really? :)
On 09/10/18 14:21, Chip Wachob wrote:
> The API is providing me with a bytearray-formatted result, but the API
> only reads one whole byte, or eight bits, at a time.
Being slightly picky but an octet and a byte are subtly different.
An octet is a group of 8 bits with no meaning attached.
So an
On 09/10/18 13:45, Chip Wachob wrote:
> Another related question. How do I know I want to do dir(int) vs.. I
> don't know dir(long)?
Because you want to convert the byte array into an int.
And there is no long in Python...
> And, when I do dir(int) I get the following results. I must not be
>
Peter,
Thank you for taking the time to create the example.
I'm new to Python, and, as a result, about a quarter of your example
makes sense to me. The remainder I will have to start googling to see
if I can get my head around it.
On 10/9/18, Peter Otten <__pete...@web.de> wrote:
> Chip
I'm sorry that my explanations are obtuse...
Hopefully this will clarify things. Again, not knowing how much
information is too much... I know I can be too verbose and that's not
always a good thing.
I have a bank of registers that I read via SPI. The SPI API is from
the IC manufacturer.
Alan,
Thank you.
Another related question. How do I know I want to do dir(int) vs.. I
don't know dir(long)?
And, when I do dir(int) I get the following results. I must not be
seeing the from_bytes in this list...
>>> dir(int)
['__abs__', '__add__', '__and__', '__class__', '__cmp__',
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
On 09/10/18 02:48, Chip Wachob wrote:
>> bytearray(b'\x00\xff\x7f\x00')
>> py> n = int.from_bytes(b, 'big')
>
> I'm not familiar with this int.from_bytes.
>
> Being new to Python, I don't have a mental library of these nifty
> functions. How / where does one find a library of these wonderful
>
Mats,
Thanks for the suggestion.
Even if I did mask, I would still have to shift the data to line it up
properly. And the shifting seems to be where I'm introducing my
error(s).
This bit stream is complicated in that I have to reverse the bytes as
well since I'm reading off the 'end' of a
First,
Steven,
Thank you for your insight.
On 10/8/18, Steven D'Aprano wrote:
> On Mon, Oct 08, 2018 at 09:16:16AM -0400, Chip Wachob wrote:
>
>> - What follows is a mini version, the array could be any size up to 64
>> bytes
>>
>> input: 10010010 . 1110 . 01010011
>>
>> shift 'x' (for
Chip Wachob wrote:
> All,
>
> Sorry for not being more clear. I think I was nearing my fill of
> Python for the day when I wrote.
>
> Now, refreshed, let me see if I can fill in the blanks a bit more.
You have posted code sprinkled with prints and irrelevant details.
Please rewrite the
On 10/08/2018 07:16 AM, Chip Wachob wrote:
> All,
>
> Sorry for not being more clear. I think I was nearing my fill of
> Python for the day when I wrote.
>
> Now, refreshed, let me see if I can fill in the blanks a bit more.
>
> - Bits that are shifted in either direction off the end of the
>
On Mon, Oct 08, 2018 at 09:16:16AM -0400, Chip Wachob wrote:
> - What follows is a mini version, the array could be any size up to 64 bytes
>
> input: 10010010 . 1110 . 01010011
>
> shift 'x' (for example, I'll use 1)
>
> output: 01001001 . 01110111 . 10101001
The first two seem to be
All,
Sorry for not being more clear. I think I was nearing my fill of
Python for the day when I wrote.
Now, refreshed, let me see if I can fill in the blanks a bit more.
- Bits that are shifted in either direction off the end of the
64-byte(or 'n' size) collection are of no use. They are
Chip Wachob wrote:
> Hello,
>
> I was not able to find any answers in the archive on this one.
>
> I'm wondering if this task can be done in a better way than what I've
> attempted..
>
> I have an array of bytes. Up to 64, which makes for 512 bits.
>
> I am reading these bytes in serially,
18 matches
Mail list logo