I2C 16bit ADC expansion for WC8

This little ADC board is based on TI ADS1115, it has an I2C interface talking to Webcontrol I2C interface and four 16 bit analog channels. We will provide detailed programming help in this thread. 
 

http://www.ebay.com/itm/361338787943

datasheet from TI is here:

http://www.ti.com/lit/ds/symlink/ads1115.pdf

 
 
 
 
 

First step is to find I2C device's address. Each I2C device has its own unique address on the I2C bus.
According to the above mentioned datasheet page 17, its I2C bus address is from 0x48 to 0x4B
For convenience, we just has its address pin tied to ground, so that this modules' I2C address is set to 0x48.  If you have more than one same module, you can have each module set at different address and co-exist.

Read and write to the I2C device
I2C device address is 7 bit address, like above mentioned 0x48, or binary 1001000.  Most I2C device has read and write mode. The way to tell this I2C slave read or write is by shifting the I2C address up one bit, then pad 1 to indicate the action is read, pad 0 to indicate the action is write.  For the address 0x48, we will talk to this module on the following two addresses: 0x91 for read and 0x90 for write.

Whoopie, thank you!

Sorry, didn't mean to pollute the LCD thread, you led me there, and when Ross answered I wanted to leave a reply.  Thanks for starting a new topic.

I looked at that one first, and asked about it in the other thread, but hearing nothing, and not finding the 'ads1115' string here anywhere, I got muddled down in the bit word question.  In the manual the "DS2450 chip has 10 bit resolution", and I hadn't see any mention of the fields being 16 bit, so I was stuck on the ADC choice.  It also does say "AIP1  Analog Inputs 1...3 Valid range 0 - 1024" and that 1024 value did suggest 10 bit as well.

I had already made a pcb for the DS2450, it was on there with the bypass caps and input resistors six months ago, shortly after I bought the webcontrol, and I was OK with it & ready to go, but at that time I was resolving an issue with the temp sensors sometimes vanishing from the bus and didn't want to compound things.   Then it got shuffled aside for another task on the bench, and the sensors weren't immediately necessary, so there it lay until the lightning strike.  Using this method looks to be much better because it appears like it will allow adding 12 sensors instead of only four, and at the moment that's a good thing.  The Vars are stated as 32 bit, so that's good too.

I spent loving time with these docs last night on adafruit, I have the datasheet pdf and understand the addressing, and I am looking at arduino speak for making it do tricks.  I'm glad to hear you mention the feature this chip has, to change its address by tieing ADR to GND, VCC, SDA, or SCL, since I'd like to use three of them.  But I wasn't being presumptuous that this would work on the fully supported webcontrol implementation. I'm going to take what you've said as confirmation that it will

So now I have three of them coming in the mail. I elected to pay a little more and forgo the three week economy shipping, but the sole CA vendor only had two in stock.  Should be here in a few days.  He only had three to begin with, I'm guessing maybe you snatched the other one     My third will come from Alice by epacket, that's usually pretty quick from them

If you are going to be on willing standby for plc cleverness that can only be good.  Thank you

Meanwhile I will figure out some cabling to my antiquated "spare pin header"

My board is 2.2.2, my firmware is v03.02.18b5, my manual shows SCL and SDA on the header...Do I need to flash this thing before it will be obedient with this ADC?
 

If you do not plan to use features only on older firmware, then it is always a good idea to have board running latest firmware.
 
Sure, you can have 3 of those ADC board running on a WC8, but WC8 has limited RAM and VAR storage space, whatever your code wants to do will have half its RAM or VAR taken by storing the ADC values. 

CAI_Support said:

whatever your code wants to do will have half its RAM or VAR taken by storing the ADC values. 

Click to expand...

 
Thanks, yes, I realize that filling up the VARS with data could lead to a juggle, and I have been thinking about Ross' suggestion regarding his weather station method.

As it is, my plc is operating some lights, a fan, some pumps, a valve, gating an intermittent mist system on its own dedicated timer, and was also gating the fertigation controller that died from emp.  It's making decisions about these things from the clock, the humidity, all the temps, and the on or off status of some other equipment, including a pc sending bits out a labjack.  and I still haven't used a single VAR location.

I am popping a few things thru ram.  Although it is running some equipment, its primary function is a sensor net for data logging, and if getting 8 more sensors takes half the ram, I haven't met the problem with that yet.  I doubt my few lines of code are consuming half already.  I don't know yet what the cogent PLC is going to be to operate the ADC, that effect on ram, so best results will depend principally on that, I think.

I was only planning on getting four inputs with the 1 wire solution, atm more is better, I'll take what I can get.  If I have a leftover ADC the wc32 will absorb it.


As far as flashing up, I asked because I definitely do NOT want to do it at this time, unless my current firmware simply isn't going to let this ADC work.  There's a string of reasons.  It's in service already, even a successful flash will interrupt that, and I don't have a spare to fill in during the exercise.  A bad flash would be semi catastrophic.

I've flashed plenty of devices thru the years and seen what can happen.  I never use wifi, for the flash or the bin d/l, I always connect direct w/ a crossover cable, never a switch or hub, and I always use a UPS.  Things can still go wrong.

I've already read two failed flash events here.  The advised caution about wifi does not cover all the reasons, and I only saw that one of the two hapless campers was on wifi.

A bad d/l can also cause a flash to hang halfway thru, and there is no hash file in the firmware zip, so no way to verify the file integrity before throwing caution to the wind, except maybe asking here.  If you have a SHA for this firmware link you posted, I really appreciate that for later.  I don't know if the loader checks using a crc value inside the bin, but I thought I read here somewhere that it doesn't

Even a verified file can still fail upload for no apparent reasons.  I have a small brick collection, only two, but it has happened

I'm just not ready to take *any* unnecessary chance of finding out if my router will object to ff:ff:ff:ff:ff:ff, or paying shipping + $10 to get a new mac address, and lose a week or more.  not just yet   That's why I asked 'do I need to'


I have Firmware Version:  3.02.18b5.  On cainetworks /manuals, you have

WebControl 8 PLC FW 3.2.18a PDF
Version: 3.2.18a
Hardware Version:  2.2.2
Firmware Version:  3.02.18a,b,b2
Firmware datastamp:  5/8/2014
Doc last modified:  8/12/2014

You don't have it there anymore, but you used to have

WebControl 8 PLC FW 3.2.18d PDF
Version: 3.2.18d
Hardware Version:  2.2.2
Firmware Version:  3.02.18d
Firmware datastamp:  8/5/2014

My version is somewhere in between, and there is no other manual I've found that claims it, or is between these two.  They are only three months apart

If I look in the 18a manual, I see a spare pin header with SCL and SDA for I2C
If I look in the 18d manual, I see that MOSI MISO & SCLK for SPI have been added

In the minor version changes over three months that span my version, there is ongoing development occurring, and I don't know where my board is in this, because there is no changelog past 17e, and the 17e pdf manual shows blank-nothing where the spare pin header will eventually be

Anyone home? ~ "We did have I2C firmware for testing, but that is not officially released." (22 May 2014 - 08:24 AM)
18a manual shows a firmware timestamp of May 8, but on May 22 it's not officially released.  I can imagine how that might be, but it still adds some grey to the fog

I2C slave device support ~ On 27 May 2014 - 09:47 AM You ask Ross, "You got the test firmware working?"
So testing is ongoing.  Ross' weatherstation is working w/ I2C on 11 June, and I take that as a golden indication, but saw no mention of which firmware

WC8 I2C related user guide updated Jun 18 2014 09:49 AM ~ might seem to be an announcement that this is all working, but still refers to 3.02.18a firmware.  Doesn't seem unreasonable to wonder if 18 June is past my 18b5, as I can't seem to discover its datestamp.  The modification date for the 18a manual is a few days after the release of 18d, but the 'Firmware Version:' string still hasn't been updated to show my b5 version.  In other software, versions that go undocumented, between the others noted as stable releases, are often bugged versions, swept under the refactoring carpet.  I'm not saying mine is, only asking
 
In the 18a manual under I2C is said "WC8’s I2C support includes clock stretching up to 255 uS. It does not support bus mater arbitrition at this time."  Other than the arbitration issue, still recently being discussed, I don't yet know what that might mean regarding the operation of this ADC, and in general it implies to me that 18a may not be in the 'fully supported' state.  It includes one thing, and doesn't include something else, but is that the whole story?  It's ambiguous to me, and I have read some incomplete and incorrect answers in other topics, so I'm trying to vet this.

Is 18b5 all the way there besides arbitration, or at least, has it the support necessary for this ADC?  I dunno.  Only you know that.  Well, Ross might know, especially if he had one of these versions, and others with more I2C experience might know, but I don't

were there maybe fixes or additional feature support in 18c?  Am I going to find trouble trying to use the ADC, then eventually be informed that I need to flash up because something was patched or added right after my release?

If so, that needs to be a planned event, if possible, Please.  I have to consider this ahead of time and plan for it if necessary.  But I also need to skip it for now if I can

tried to discover this by looking in the docs and forum.  didn't work, so asked.  tried one sentence, in bold.  A yes or no reply would have left this post much much shorter.  sorry if I wasn't making it clear the first time. I really appreciate the help with this, but can't move ahead with equivocal answers
 

From my own perspective and experience, might I say that if you have a critical application, you really, REALLY need to lash out and buy a spare board.
A spare board also means you can test new code, new sensors, new communications concepts etc, without disrupting your existing production environment.
You can then drop the new board into "production" and reflash the older board at your convenience, without the potential drama of it all going pear-shaped.
 
For the relatively low cost of a second board, it buys a whole lot of "peace-of-mind"

Thanks Ross.  Clear headed and precise, so very appreciated.  I agree, and that could be one of the options, depending on the answer.  But if an incomplete answer is to encourage an additional purchase, well that's not as good as it could be?  Low cost is relative, there can be time-of-month and other variables, but above that there are tedious practical responsibilities here atm that make doing that a task that would be better delayed.  If possible.  Additionally, the wc32 + IO board is already in that purchasing slot, and I would really appreciate being able to wait awhile on bringing a 2.3.8 board into the fold.   Right now some good intel would be worthwhile, and it didn't seem like too much to ask.  When I asked why this info isn't on the site so that I can find it out for myself, the answer was 'We don't mind email discuss with customers to verify their board revision'.  Unfortunately perhaps, the surest way to prevent me from sending an email is to put a contact form between us, so I will always default to a discussion page instead, if one is available.  If the answer simply isn't known, I can appreciate that too, I don't know it either.  But 'it's always good to have the latest firmware' is generic info (that even I know), and it doesn't help me make a decision in this case, so just trying to be clear in case there was a misunderstanding

Klaatu,
 
Although firmware you have is stable, it does not mean we will not continue adding more functions and features to WebControl, thus release newer firmware. If you don't really use those new features, existing firmware did not make one missing anything. If you do have the need for new feature, then please do let us know. We will help you just like any other customers. If a solution requires new firmware, and it is feasible by our engineers, we will work on it for you. 
 
The 3.02.20 user manual is online. You don't have to get middle versions one by one, simply update to the 3.02.20, you will get all the features listed in the 3.02.20 user guide. That is a release with all the features and it is released more than 3 months and used by a lot of people already.

I appreciate the response.  I can't seem to find where I have asked for any new feature yet, and I can't help but think that there is some kind of a communication issue here.   I have no further ideas on how to be any more expressive about my present concern

I'm going to interpret 'firmware you have is stable' & 'existing firmware did not make one missing anything' as meaning that I do not need to flash yet in order to get the ADC working.
 

CAI_Support said:

The 3.02.20 user manual is online. .... simply update to the 3.02.20

Click to expand...

The apparent focus on 3.03.20 does give me some trepidation, especially this part about 'simply update to the 3.02.20', after the previous Great Wall of text about why updating isn't simple at the moment.

I also see Efreid making a comment in Ross' Weatherstation based on WebControl8, about 'the board where we may run I2C is a WC8 V18d only'

I don't know where he had found this info, so I can't verify it, but 18d is after my version, like 20.  And there was no response from on high disputing this statement when he made it.  He also voiced a similar concern about the lack of open answers: 'is interesting that CAI does not publish version numbers and capabilities in a table, so owners may orient themselves'


Moving on, saw this statement of yours in the same thread:
'The goal is to let everyone learn how to use the I2C and SPI feature to communicate with all kinds of sensors and IO chips.  For example, there are limited RAM space and when power lost, data could lost. However, if you have I2C based RAM and EEPROM, you can expand storage into external RAM and EEPROM.'
 

CAI_Support said:

WC8 has limited RAM and VAR storage space, whatever your code wants to do will have half its RAM or VAR taken by storing the ADC values. 

Click to expand...

When you pointed this out up above here, you didn't mention I2C based RAM and EEPROM as something that might address that.  Would it?

I've looked at the datasheets for some I2C static ram and eeprom, perhaps while we wait for ADCs to arrive, if you feel like it, you could discuss this here a little bit?

I searched the forum for some part numbers, for instance PCF8570 256 × 8-bit static low-voltage RAM with I 2 C-bus interface (this is a really old chip, but is on ebay) or the AT24C256 Serial EEPROM Module I2C EEPROM Data Storage Module, also on ebay, commonly.  This isn't to derail the topic, only some mention in support of it, for instance if someone wanted to add all four ADCs.  Neither part number is found in discussion here, but neither was the ADS1115.  If you know of some more suitable or appropriate components, since you offered this suggestion in Ross' thread, maybe you wouldn't mind giving some examples that you know will work?

The webcontrol hides all the timing, which is fine with me, but I don't know how that affects which of these chips might be compatible with one.  Or which might be employed to support using additional sensors, and provide a method for storing values in external ram during reads and computation.  Or writing them to eeprom after all the native variable locations are filled, and how those locations might be successfully polled.  I think I can eventually imagine what the plc for this might be like, but can the board actually handle some of these and still manage all the sensors too?  I've read that the webcontrol can't ping out because if the target device is close, the cpu can't finish its housework in time to deal with the return ping, so I'm guessing there could be limitations.   For instance, perhaps the write speed of the eeprom, or even the ram, depending on type.  I don't know if any of this is particularly meaningful, and a few details would be illuminative.

I'll volunteer to be supportive of the goal to let everyone learn how to use the I2C feature to communicate with all kinds of sensors and IO chips.  If it's not too late.  I might be the last one.

Only while we wait... my california vendor appears to be slow to ship, the chinese epacket might get here first


 

Klaatu,
 
WebControl provides a lot of functions and features in its firmware without requiring user know much about attached chip modules.  Majority of users use WebControl that way.
 
However, due to DS2450 was not accurate and many other sensor chips could not all be included their low level support in the firmware, we added I2C and SPI to let users with engineering background or users willing to learn some electronics to expand their WebControl functions. 
 
When adding I2C and SPI features, we did it in steps by adding I2C support first, then removed DS2417 and DS2450 support, then added SPI support.  Maybe that is not what you think the best way, but it is the way for users who interested to use it from last year.  There is no product on the market is suddenly became what they are.  That is no secret.  If anyone keeps following this sub-forum, it will receive notice from this forum of all the discussions and progress on the firmware changes.  That follow option on the sub-forum upper right corner.
 
We believe what we did is for the best interest for most customers.  We know we can not satisfy everyone, but we tried and still trying.

Hi Klaatu,
 
I2C based RAM is different from RAM inside the processor. Definitely, external RAM or EEPROM can be used on I2C bus, so that user's PLC program can store value to them. But it will not expand how PLC or other part of the firmware operating.  Once we received this I2C ADC module, we will finish up how to program the ADC module.  Then we can move on to other modules.
 
WebControl PLC has no limit on what kind of I2C devices can be attached, except another I2C master.  We try to hide lower level handshaking from WebControl users, so that it is easier.  However, when two I2C master attached to the same I2C bus, there are chances that both masters started talking at the same time.  When that happening, it is hard to hide the collision handling from PLC users, since users must handle retry logic etc.  Maybe in the future our developer can come up a way to better handle that collision so that two master can easily co-exist on the same I2C bus. Until then, that is the only limitation on the I2C usage.
 
I am impressed that you are such an electronics expert from very young age.  I have talked a few of them on this board, some of them sending us private messages with good suggestions, some of them even helping us by providing very good consulting work.  We appreciate each and every one of you. WebControl as a hardware board has its limitation, no matter which processor to use, but how to use it in automation control has unlimited ways.  Let the fun roll...

Thank you.  I realize that adding ram to the I2C bus is not adding system ram, only giving me more locations to store variables.

If I were to add that and be able to dispense with most of the native ram locations provided for using in the plc, except for what might have been necessary to load the external ram, and had the thought that the freed onboard locations could or should somehow be utilized by the system, like maybe with a jumper, that would be in the category of a feature request, and I am not thinking about that.  I don't even know if it is possible.  But having some spare ram locations for plc variables seems like a nice option, and I'd like to explore it.  I just didn't know if there are any limitations in chip selection, that's the first step, and I am not seeing anyone else doing it here. Once I have the parts in hand, given time I can figure out how to proceed with it, I wasn't asking for that info.

Thanks for letting me know that "PLC has no limit on what kind of I2C devices can be attached, except another I2C master", that is really the part I needed to hear most.  Now I can try stuff with abandon, if I have the time, since the parts are relatively cheap. I don't foresee needing arbitration, Ross will have to bug you about that

I didn't offer personal history to make any impression, and I'm not any expert at anything, certainly not electronics.  I just benefited from an early start by growing up in the environment.  My interests are too diverse and I never specialized, I studied physics as a generalized background framework for problem solving, which is what I do most.  Maybe from the mathematics influence.   I only went into a few details to make sure I could offer some qualifications for background and willingness, if that's part of getting a little I2C support

I deeply appreciate getting back on track, and would like to spare visitors having to blind themselves on the way down.  I'm happy to delete the post now that it seems an understanding has begun.  I think yours should be also because it really doesn't apply to me, and I am still confused as heck by it.  That's up to you, not me, just saying.  Would be better focus for the thread.  They don't need to be between my question and your answer

 

Eight 32bit VARs and eight 32bit RAMs are all the internal storage can be used in WC8. To do I2C communication, it will need to have certain RAM or VAR allocated for that purpose.  After experimenting with an I2C sensor, it can calculate how much RAM is needed for communicating to that sensor.
 
I hold nothing against customers, maybe what I said upset you, but that was not my intention. Certain person you mentioned brought up some memories. But what I said was our true attitude toward  such person. No matter what he said in the past, we still try our best to help. I appreciate you put up with me and gave us chance to work with you.

Thanks very much for that info, all of it.  Humans are so complex I can never be sure, a lot gets processed in the background, & I lack some of the dedicated wetware that most others enjoy for that.  Earlier I was forced to read every post, starting at the last page, so nearly all of it was still fresh in short term ram, and the intuitive result had a high confidence index.  Confirmation is always good. Sorry, it wasn't anything intentional, awareness was only triggered when I saw your paragraph and recognized it

So far eight RAMs has been more than enough, and I haven't touched the VARs.  I used the most when I had to set three time intervals and OR them together, two at a time.  There might be a better way but I still didn't use it all up.  I don't know yet what icreading and icwriting are going to entail when using the external ram to store or operate on results, how much benefit it may provide, or what the tradeoff will be, but the parts are cheap enough to find out and I am curious.  If it lets me use all four ADCs on one wc8 that would be cute.

The eeprom might also be cool.  I'd mostly like to use an spi micro sd eventually. I looked at the lcd plc for writing bytes/ascii, that was happening like I supposed.  Earlier Ross had said he thought that would be fairly cumbersome without tables and strings, but it still seems to work.  I don't know how busy the cpu gets, just need to try and see.  I don't recall seeing anyone ask for a console port, some way to see cpu & memory load, like 'top'.  I imagine you have that for debugging at least

I hired a temp to free up some time, as long as the fun doesn't go on too long.  I can't travel w/o my full automation systems 100%, and I need to for some work.  I think I know pretty much how to do this now already, since I read everything, but I can be fooled by myself.  need the parts here to find out