28x2 In "I2C Slave" Mode, Not Working

J

jsmanson

Member
Hi fellow campers, I am having some difficulty getting two 28x2's (5 volt) to chat with each other using I2C. Picaxe #1 is going to be set up to monitor water flow pulses (5 of them) and record to the scratchpad the cumulative flows (in liters, about 330 pulses per liter), as well as instantaneous sensor data (4-20ma), all of which will sit in scratchpad memory. The program will also occasionally read a value from the scratchpad, and will turn on/off a couple of digital outs based on the value in the scratchpad.

OK, a second picaxe 28x2 is being programmed to simulate what will eventually be a netduino or similar device operating about 100 feet away from the above picaxe. I want to use I2c between these, along with RS-422 adaptors at each end due to the distance involved (I beleive you can run I2C on an Rs-422 transmission system from what I can understand).

So, for now, I just want to get basic I2C up and running between the two 28X2's just to test communications etc. I set picaxe #2 as an I2CMaster, i2cslow speed, and set the adress to %1010000. I also programmed Picaxe#1 to I2cslave, i2cslow, same address, and that was about it for that one. I started with both pic's running at 64mhz using an external 16mhz oscillator. I have pwm'ed out signals from both pics to confirm that the oscillator is working correctly.

I also have a logic analyser, so I can sniff the I2C line and see what's happening, using a "Lab Nation" analyser, in digital mode using I2C protocol, works really well.

So with both Pic's running, I can see picaxe # 2 sending out the first I2c command which is to read from picaxe#1's scratchpad. I can see the start of the I2C's transaction, with the correct address, %1010000, but picaxe#1 does not alknowlege the transmission. (The analyser shows "NACK", not "ACK").

Both Pic's are set to the same I2C address, I have tried it runing both pic's at 64 mhz (they share the same oscillator running at 16 mhz, the 28x2 runs at 4x the external oscillator, "setfreq em64"), and I have also tried running the 28x2's at their default 8mhz. I have also tried runing i2cslow and i2cfast, all scenarios without any alknowlegement from picaxe #1.

Are there any specific timing issues or constraints when using I2C with the 28x2 picaxes that I am not aware of? I am hoping to run the 28x2 at the full 64 mhz so it can reliably read and process the water flow pulses, and I am hoping that the i2c bus will run properly at either i2cslow or i2cfast (100khz or 400 khz) with the pic running at 64mhz. Any ideas on why #1 is not alknowleging the I2C transaction would be appreciated.
 
hippy

hippy

Ex-Staff (retired)
It is probably best to start with default internal oscillators and default operating speed. Perhaps post your code though it seems your are starting simply enough and maybe a photo of how things are wired in case it's just a connection or wiring error.

It obviously should work, it's just a bit difficult to make a guess as to why it isn't.
 
J

jsmanson

Member
hippy said:
It is probably best to start with default internal oscillators and default operating speed. Perhaps post your code though it seems your are starting simply enough and maybe a photo of how things are wired in case it's just a connection or wiring error.

It obviously should work, it's just a bit difficult to make a guess as to why it isn't.
Click to expand...
LOL Hippy you don't want to see a photo, many many wires lol! The I2C connections are straightforward, SDA on C.4, SCL on C.3 ,4.7 pullups on both, both chips flashing an LED so are runnig fine. I think I will write a simple one line "i2cslave" program on #1 to get the communication going, i2cslow on the master at 8mhz, then start changing parameters until the communcation drops. You're not aware of any limitations on I2C with respect to running the picaxe at 64mhz? I am assuming that the i2cslow and i2cfast paramaters will cause the pic master to run the i2c bus at 100 or 400khz respectively, no matter what the pic itself is running at...

I will also measure the clock frequency coming from the master to make sure it is runing at 100 or 400 khz, I didn't do that last night, even though the analyser did identify the signal and was able to translate it properly. I also presume that when a picaxe is set up as a slave, it automatically determines if the incoming I2C signal is running at 100 or 400 khz, as the hi2csetup command does not contain a speed paramater when it is run in slave mode, it only uses one when setting up in master mode. I will report back tonight on my progress, thanks Hippy.

John
 
J

jsmanson

Member
OK, I think I know my error, I used the generic i2cfast and i2cslow parameters, I should be using i2cfast_8 and i2cslow_8 when in default 8mhz mode, and hopefuly there is a similar i2cfast_64 and i2cslow_64 paramater for running this baby at full speed. I'll give that a try.
 
I

inglewoodpete

Senior Member
jsmanson said:
....I think I will write a simple one line "i2cslave" program on #1 to get the communication going, i2cslow on the master at 8mhz, then start changing parameters until the communcation drops.
Click to expand...
"Changing the parameters" is a bit academic. You can experiment but you will return to the defaults when including a PIC as a slave: i2cSlow_x.

jsmanson said:
....You're not aware of any limitations on I2C with respect to running the picaxe at 64mhz? I am assuming that the i2cslow and i2cfast paramaters will cause the pic master to run the i2c bus at 100 or 400khz respectively, no matter what the pic itself is running at....
Click to expand...
i2c is independent of the chip speed, although the chip must be running fast enough to process the data. I learned that when trying to run them at 4MHz while debugging some code! It doesn't always clear its buffers at that speed.

jsmanson said:
....I also presume that when a picaxe is set up as a slave, it automatically determines if the incoming I2C signal is running at 100 or 400 khz, as the hi2csetup command does not contain a speed paramater when it is run in slave mode, it only uses one when setting up in master mode.
Click to expand...
A slave is a slave. The clock signal is coming from the master.

Don't use i2cFast_x if one of your slaves is another PIC - it's just too fast for a PIC to keep up with. In fact, there are only a limited number of i2c slave chips that can process data at that speed.
 
J

jsmanson

Member
OK, no luck tonight either. NACK's all over the place!
I wrote two very simple programs, one runing the i2c master, one running the slave. The master sends out 3 bytes of data repeatly. The slave justy sits there in a loop waiting. The two .bas programs are enclosed, both 28x2's run at 8mhz, the master is set to i2cslow_8 (100khz), which is a clock cycle time of 10us. I aso ran both at 64mhz, used i2cslow_64 on the master, the cycle time on the clock was a bit faster than 10us, it was around 8us, so I stuck with 8mhz to eliminate this possible issue.

I have also enclosed a photo of the chips setup, the one on the left is the master, the one on the right the slave, but they are wired identically. I also do a 100khz pwmout on both picaxes, and I display that signal along with the i2c signals, so we can compare the i2c signal with what should be the same cycle period. So in the doc file I have enclosed, you can see a couple of screen captures with all three signals there. The I2c bus is loooking like it's at 100khz, so that is fine. But the second slave is not responding to the i2c call, as the scope shows the NACK, not a ACK respince to the first transmission of the address data, which matches both programs.


Any ideas folks?
 

Attachments

techElder

techElder

Well-known member
One of your mistakes is the series resistors at SDA on the righthand 28x2. The photograph shows that they don't meet in the middle. No pullup on that pin.
 
J

jsmanson

Member
The photo isn't great - they did meet in the middle, the SCL and SDA lines both sit at 5volts as seen on the scope, I also had an embarrassing addressing problem, left a '0' out in one of the addresses, so that didn't help much lol!
 
You must log in or register to reply here.
Top