Point taken on 'bytes'.. thanks. the
scratch_ary = bytearray() was my attempt at 'setting' the type of the variable. I had hoped that it would help resolve the error messages telling me that the types didn't go together. Coming from a 'C' background, I find the lack of typing in Python to be confusing. I'm used to working with bytes / words signed and unsigned for a reason. So, if I'm understanding the transfer() function correctly, the function takes and returns a bytearray type. You mentioned about constructing a bytearray if I need one. Can you expand on how I approach that? I'm going to try the experiment you mentioned in hopes of it giving me a better understanding of the 'types' and what happens with the variables. Thank you, On Fri, Sep 7, 2018 at 6:23 PM, Cameron Simpson <c...@cskk.id.au> wrote: > On 07Sep2018 15:45, Chip Wachob <wach...@gmail.com> wrote: >> >> Basically I'm trying to write a block of unsigned bytes to the device >> and read back an equal sized block of unsigned bytes. There's a >> function that is provided called transfer(data_to_send, num_of_bytes) >> that handles the heavy lifting. Unfortunately there seems to be a bug >> in the part and if I attempt to send the entire block of bytes (64), >> the device will lock up. I've been able to determine that if I send >> 16 bytes at a time, I'm okay. >> >> So, I take my bytearray(64) and step through it 16 bytes at a time like >> this: >> >> my function's main pieces are: >> >> def transfer_byte_array(): >> MAX_LOOP_COUNT = 64 >> slice_size = 16 >> read_ary = bytearray(MAX_LOOP_COUNT) >> scratch_ary = bytearray() >> >> for step in range (0, MAX_LOOP_COUNT, slice_size): >> scratch_ary = transfer(data_to_send, slice_size) >> >> for bytes in range (0, slice_size): >> read_ary = scratch_ary[bytes] >> >> return(read_ary) >> >> >> Ideally, I'd like to take the slice_size chunks that have been read >> and concatenate them back togetjer into a long MAX_LOOP_COUNT size >> array to pass back to the rest of my code. Eg: >> >> read_ary = ary_slice[0] + ary_slice[1] + ary_slice[2] + ary_slice[3] > > > Minor remark: don't use the name "bytes" for a variable, it is a builtin > type name and you're shadowing it. > > It looks to me like "transfer" hands you back a buffer with the read data, > so this: > > scratch_ary = bytearray() > > don't do anything (it gets discarded). > > If you're getting back a bytes or bytearray object from transfer, just > gather them all up in an list: > > returned_buffers = [] > for ...... > response = transfer(data_to_send, slice_size) > returned_buffers.append(response) > ....... > read_ary = b''.join(returned_buffers) > > Note that that makes a new bytes object for read_ary to refer to. You don't > need the earlier initialisation of read_ary. > > Also note that the bytes object is read only; if that is a problem you'll > need to construct a bytearray instead. > > [...] >> >> The problem that I repeatedly run into is with the line: >> >> read_ary = scratch_ary[bytes] (or variants thereof) >> >> The traceback is this: >> >> Traceback (most recent call last): >> File "SW8T_5.py", line 101, in <module> >> loop_size = RSI_size_the_loop(Print) >> File "/home/temp/Python_Scratch/examples/RSI.py", line 350, in >> RSI_size_the_loop >> read_ary.append(scratch_ary[singles]) >> TypeError: an integer or string of size 1 is required > > > Yeah I thought that looked weird to me too. >> >> or, one of the other common ones that I've seen is >> >> TypeError: can't concat bytearray to list >> >> This one is confusing because both of the operands are bytearry >> types.. or at least I thought they should be... > > > No, one will be a list :-) putting a bunch of: > > print(repr(foo)) > > replacing "foo" with relevant variables will be illuminating to you; you can > see immediately where this are not what you expected. > >> I'm obviously missing something fundamental here. Problem is I can't >> seem to find any examples of people asking this question before on the >> inter-webs.. > > > You have the opposite of my problem. I can often find people asking the same > question, but less often an answer. Or a decent answer, anyway. > > Cheers, > Cameron Simpson <c...@cskk.id.au> _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
