Help Me Continue My I2C

[22swg]

WCOL can be set with one master and a slave all to easily . if your setup is on BB  then you can get spurious spikes and stray capacitance, they are not the most secure of connects.
how about a bb jpg .  are you  doing any thing with WDT ?

[amwales]

SuzyC, the code snippet I sent you should be easily translatable and I had only a little trouble getting it to work. You should give it a try, simply take the isr code, port it to xc8 or which ever compiler you are using. If you decide to run the i2c code outside the isr make sure the code is not interrupted since I found some devices do not properly honour clock stretching ( raspberry pi ) and you have to get the i2c code processing as fast as it can.

[SuzyC]

Thanks again 22swg,

I am not using the WDT, and the waveforms always look free of noise/spikes on a 200MHz scope. Breadboarded or not, the waveforms look very good to me!

I would be surprised if it is a WCOL because there is only one master clocking everything and the Master checks the clock line in it's send routine to Slave for a high level before it starts to make any transmission.

In any case, I have used error detecting bytes in the transmission-reception, so if there is a problem detected, the data is discarded and it is a case of try again.

After all I have got very good scores now, 25000 or more successful TxRX without any TX Rx failures, even if I have settled to accept things going on at a slower clock rate than I anticipated.

[SuzyC]

The real problem nows:
How to get information Tx-RX'd without having the peeking at bytes on the Slave while the Slave might be updating the same bytes I want to be sent to me without resorting to turning off the IRQ's every time a var is being changed rapidly during some task on the Slave. If I turn off the IRQ's before any change in byte value I will have my code overflowing with the turn on/turn off of IRQ's. Probably enough of them to run out of memory and seriously upset the clock/timers on the Slave.

On the other hand, I can save all the vars I am interested in in a cache array and have a flag byte tell me that the cache has been updated or is being updated.
 
(1) I send a request to Slave to Update Buffer Cache Array(has all the values)
     A update flag var is set on Slave in the IRQ,  RTS=Request To Send.
(2) The list of vars is updated when RTS detected in passing along the main() loop.
(3) A routine updates all the Vars and sets flag RTS=Ready To Send.
(4) I sent a request to Slave for the RTS byte.
(5) If the RTS is Ready to Send I send a SendBytes Command to Slave and grab the bytes in the Buffer, one IRQ for each byte number, or maybe get two or more bytes at a time being careful to not be running out of ISR time.
 
This results in data slightly stale, might take a few mSecs, but that's fast enough for me.

Am I good to go with this? 

(3) I send Slave a command byte requesting the cache status RTS flag byte.

[senso]

There are lots of 5v 16bits pics, for example dspic3011, 40 pins, 10 pwm, 5 16 bits timers 2 32 bits timers, all in a dip package, come on, use the search/pic selector and find a better one..

[bobcat]

On long I2C lines > 2"", termination is important. I have good luck using 4.7K pull up resistors to Vcc. Also add a 470 ohm resistor in series with both of the clock and data lines. Place the series resistors close to the MPU. Even "clean" looking signals on a scope can be bad.

[SuzyC]

Thanks Senso, I didn't realize there were DIP packaged dspic.  I have taken a look at these chips, they might be the ticket..

[SuzyC]

Thanks again 22swg, for your valuable advice to pay attention to WCOL issues

I thought I was getting  good transfers from master<--->slave, but it was an illusion. Once I added to the slave WCOL=0 SSPOV=0 before the start of the slave i2c ISR code, the transfer from master to slave seemed without error, that is, master-->slave worked fine half of the time; but transfers failed right after the SEN command every other time it was attempted by the master. It seems that the master, after sending a command, and terminating the transmission with PEN=1, would trigger a failed start of the next transfer, at the very start of the very next transmission. Then, once the code was repeated again, it worked ok.

Once I added WCOL=0;' SSPOV=0; at the very beginning of my sub-routine code that sends a command to the slave right before the SEN=1  then my master<--->slave code worked perfect!

[SuzyC]

Thanks to Bobcat!

I still do not understand why the i2c baud rate is still limited to approx to a  period of 6uS minimum in order to get error free transfers. The freq. of the i2c clock is less than 200KHz, but I can't seem to get it to run any faster even if I am just master--> slave only operation. I have tried again higher values of pull-up resistors(5k) but it only works worse.

The 16F88x spec sheet alludes to 1MHz baud but only shows specs for 400KHz and 100KHz operation. I can't do better than <200 KHz. I have yet to try 470ohm resistors in series with the ic2 Tx Rx pins.

However, I can still send a 5-byte command sequence to the Slave and get back 26 data bytes from a Slave's sensors all within 3mSec per MMMMM.

And that's good enough for me at this time to get this robot dancing!

Maybe it's my code.

[SuzyC]

Sorry to have taken sooooh long to reply to some of the people who generously took time out of their busy day to share their advice and deas with me!

Thanks a million to all you guys!

What really made my code make a turn to working was changing my code to use the i2c status register to create a state machine. It really made the difference in getting my code' to work when I knew how to respond codewise when a Start Sequence or R/*W or Data/Address was the last event in i2c land. Before that I was just looking at SSPIF and not paying any attention to these these important flags that tell the state of things i2c-wise. On top of that I was also ignoring WCOL and SSPOV's that were shouting at me!

I have been so thrilled to get my four MMMMM's to control each motor to go fast and slow, forward and reverse that I started to play with my prototype's construction and control code and sensor code and it took me just to recently to look back to the basics of having a perfectly reliable i2c and I have to say, I am so glad to see it work as well at is does!

What does it matter so much at this point if sometimes each MMMMM is a little bit of a jerk?

[SuzyC]

Oh Dear!

Amwales, you too gave me a clue about WCOL that helped me to solve the i2c problems.

My thanks!

[amwales]

Glad you got it working, what speed did you finally manage to achieve?

[SuzyC]

Amwales, Thanks Again for y our help:

As I have said a little earlier on this post page, the latest news is I canl send a 5-byte command sequence to the Slave and get back 34 data bytes from a Slave's sensors all within almost exactly 3mSec per MMMMM, though the time bounces around a bit by winning or losing the ISR time lottery.

So the clock period is very close to 6uSec, a speed <200KHz, and any speed faster than that gives me errors break dancing all over my i2d score card and I donno why!

[SuzyC]

Whaz is a real problem is PWM using a single powerful MCU. Some posters suggest I should stick with just one big MCU chip.

But when  I use a single chip each to control each of the four motors, then each or all four PWM's ON period starts at the same time, so the battery faces a huge surge load. This is why I think my MMMMM approach is going to work better, because each PWM is driving their motor asynchronously with their MMMMM peers, PWM-wise. 

The other issue is with an 8-bit MCU, such as the ATMEGA 2560 or the presently being used 16F886's,is that I cannot get my
code to do more than a few floating point calculations before i have used up all the program memory and the available MIPS.

Maybe I need to start a new post:  Which processor is the easiest to graduate to from an 8-bit to start doing some highly educated management of my MMMMM's?

[dannyf]

I think you made your life unnecessarily difficult.

Even though a slave is difficult to code, it is not impossible to code, even for a newbie. SPI slaves for example are quite simple. So is an uart receiver.

If I were you, I would have done either a spi slave (which needs two lines for the bus, and 4 lines for chip select);

or better yet, a uart receiver - 1 line for each chip, or with some additional coding, 1 line for all chips (as many as you want) if you allow a protocol there. Such a system has the added advantage of being very scalable.

[nctnico]

From a functional point of view I2C is the easiest to make a master/slave system because the hardware also does the address decoding. With SPI, UART, etc you'll always have to do the addressing in software.

[SuzyC]

Thanks again nctnico,

I have been busy on my new post and just now had a few mins to take a look at this one.

I have not tried using the UART because I found the baud rate setting tables a little more than confusing and the problem of addressing four separate seemed rather difficult in terms of software and at the same time some other slave was having a conversation, every other slave would have an interrupt and somehow resolve if it was the target of the master's attention.
On the other hand, the problem of using the UART becomes simpler if some pins are allocated to chip select/direction control, but I have just about run out of pins on the master,due to a LCD display, a momentary switch, 6 A2D's and a rotary encoder, and one of two bits for hardware flags/debug purposes,  though I have quite a few of the 28-pins left over on the slaves.