MCP4561 Digital Potentiometer and 9bit Registers

[Comalco]

Folks,
I have been using the DS3502 Digital Pot successfully on a ESP32. I wanted to upgrade to improve resolution of the wiper value, and after looking at pricing and datasheets I chose the MCP4561.
As a newbie, I have struggled to adapt the DS3502 library to work with the MCP4561. I am wondering if the MCP4561's use of a 9bit wiper register at address 0x00 is the problem for my use of i2c.writeto_mem and i2c.readfrom_mem commands ?
I always seem to get a b'\x00' returned by a read from address 00 - even though a POR loads the register with 100h (according to the data sheet). I think I am not getting that 9th bit in my read value. I also recollect that Micropython treats hex numbers a little unusually too.
Could someone please point me to an existing Micropython i2c library that works with a chip with a 9bit register, or suggest some code that would allow me to read and write to the 9bit wiper register in the MCP4561 memory location 00h ?
TIA

[peterhinch]

The datasheet is rather confusing.

Figure 7.3 suggests that the memaddr field of i2c.writeto_mem should have D8 in the LSB, with a 1 byte buffer containing D7..D0. The A bit in the diagram denote ACK bits sourced by the chip, so the chip is seeing 8-bit transfers.

The figure is confusing because it appears to show 9-bit writes which is how the chip sees things, but the ACK bits reveal what is happening in terms of the interface behaviour.

You could use a longer buffer to update multiple registers as shown in the figure, but as a starting point I would just update one.

[Comalco]

Your experience saw what I didnt. Thanks. I sent you a messsage re this too. I will re-read the datasheet and try and implement what you have suggested. :)

[Comalco]

and .... only the wiper register needs to be read/written. The Control register defaults as required anyway.

[Comalco]

Peter, your comment;
"Figure 7.3 suggests that the memaddr field of i2c.writeto_mem should have D8 in the LSB, with a 1 byte buffer containing D7..D0. The A bit in the diagram denote ACK bits sourced by the chip, so the chip is seeing 8-bit transfers"....
Does this mean that for a write to memaddr 0x00 would actually be written as 0x01 if I needed the LSB set ?
This is confusing me as memaddr 0x01 is a valid address for MCP devices with two pots in the chip.
Figure 7.5 has me thrown. Most times I need to read the current wiper position, occasionally I would do a write to update the wiper value.
As the wiper for Pot"0" is memaddr 0x00, would not a "random read" of the wiper value be;
wiper = i2c.readfrom_mem(0x2E, 0x00, 2, addrsize=8) (0x2E being the chip i2c bus address).
Or am I totally misunderstanding what is required here?
I was hoping to see how other i2c devices using similar 9bits do things, but I havent yet found one that uses this structure ........

[Comalco]

OK, so a bit more reading through others' work and it seems this should work;

def myRead16(self, register):
value = int.from_bytes(self.i2c.readfrom_mem(0x002E, register, 1, addrsize=16), 'big')
return value & 0xFFFF

def lrange(self):
return self.myRead16(0x0000)

x = lrange()
print(x)

But no matter what I seem to do, I only ever get "0" printed............

I think I have passed my safe swimming depth and I am out of my depth. Ideas??

[peterhinch]

It is an unusual chip, and I should issue a disclaimer here: though I've used several I2C devices they were all much simpler than this one. Reading seems particularly difficult.

I think what you have to do to read a register is first prime the device with the address. This involves sending two bytes, the first being the chip address (the low order bits set by pins on the chip). The second byte is the device memory address and the command. Having set the register address, you then do a read using the chip address, which will return two data bytes. However I'm unsure about the bus state between the two transfers. To be honest I would expect to spend an hour or so with the chip and a logic analyser to get this right.

I would concentrate on writing, which looks simpler. In general you can keep a record of what you've written, so reading is often unnecessary. Check the effectiveness of your writes by observing the behaviour of the pot.

Writing seems to consist of sending three bytes, which should be simple. The first byte is the chip address, as described above. Then the write command made up of 4 bits of register address, three 0 bits, and the data MSB. Lastly the eight data LS bits.

[Comalco]

Thanks Peter. I have used a lot of i2c chips before and they were very straight-forward to this one. I finally got it working, using your original comments about using multiple bytes in a buffer. I looked at the urtc.py library and saw how it does multi-byte tuples. I played around and finally got a read and write working. My application is to use one of the numerous step-up buck converters from the www and to substitute the on-board PCB voltage adjustment pot for this MCP4561 so I can control/set the output voltage in my project. I wish I had the experience to write a proper library for the chip series (there are quite a few), but for now the read/write is all I need. I will post my final code (as I am still cleaning it up). Its not good code work, but it works reliably. Someone could really help others out by writing a MP library as they are a nice (and low cost) chip series...... I noticed a couple of Arduino libraries for them, so perhaps someone with Arduino experience could rework one of these into a MP version. Many thanks for your helpful comments. (Oh, and I think I added to my problems by writing to the chip incorrectly earlier on - and not doing a POR to reset defaults as I played. I suspect I upset the chip along the way, and didnt get progress in later code tinkering because the chip was already upset and not reset to proper defaults for each new version of my code. A valuable lesson learned!. Inadvertently writing to some of the reserved locations seems to create some very weird behavior!) Thanks again.

[Comalco]

I dont now if there's a simpler way, but I arrived at this;

###################################################################################################

MCP4561 DIGITAL POT LIBRARY

###################################################################################################

class MCP4561:
_TCON = 0x04
_WIPER0 = 0x00

def __init__(self, i2c, address=0x2E):
    self.i2c = i2c
    self.address = address

# set_wiper(value)
def set_wiper(self, value):  
    self.i2c.writeto_mem(self.address, 0, value.to_bytes(1, 'little'))

# value = get.wiper()
def get_wiper(self):
    t = self.i2c.readfrom_mem(self.address, self._WIPER0, 2)
    value = t[0] << 8 & 0b00011111 | t[1]                                   # move bits, and then mask for desired bits only 
    return value

[peterhinch]

It seems to me that your write is only updating 8 of the 9 bits. To write to arbitrary registers I would try:

def set_wiper(self, value, reg):
    value &= 0x1FF   # Ensure only 9 bits
    reg &= 0xF  # Limit to 4 bits
    vb = value.to_bytes(2, 'little')
    self.i2c.writeto_mem(self.address, vb[1] | (reg << 4), vb[:1])

[Comalco]

Thanks Peter,
You must be correct, as I am not doing any manipulation.
I presume reg is 0x00 for the MCP4561 wiper address?
Your use of reg and masking it with 0xF has me a little confused, shouldnt the last line be as follows ....... so a [0] and a [1] byte is specified?
self.i2c.writeto_mem(self.address, vb[0] | (reg << 4), vb[:1])
And if you could mentor a bit more please. Using your structure, what does my get_wiper become ????
I have a long way to go to understand the use of to_bytes I think !

[peterhinch]

Masking the inputs is defensive programming to ensure nothing breaks if out of range args are used. Alternatively you might test the values and raise an exception:

if not (0 <= reg <= 15):
    raise ValueError "Register value bust be in range 0..15"

Assume value==0x103. The line

vb = value.to_bytes(2, 'little')

will produce

b'\x03\x01'

In other words the LSB is in vb[0] and the MSB is in vb[1].
So

vb[1] | (reg << 4)

puts the 1 into the LSB of the result and the value of reg into bits 4...7
vb[:1] produces b'\x03 i.e. a single byte buffer containing the LSB.
I recommend testing all this at the REPL: it's a great way of learning Python:

MicroPython v1.20.0-450-g3637252b7 on 2023-09-06; linux [GCC 11.4.0] version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> value = 0x103
>>> vb = value.to_bytes(2, 'little')
>>> vb
b'\x03\x01'
>>> vb[:1]
b'\x03'
>>> 

I agree that,at a glance, the line of code looks wrong, but it does what I intended. Whether the chip agrees with my intentions is another matter.

[Comalco]

I agree masking is just defensive, but probably safest for me as a newbie. I have found that inadvertently writing to some locations in the chips creates some seriously weird behavior. I am really thinking whether to bother with the highest value and just use one range of 00-FF. 255 values is still plenty to adjust with, and the 9th bit is cleared on POR. I can see now how your code is working, and why. Thanks for the explanation.. I now can better grasp the steps - and why T0 and T1 arent used as I expected. Do you know of a good book that dives into the deep end of this, and not just a few basic examples?. I have bought a few, and looked at others' code on line, but the books tend to be very simple examples, and online code understandably rarely have any explanation or tutorial content. I will play some more with REPL as it probably is the best way to experiment and learn subtleties .... as youve suggested. Thanks for your help (again).

[peterhinch]

Sorry, I don't know a suitable book. Perhaps someone else can advise?

I think your read bit manipulation should be

def get_wiper(self):
    t = self.i2c.readfrom_mem(self.address, self._WIPER0, 2)
    value =((t[0] & 1) << 8) | t[1]    # move bits, and then mask for desired bits only 
    return value

because t[0] holds the MSB and t[1] holds B7...B0.

However before performing a read, you need to write a single byte comprising the register address and read command as per fig 7.4. Something like

def read_reg(self, reg):
    reg &= 0xF
    buf = byetarray(2)
    buf[0] = self.address
    buf[1] = (reg << 4) | 0x0C  # Read command 
    self.i2c.write(buf)
    t = self.i2c.readfrom(self.address, 2)
    value =((t[0] & 1) << 8) | t[1]    # move bits, and then mask for desired bits only 
    return value

I can't guarantee that this will work, but it's worth a try. If we can get working read and write methods we have a basic device driver which you might like to share.

In your initial example you have self.address set to 0x2E. This looks wrong. It should be 0x50 if you have all the address pins grounded (fig 7.4). i2c.scan() would settle this.

Incidentally, when doing bit manipulations, I tend to use parentheses liberally. It's easy to get caught out by the precedence of the various operators. Brackets make the intention obvious with no penalty in performance.

[Comalco]

The text describes A0 as having a weak pull up on POR.
I have it pulled low on the 50K pot and high on the 5K pot.
I only have A0 available as I am using the 8pin MCP4561s
i2c.scan() shows the 50K device at 0x2E, and the 5K at 0x2F accordingly.
The more I re-read the text and look at the Figures, the more I realise how different this chip family is for I2C !!

[peterhinch]

OK, that makes sense. Table 6.2 indicates that the unavailable pins read 1. Given that the address width is 7 bits, the values from scan are as expected. Did my read_reg show any signs of working?

[Comalco]

The read_reg isnt quite working properly. It returns the incorrect value. A POR sets the wiper memory location 0x00 to hold 0x80.
I have double (triple) checked and I have typed it out correctly. I need to go through it using REPL and try and see why it isnt returning the correct value. We have had great weather tis past weekend so I havent hadmuch time in front of the laptop to delve deeper. Stay tuned!

[Comalco]

OK.....

A typo in your 'bytearray' word on line 3 (I didnt spot it until about the 10th read of my typing),
and a missing self.address statement on line 6 (I couldnt figure out how the i2c knew where to write buf without an address?)
This works;

def read_reg(self, reg):
reg &= 0xF
buf = bytearray(2)
buf[0] = self.address
buf[1] = (reg << 4) | 0x0C # Read command
self.i2c.write(self.address, buf)
t = self.i2c.readfrom(self.address, 2)
value =((t[0] & 1) << 8) | t[1] # move bits, and then mask for desired bits only
return value

def set_wiper(self, value, reg):
value &= 0x1FF # Ensure only 9 bits
reg &= 0xF # Limit to 4 bits
vb = value.to_bytes(2, 'little')
self.i2c.writeto_mem(self.address, vb[1] | (reg << 4), vb[:1])

[peterhinch]

Apologies foe the typo. However I'm puzzled by the line

self.i2c.write(self.address, buf)

because according to the docs i2c.write takes only one arg. The intention of my code is that the address is contained in buf[0]: that is how the interface "knows" where to write. The intention is that the interface outputs two bytes, the chip address followed by a byte containing the read command and the register address.

When posting code samples, if you surround them with treble backtick () characters, indentation is preserved. If the opening treble backtick is followed by py` you will also get syntax highlighting.

[Comalco]

No apology required.
I cut and pasted your code, it threw errors, I looked at it probably 10 times before I spotted the typo :)
I am running the code from one file, not calling to a separate library (yet).
I thought it easier to get the code working, then create a library file for the chip.
This code has been running since I got it working.....and still is right now.
I am reading and writing from a MCP4561 at address 0x2E. My value is called wiper_coarse

Retrieve saved wiper_coarse value

wiper0 = 0
wiper0 &= 0xF
buf = bytearray(2)
buf[0] = 0x2E
buf[1] = (wiper0 << 4) | 0x0C # Read command
i2c.writeto(0x2E, buf)
t = i2c.readfrom(0x2E, 2)
wiper_coarse = ((t[0] & 1) << 8) | t[1] # move bits, and then mask for desired bits only

Note I am using writeto, not write.
I have actually removed the 'to' and the address and restored the syntax to your structure - i2c.write(buf) - and it now works (not sure why it didn't before)