I would argue that all of these "solutions" are cumbersome. All of them have you juggling transposition all the way up to the end of your method call. Why not implement a reusable solution that covers all of the bases?

Code: Select all

```
import math
convert = lambda n: (n).to_bytes((0 if not n else int(math.log(n, 256)))+1, 'big')
val = 32767
i2c.writeto_mem(0x0E, 0x18, convert(val))
```

With this solution you don't have to do any shifting, multiplying, subtracting, separating ... any of it. Just dump your number (no matter what it is) into

**convert** and out comes your bytes. If it has to be a

**bytearray**, simply wrap the return in

**bytearray**, as below.

Code: Select all

```
convert2 = lambda n: bytearray((n).to_bytes((0 if not n else int(math.log(n, 256)))+1, 'big'))
```

For anyone that needs an explanation:

**to_bytes** takes 2 arguments. The first is how many bytes to use, and the second is the endian. Using

**log** we can determine how many bytes our number will consume. We want the bytes back in the same order in which we put them in, so we use big endian. In short, we stick in a number, the amount of bytes that number consumes is determined and then the number is converted to that many bytes. If you use the

**bytearray** version all of the exact same things happen and the result gets dumped in a

**bytearray**. That's it. Simple. In contrast you can do 3 lines of math every single time you need to call

**writeto_mem** ... and possibly spend hours trying to track down the one time you

**<<** instead of

**>>** (and other such issues that arise when you manually input something that should simply be a function, multiple times). Let's also not overlook that all the ways that were suggested/implemented only handle 2 bytes. My method will spit out however many bytes the largest number you can create is (8?).

SIDENOTE:

Code: Select all

```
val = 32767
higherbyte = (val >> 8)
lowerbyte = (val - (higherbyte *256))
i2c.writeto_mem(0x0E,0x18,bytes([higherbyte, lowerbyte]))
```

This code is all over the place. You use bitshifting to divide and then decimal multiplication. But what is really weird is you divide val by 256 (>>8) to make higherbyte and then multiply higherbyte by 256 to subtract it from the original value. It's not wrong. It's just not good. lowerbyte is just val&0xFF. higherbyte is the same thing, but you have to shift it over 8 places(bits) before applying the bitmask for one byte (val>>8&0xFF). Manipulating the MSB to figure out what the LSB is, is very weird.

Now I can have input in decimal, its easier for me

Hex is for you, not the device. In other words, the device doesn't care, at all, if you write 254 or 0xFE. Both are 0b11111110 as far as the device is concerned. That being said, hippy's solution would have worked fine with decimal notation, as long as that decimal is a whole number. 32767>>8 or 32767//256 or 32767//(2**8) <- these are the same result, and the

**8** in the first example is equivalent to the

**8** in the last example. In other words

**>>8** is equivalent to "floor divide by 2 to the 8th power".You should do a study on bitwise operators and become intimately familiar with bits/bytes. You think 32767 is easier than 0x7FFF, but it really isn't. 0x7FFF tells me right off the bat that the bits are 7:(0111) F:(1111) F:(1111) F:(1111). I also know that it's 2 bytes (0x7F, 0xFF). I know that the absolute MSb is not being used, and maybe it can be used for something else (parity?). I know that it can only be left shifted 1 time (within 2 bytes) before it starts eating itself, which also means the value is half-1 of the total possible value. 32767 doesn't tell me anything beyond some things that I have memorized. For instance I know that 2 full bytes is 65535 and 1 full byte is 255 so, 32767 is somewhere in 2 bytes. That's not very helpful information.

"Focus is a matter of deciding what things you're not going to do." ~ John Carmack