machine.I2C and the stop condition

The official pyboard running MicroPython.
This is the reference design and main target board for MicroPython.
You can buy one at the store.
Target audience: Users with a pyboard.
NielsClausen
Posts: 14
Joined: Sun Dec 13, 2015 5:31 pm

machine.I2C and the stop condition

Post by NielsClausen » Tue Nov 07, 2017 9:21 am

I am trying to communicate with the impedance converter AD5933 through I2C. However, it seems that Analog Devices have adopted their own flavour of block reading and writing, cf. the datasheet p.27-29.

Using the machine.I2C library, I have not had success reading and writing blocks. I have checked, and the *_mem* functions do not yield the correct result with this device.

Cf. the docs, it should be possible to construct the calls the AD5933 specifies, however, I need to control the stop-condtion, which seems to be unavailable? Is this the case, or did I miss something obvious?
Screen Shot 2017-11-07 at 10.18.08.png
Output from terminal
Screen Shot 2017-11-07 at 10.18.08.png (50.28 KiB) Viewed 2230 times
I'm using a pyboard v1.1 with firmware v1.9.2.

NielsClausen
Posts: 14
Joined: Sun Dec 13, 2015 5:31 pm

Re: machine.I2C and the stop condition

Post by NielsClausen » Tue Nov 07, 2017 10:46 am

I have implemented a solution where I read and write a single byte at a time. This works for now, but for a later version I would like to read and write larger blocks in one go, so I am still interested in this topic :-)

User avatar
deshipu
Posts: 1348
Joined: Thu May 28, 2015 5:54 pm

Re: machine.I2C and the stop condition

Post by deshipu » Tue Nov 07, 2017 12:12 pm

If you look at the documentation (http://docs.micropython.org/en/latest/p ... operations) you will see that you have full control over what gets sent and received. You shouldn't have any problems constructing the necessary transactions. Perhaps you should show us your code if it doesn't work as you expect it. Best write a small example program that demonstrates the issue.

User avatar
deshipu
Posts: 1348
Joined: Thu May 28, 2015 5:54 pm

Re: machine.I2C and the stop condition

Post by deshipu » Tue Nov 07, 2017 12:32 pm

Looking at the descriptions of the commands, they look like perfectly normal and standard I2C communication. You should be able to do it with a writeto with stop=False, followed by a readfrom.

User avatar
deshipu
Posts: 1348
Joined: Thu May 28, 2015 5:54 pm

Re: machine.I2C and the stop condition

Post by deshipu » Tue Nov 07, 2017 12:35 pm

It should work if you drop the "stop=" from your command, and just put False in there.

NielsClausen
Posts: 14
Joined: Sun Dec 13, 2015 5:31 pm

Re: machine.I2C and the stop condition

Post by NielsClausen » Tue Nov 07, 2017 3:03 pm

Dear @deshipu,

Thanks for commenting on this. I see that using false as a third and keyword-less argument works! Is the documentation wrong, or do I not get the finer points of how it is documented?

Thank you for your time! See working code at the bottom.

Using primitive operations
Not supported on my pyboard.
Screen Shot 2017-11-07 at 15.40.38.png
Screen Shot 2017-11-07 at 15.40.38.png (67.38 KiB) Viewed 2200 times

Code: Select all

from machine import I2C

I2C_ADDR = 0x0D

i2c = I2C(1, freq=100000)

set_pointer = bytearray(2)
set_pointer[0] = 0b10110000  # Set pointer command code
set_pointer[1] = 0x82  # Register address, to start writing at

write_ba = bytearray(5)
write_ba[0] = 0b10100000  # Block write command code
write_ba[1] = 3  # Number of bytes to write
write_ba[2] = 0x02  # First data byte
write_ba[3] = 0x03  # Second data byte
write_ba[4] = 0x04  # Third data byte

read_ba = bytearray(2)
read_ba[0] = 0b10100001  # Block read command code
read_ba[1] = 3  # Number of bytes to read

def test_i2c():
	# WRITE BLOCK
	# Set pointer
	i2c.writeto(I2C_ADDR, set_pointer)
	# Write
	i2c.writeto(I2C_ADDR, write_ba)

	# READ BLOCK
	# Set pointer
	i2c.writeto(I2C_ADDR, set_pointer, True)
	# Set read block instruction with no stop condition
	i2c.writeto(I2C_ADDR, read_ba, False)
	# Read
	i2c.readfrom(I2C_ADDR, 3)

User avatar
deshipu
Posts: 1348
Joined: Thu May 28, 2015 5:54 pm

Re: machine.I2C and the stop condition

Post by deshipu » Tue Nov 07, 2017 3:17 pm

The problem is that in normal Python, you can always specify arguments as keywords — so the documentation tools used don't give any way of marking if an argument is positional or keyword. However, MicroPython had to cut some corners, and most of its functions can only ever take positional arguments — that saves memory for not having to store their names.

NielsClausen
Posts: 14
Joined: Sun Dec 13, 2015 5:31 pm

Re: machine.I2C and the stop condition

Post by NielsClausen » Tue Nov 07, 2017 3:23 pm

Ahh! Great explanation – will keep that in mind when reading the docs :-)

Thanks again. I have now built my very rudimentary AD5933 driver. When it has been expanded and tested, I will share it .

User avatar
pythoncoder
Posts: 3695
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: machine.I2C and the stop condition

Post by pythoncoder » Wed Nov 08, 2017 7:05 am

@NielsClausen That looks like an intriguing chip but I'm struggling to understand its purpose. As far as I can see it drives an external load with a sinewave and acquires a sample set of the load current. It then performs a DFT on the samples. Given that a linear load will produce only a single point in the frequency domain I assume its purpose is to analyse nonlinear loads. What information about the load can you expect to deduce from the frequency domain data?

Is there an idiot's guide anywhere which might enlighten me about these devices?

Incidentally the point made by @deshipu applies to functions written in C. If you write your own functions in MicroPython, normal Python calling conventions apply: you can optionally specify positional arguments by name in the calling code.
Peter Hinch

NielsClausen
Posts: 14
Joined: Sun Dec 13, 2015 5:31 pm

Re: machine.I2C and the stop condition

Post by NielsClausen » Wed Nov 08, 2017 12:21 pm

The AD5933 measures the complex impedance of the load. I cannot disclose what I use it for specifically in this case, but one use-case is laid out on p. 32 of the datasheet.

I like the chip, as it has almost everything on-board, with minimal post-processing required.

Post Reply