I2C 16bit ADC expansion for WC8

[CAI_Support]

The ADC continuous conversion has no problem with WC. You only need to configure that chip once during power up. Then when you want to check the value, read from the sensor register and validate that is a valid value, if so, then store it in AP5,6,7,8, etc. In WC32 case, validated the value then store in VAR or RAM whichever you selected to store them.

 

[klaatu]

The ADC continuous conversion has no problem with WC.

validate that is a valid value

tnx for the info about the continuous conversion, I'll leave it set that way for subsequent testing

as far as value validation, the data sheet seems thin on that step.  checking that it isn't FF, then reading again if it is?  or what?

 

[CAI_Support]

You are right, there is no place to check conversion ready in registers. But it does have a READY pin that can be connected to the TTL input, so that each time you address MUX to switch analog input to another one, check that is READY, then do the I2C read for conversion result.  If you only use one of those four analog inputs, then you probably don't need check. I think datasheet saying when initialized, it sets the register to all zeros.

 

[klaatu]

Ah. ok, I see it

"When in continuous conversion mode, the ADS1113/4/5 provide a brief (~8µs) pulse on the ALERT/RDY pin at the end of each conversion."

That page dealt with the alert/ready pin being used with the comparator, which I have disabled.  So I hadn't really read thru that.  If it is necessary, outside of enabling the comparator, it would have been a nice tidbit for them to feature a little more prominently, like in the quickstart example

I have been testing with just a single input, not seeing any zeros, that might be a refreshing change from FF.  So is this suggesting that I have to scan one of my ttl inputs, wired to the ready pin, and catch an 8us pulse, then use that to trigger my sub that does the read?

As I am understanding the continuous conversion, the value is essentially always available, just being updated at whatever the data rate is.  I have to specify which of four inputs I want to read the value from, then when that byte is in the config register, the conversion register gets set to the current value from the selected input,  then I can read it.  still not clear how long each of these steps takes

Here is where I might have imagined that the wc is semi-magically handling these event timings, behind the curtain.  similar to the 1 wire.  because it's just that smart
 

 

[CAI_Support]

I think that this chip inside will make sure conversion result register value is always a valid one, not half valid one. It probably has other places to store a value then copy over in one shot. Other than when switching to different analog input, it probably does not have need to check ready pin.
 
WC PLC engine hide all the I2C timing handling, low level bit transmissions from PLC coding. User still needs to know I2C registers and configuration on the sensors, but no worry for lower level hardware communication.

 

[klaatu]

Other than when switching to different analog input, it probably does not have need to check ready pin.

That's what I'd like to expect.  but I do need to scan thru all four inputs, and I half thought that at most using some brief delay would be enough to ensure that the conversion register had an updated value before each read

 

[rossw]

I have been testing with just a single input, not seeing any zeros, that might be a refreshing change from FF.  So is this suggesting that I have to scan one of my ttl inputs, wired to the ready pin, and catch an 8us pulse, then use that to trigger my sub that does the read?

 
You've got almost no chance of catching an 8us pulse using a TTL input and software scanning.
*IF* you need to do it, I'd use input 1, configure it to a counter, and check for a counter increment.
 
However, there should be in the documentation a "worst case conversion time" - which probably should include (or add to it) an appropriate input settling time. It's highly unlikely to be more than a few milliseconds in any case, and could be achieved by a fixed program delay of a few milliseconds. OK, it may slow your code down ever so slightly, but I doubt you're needing to squeeze every last microsecond out of your application

 

[klaatu]

You've got almost no chance of catching an 8us pulse using a TTL input and software scanning.

exactly      I've been told my delivery is too deadpan

My counter is tied to the kwh meter and isn't giving it up, nor would I go there anyway

I expect that a delay should be adequate, and non troublesome.  I have tried some, based on estimates from the data rate, as yet to no avail.  think your observation about addressing is likely, but I dunno yet where it is borked.  Plenty else to do, and still some hardware trickling into the POB, so now waiting for the expert code

 

[klaatu]

actually the delay testing did maybe show a clue, but I'm not sure at all how to interpret it.   adding even a 5-10ms delay between setting the pointer to the conversion register, and initiating the read, results in the value oscillating intermittently between 0 and FF, one or the other, & not in any even time interval, maybe every 1 - 10 seconds, seems random.  the zero value is less persistent, most of the time it is FF

the only clue I saw in the manual was the SPS rate which suggested conversions taking no more than 8ms at the default setting

 

[klaatu]

ok, under "DUTY CYCLING FOR LOW POWER", another section that didn't get my undivided interest...

For example, an ADS1113/4/5 in power-down mode with a data
rate set to 860SPS could be operated by a microcontroller
that instructs a single-shot conversion every 125ms (8SPS).

Because a conversion at 860SPS only requires about 1.2ms, the
ADS1113/4/5 enter power-down mode for the remaining 123.8ms

so 2ms should be enough, and isn't going to negatively impact any other ongoing processes in my use

 

[CAI_Support]

Sure, if that is case, do single conversion, and check ready pin to be high, then read from the chip.
Please note when reading, you need to read two bytes, first byte is most significant, second byte is least significant byte.  they make up 16 bits in total.

 

[klaatu]

set pointer to conversion register:

    i2cwrite 1 0 0x90    # address 0x48 plus write 0 bit appended
    i2cwrite 0 0 0x0      # points to Conversion register

next come the reads:

    i2cwrite 0 0 0x91        # address 0x48 plus read 1 bit appended
    i2cread 0 0 RAM21    # store MSB aip0 conversion value in MSB RAM2L
    i2cread 1 1 RAM20    # store LSB aip0 conversion value in LSB RAM2L
 

please note... reading two bytes, first byte is most significant, second byte is least significant,  they make up 16 bits in total (ram2L)


I've tried delays in here, with both single read and continuous.  maybe the ack/send/stops aren't right?

 

[CAI_Support]

I think you may need to have start bit on when telling sensor to read
 

i2cwrite 1 0 0x91 # address 0x48 plus read 1 bit appended

I don't have module to try it, but a lot of them  will need start/restart
 
When you finish, you should have end 1, but start should be 0.
 

i2cread 0 1 RAM20    # store LSB aip0 conversion value in LSB RAM2L

 

[CAI_Support]

Do you have all the code?  Look datasheet fig 30, first to tell sensor which register to read, then second time to actually read those two bytes in.
 
Each time when specify the address 0x91, you will need to have start bit 1. when finish tell register address, need to have stop bit 1.

 

[klaatu]

first to tell sensor which register to read, then second time to actually read those two bytes in.
 
Each time when specify the address 0x91

 
I don't get that from reading the quickstart.   I am only using 0x91 a single time, to initiate the reads, not when setting the pointer to the conversion register.  there it is 0x90, like when it is first set to the config register.  the guide uses the low bit 0x90 both times when writing to the config and conversion registers, the high bit 0x91 is only used once before the two reads.

    i2cwrite 1 0 0x90        # address (write)
    i2cwrite 0 0 0x1          # pointer to config
    i2cwrite 0 0 0xc0        # 11000000 = aip0, pga = +/- 6.144v, continuous
    i2cwrite 0 1 0x83        # default data rate, comparator disabled

    i2cwrite 1 0 0x90        # address (write)
    i2cwrite 0 1 0x0          # pointer to conversion

    i2cwrite 1 0 0x91         # address (read)
    i2cread 0 0 RAM21     # read first byte
    i2cread 0 1 RAM20     # read second byte

    SET VAR2 RAM2L


no change with the modified start/stop, still 65335.  I was hopeful.  If I add 'delay 2' either before or after the 'i2cwrite 1 0 0x91', then sometimes it will briefly read 0, then change back to FFFF