i2c details - help

[Hundred1906]

I thought I had picaxe - picaxe i2c cracked but now I am not so sure and could do with some guidance setting up a reliable link.

I am using two 20x2, one master, one slave with 4.7k current drive. Both on a pin-board within 4 cm of each other.

1. Is there a relationship/dependancy between the clock frequencies of the Master and Slave. Ie do both need to be at the same clock speed (M32, M64, etc)?

2. From a reliability perspective what is the ideal i2c speed for the Master to use with a 20x2 Slave (Slow_ or Fast_). Assuming slow is best is I2cslow_64 the best combination?

3. Is it necessary for the Slave to use i2cflag (or interupt) or can it happily freewheel as indicated in the manual. In my case the Master is writing into a circular buffer and the Slave is reading from it (the buffer is in the Slave scratchpad) consequently there is no real need for the slave to monitor the i2cflag - or is there?​

I have code in my Master that at one point sits in a tight loop executing SERIN to @PTR for 16 bytes input.

		ptr = RFID_start ' reset scratchpad pointer
		for temp=1 to rfid_mess_length
			serin [rfid_timeout,operate], b.1, comm_speed,@ptrinc
		next temp
		'check rfid data is framed correctly
		{
			ptr=RFID_start
			if @ptr <> SOT then goto rfid_err
			ptr=rfid_mess_length
			if @ptr <> EOT then goto rfid_err
		}

4. This works reliably unless the program has enabled i2c (eg hi2csetup i2cmaster, %10100000, i2cfast_16, i2cbyte) when the SERIN becomes unreliable .. even though i2c is not being used at that point. Should I be turning i2c off when not being used?

5. In which case - what sort of times are involved in turning i2c on and off?​

Many questions. Help with any would be appreciated.

 

[nick12ab]

1. The clock speeds don't need to be the same, but the slave shouldn't run any slower than the master.
2. You should use i2cslow, but you don't need to make it much slower using the clock speed prefixes when unnecessary. Even when using i2cslow the PICAXE-20X2 slave at 8MHz requests the master to delay after any communication anyway so there would be little benefit by using i2cfast at lower speeds.
3. Use of the i2cflag is not mandatory - you only need to use it when you want to know when the master has written some data.
4. Don't know why that would happen. Why not disable i2c when using it?
5. It should be instant.

 

[Hundred1906]

Nick, thank you for your answers: Outstanding support via the forum as per usual. Despite bracketing my code with hi2c off/on instructions I have not yet tracked down the issue but now feel much more confident that I am doing the right things.

 

[inglewoodpete]

...I am using two 20x2, one master, one slave with 4.7k current drive. Both on a pin-board within 4 cm of each other.

2. From a reliability perspective what is the ideal i2c speed for the Master to use with a 20x2 Slave (Slow_ or Fast_). Assuming slow is best is I2cslow_64 the best combination

.....

4. This works reliably unless the program has enabled i2c (eg hi2csetup i2cmaster, %10100000, i2cfast_16, i2cbyte) when the SERIN becomes unreliable .. even though i2c is not being used at that point. Should I be turning i2c off when not being used?

5. In which case - what sort of times are involved in turning i2c on and off?​

Many questions. Help with any would be appreciated.

Despite assurances from Rev-Ed, I don't have a lot of confidence in the 20X2 when used as an i2c slave and with the current firmware. However, this is specifically related the i2c port lockups in the slave. I have found the 28X2 and 40X2 much more reliable as i2c slaves.

There are ways to get the 20X2 to be more reliable in the i2c slave role: remove all 'macro' or time-critical commands Eg SerTxd, SerOut, ReadTemp, ReadTemp12, Debug and possibly others. However, this is not a total fix.

I don't think there is any benefit in stopping and starting the i2c configuration.

 

[nick12ab]

Despite assurances from Rev-Ed, I don't have a lot of confidence in the 20X2 when used as an i2c slave and with the current firmware. However, this is specifically related the i2c port lockups in the slave. I have found the 28X2 and 40X2 much more reliable as i2c slaves.

There are ways to get the 20X2 to be more reliable in the i2c slave role: remove all 'macro' or time-critical commands Eg SerTxd, SerOut, ReadTemp, ReadTemp12, Debug and possibly others. However, this is not a total fix.

Full reliability seems to be achieved as long as absolutely no blocking commands or any interrupt-based commands are used at the same time. A project with an Arduino as the master would normally freeze up within a minute when a single interrupt-based function (hardware serial background receive) was used but has never frozen up in weeks of operation after bit-banging was used instead. This was with the master constantly polling the slave.

The PICAXE-28X2 and PICAXE-40X2 seem to allow you to use even blocking commands without causing a permanent lockup. When using the serout command, very brief freezes occured when the master was constantly polling the slave but it never permanently locked up the master.

 

[Hundred1906]

I have written a simple 20x2 master - 20x2 slave test program which has run without errors (about an hour continuous). But the program is over simple as it is just an incrementing value being written into one location on the slave and then being read back. As yet I have not seen any lock-ups.

I have noticed that the use of any complex instructions (like SERTXD) on the Slave cause data transfer error exactly as the manual advises, so these instructions are entirely avoided. However I am not yet certain that communication is reliable in my setup and I cannot easily use my application code to drive the interface hard so I am going to need a more sophisticated test program.

Bit-banging code would be interesting to see because my assumption was that a Picaxe would be too slow for that type of operation. I continue to be amazed at what these little devices can achieve. Would this code work on an M2 type device like a 14M2?

My code on the Master, in my first post, is somehow corrupted by that part of my application that uses i2c. What appears to happen is that the first character read by a serin (@ptr) sequence becomes a 255 and the following characters are then as expected. Ie the 255 is consistently inserted into the front of the sequence. The error is occuring in a small piece of code which I would have considered immune from i2c conflicts so it is going to take a bit more investigation to work out which part of my application code is causing this.

If possible I would prefer to stay with the smaller 20x2, rather than a 28x2 or larger. I do not have a lot of space, indeed one of the reasons for using i2c at all is to simplify pcb layout. A better option for me might be to use an IO expander but I would rather stay with the benefits of being able to move some of the real-time logic handling off to the slave.