I2C slave device support

CAI_Support

Senior Member
RossW proposed to add I2C support to the PLC firmware.
We are looking into how to add that support.  If this is any interest to you, please let us know which I2C slave device interesting to you.
 
I assume this is for the WC32.
 
I don't have any specific projects in mine but can't go wrong adding external memory and I/O port expansion, mainly digital but analog if it is not too much effort.
 
/tom
 
Tom,
 
This is for WC8.  With current 3.02.17g version being stable, we are releasing additional firmware for users to cheery picking which one would be the best for them to use.  3.02.18 has DS2438 support in, we will try to add I2C support on top of that.  We hope we don't have to remove any feature by doing this. This feature will use two pins from spare header on HW rev 2.2.2 board.
 
It seems I2C has LCD display, EEPROM, pressure sensor, temp sensor, real time clock, etc many low cost devices.  User must do its own I2C slave communication in PLC by provided READ and WRITE commands.  It may worth to reduce some built-in device support for some and allow more user RAM.
 
If I2C bus is long, user may consider add an external I2C bus extender IC.
 
For users with I2C slave devices far from other part of the system, another way is to use WebControl over network connecting those sensors together over network. By WEBSET command to send out slave sensor' data, or WEBSET get server command to send to I2C slave sensor.
 
BaduFamily said:
How are you addressing Ic2 bus length issues?
 
For many of the devices ** I ** want to connect, the short bus length limitation isn't a problem, because the sensors won't be located far away.
I2C isn't a viable option for example, to run temperature sensors 30 feet away!
But if you need to measure barometric pressure, it'll be the same beside the WC as it is 30' away (assuming normal conditions, structures etc), so there's no problem.
Similarly with I2C counters, registers, I/O latches, even additional storage (scratchpad). So it's really horses-for-courses.
 
Once I2C is working, I'm going to lean on Wayne to add SPI (it's arguably easier to implement, and can likely re-use much of the same codebase added for I2C)
 
If you want SPI for the speed, we don't have spare SPI controller on chip any more. The hardware SPI controller is used for on board EEPROM.  That is critical for stable operation, so we do not plan sharing that with any other devices.
 
No, I was going to suggest interfacing via exactly the same way - steal some of the in and output bits and bit-bash it. Not fast, but works. Some devices are SPI only, some I2C only, some support either with a "protocol-select" pin.
 
Bassmanisme said:
I2C would be a nice addition. Would we be limited to specific devices or will all I2C devices work?
 
 
As I understand the current implementation, it's a "budget version", so will only support a single master. The discussions I've had with CAI to date on it should allow us to send any 8-bit address, and send and receive arbitary numbers of bytes.
I didn't mention to (or ask for) support of I2C devices with up to 10-bit addresses or any of the other less popular variations on a theme. Lets just get some basic I2C functionality in there and working. If it warrants extra work, I'm sure it'll get reasonable consideration!
 
We have implemented this I2C support actually is very flexible, but require user knows I2C device himself well.  There are two commands added to the PLC code, I2CREAD and I2CWRITE.  Each takes 3 parameters.
I2CREAD   send_ack   send_stop   read_into
I2CWRITE   send_start  send_stop  send_byte
This two commands will allow user to control any I2C devices, including the 10 bit address one.  There are two things we limited.  One is for slave clock stretching being limited to 255uS now.  We can extend that to a reasonable length during beta testing or later.  Another limitation is Ross mentioned have not implemented master arbitration in current release.  We want to hear from users first and decide if that is useful and providing test case.
 
send_ack, send_stop, send_start, and send_stop are 1 or 0.
 
read_into is an unsigned byte  If you are reading a negative value from the sensor, please make sure to map that into part of the RAM can be read as negative.  On WC8, we have RAMx accessible from each four bytes.  Carefully set the data value will show negative.
 
send_byte is for the byte being send out to the slave.
 
For example, BOSCH digital pressure sensor BMP180 is an I2C sensor.  Its I2C address is 0xEE
To issue command to start pressure conversion from PLC logic, these commands are sent:
 
I2CWRITE   1    0   0xEE
I2CWRITE   0    0   0xF4
I2CWRITE   0    1   0xF4
that is on BMP180 data sheet page 21 example.  Then wait long enough for the pressure sampling 25ms
 
After that, PLC can read result back
 
I2CWRITE   1    0  0xEE
I2CWRITE   0    0  0xF6
I2CWRITE   1    0   0xEF
I2CREAD     0    0   RAM11
I2CREAD     1    1   RAM12
 
That is the example in Fig 9 of the datasheet.
 
You can construct pretty much any command sequence to any slave device.  WebControl takes care all the low level timing and signal handling.
 
Bassmanisme said:
Can you give an example of writing text and/or data to an LCD if that will be possible?
 
As we don't (yet) have defined tables, arrays or "strings", it'd be a laborious process of loading up to 4 bytes as constants and sending them... it might be ok to send small amounts of text, then convert and output numeric values... but it would still be quite laborious!
 
When writing to LCD, it must take account into delay between commands, since LCD is slow device.  But it will be doable.  You will need to check the I2C LCD datasheet to get the I2C command sequence.  Since the LCD is write only, nothing reading back, you will only need I2CWRITE.
 
In most I2C device, you first I2CWRITE must have first parameter 1 to send start, only the very last I2CWRITE send 1 to second parameter for stop.
Each time sending the device address, you will need to send start, if that is already started, it will be considered as restart by slave.
 
Because each line has a lot of characters, each one will take a line in PLC, it will save PLC lines by formalize that into function. Then call that function when needed.
 
Back
Top