Help Me Continue My I2C

[SuzyC]

Thanks again DannyF,

I certainly agree that engineering should be more than a binary search to precise a working circuit.

I am without a guess what the exact problem is, but that lowering the i2c baud rate does solve the problem. If seems inconsistent with the i2c specs in the 16F88x spec sheet which on one hand says max i2c clock can be 100K, 400k or 1MHz and I could not get my i2c code to start to work reliably unless I dropped the clock down to about 6uSec per cycle.

Do you have an answer to this enigma? Ever since I left my Indian Spirit Guide in California I have at present no one to ask.

My guess is that at the 1.6uS clock I was not meeting the requirements for data setup/hold time relative to clock or else the Tmin setup time between a SEN command and the SPPBUF=Byte stuffing into the chip. Yet this proves itself wrong at the send side, because I can clearly see the byte transmitted correctly by the Master on the scope.

So the problem must be on the Slave side of this game.

[SuzyC]

22swg, thanks for the help,

It is just the opposite, it is always faster to switch higher drive currents.  Remember T=RC and so the pullup resistor must be slowed by charging/discharging a larger input/output circuit capacitance, so the larger the current the faster the charge/discharge of any switching circuit. With open-drain outputs, the pull-up resistor only affects the risetime. The falltime is completely determined by the open-drain turn-on time of the MOSFET inside the chip.

[mikerj]

Have you actually checked your I2C timing on a scope?  It's possible you have more bus capacitance than you think which could be throwing the timing out.

[SuzyC]

Thanks MikerJ,

I have a 200MHz 4-chanese digital scope and it clearly shows a clean clock and data pulses, fast rise and fall times in the <10 nSec range with very little noticeable ground bounce or significant overshoot.  After all, I am using 1K pullups and only 5-in of wire between the two MCU's.  With the 1.6uSec hi and lo period nfg clocking, I would expect problems if I were driving 2-meter lengths interconnects, but not for 5-in open wires.

The problem cannot be rise or fall times, because these do not change with clock speed.

I do not see on the scope at 1.6uSec clock rate any overlap of clock and data, and see fast rise and fall times. Since my scope has fast update rate I should see "ghosts" of any reflections of the pulses, but I don't..looks really nice.

The data setup time and time between a Start Bit condition and the first loading of a byte into the master Xmit Buffer is a spec i must try to check out in the spec sheet.  Problem is, the specs get worse(setup and hold times are proportionally longer) with slower clock speeds(100k) and there are no specs for 1MHz clock rates.

[22swg]

I only mentioned the PIC24FV  as its what I currently "get on with"  as you expect to run out of memory then perhaps I could sell you    16F1788  oooh.. 

Edit , try a 2k2....

[SuzyC]

22swg

From the 16F1788/9 Microchip SpecSheet:  16KW..now that is power!

Up to 16 KW Flash Program Memory:
- Self-programmable under software control
- Programmable code protection
- Programmable write protection
• 256 Bytes of Data EEPROM
• Up to 2048 Bytes of RAM

Edit 2k2  =2.2K  whatcha  do with dat?

Again 16F1788/9  are one PWM short of a full deck and the 16F1788/9 is not supported by Hi-Tech C compiler Pic 10/12/16 pro ver 9.83

If I have to upgrade my compiler I might as well lift my leg towards the PIC family and give an ARM a chance to shake a stick at.

[SuzyC]

Tried lowering the clk, data pull up resistors to 500-ohm and also tried raising the values to 2k, both with worse results, x10 increases in random errors.

I was in error in reporting the rise/fall times, it is more like 100-120nSec 10%-90% of P-P. at the present clock speed of around 5uSec per cycle. What is remarkable is that the fall of the clock is around 200nS away from the fall/rise of the data, but also it is that  the 0--->1 of the clock is always squarely in the middle of the data pulse.

[SuzyC]

Thanks again, nctnico

The idea of single MCU works only if there are enough PWM's on the chip. I need 4, most PICs have three.

I kinda wrap my head around using distributed processing power v. 1 powerful MCU to replace multiple MCU's for my robot.

I would rather have one idiot manage 4 morons than one moron managing four motors.

The communication to the individual satellite MCU's is mostly to boss them around, not needing them to communicate with each other, but only to Mr. Big who mostly gives them orders.

[nctnico]

How about using dedicated, I2C controlled PWM chips?

[dannyf]

You may want to try PIC24 chips - many of them have tons of pwm, with dedicated timers.

Development tools: C30/XC16, Maplab / Maplab X or emblocks (my favorite).

[SuzyC]

Thanks nctnico for the suggestion,

My main idea here to get this robot off the ground is to keep the circuits small in size and cost and use off the shelf parts to create small modules.  Using i2c PWM controllers does not provide the support for other optical and other sensor functions needed at each motor's location, nor does it allow me to get exact feedback of the power and rotational speed  that I might want  to get to determine the PWM required by each motor.

Now if I have 4 motors and then I must have four conversations with 4 i2c dedicated PWM controllers and then also near each motor I have multiple sensors that also must be giving me feedback, quite a busy job, quite a few wires running in all directions out/in, quite a lot of ground loop problems as well, is it such a good idea, a single MCU?  With distributed MCU's I only need to daisychain the i2c wires to control my robot and the Mr Big processor in the middle has time to think, being relieved of all the dirty work of accessing each of the sensors while also trying to calculate PWM management, speed and each motor's torque load at the same time. I simply ask the individual MCU's how they are managing the tasks assigned to them and what's the latest gossip about the situation they are in.

[SuzyC]

Thanks DannyF,

I was just looking at 22swg's suggestion to use 24FV chips. They are 5V compatible devices but again have only 3 PWM's.

I also looked at the 32MHz PIC16F1889 which also fails at 3 PWM's.

What's left is 3.6V ARM and PIC devices and that is an interfacing problem 3.6 logic levels and also having to deal with high current brush motors giving off EMI by the bucket full.

Consider this:  One 16F886 chip has 4-5MIPS?  One 24FV PIC has 16Mips.  4 x Motors x 4 updates/calcs x multiple sensors: all by one MCU. Thinks me I might require 20MIPS?

[dannyf]

Since you are using the hardware pwm modules, the mcu is fully freed up -> 0mips needed.

[22swg]

16F1509 supported hitec ? 32Mhz  4 pwm  only 8k and short on I/O...   

[dannyf]

not supported by Hi-Tech C compiler Pic 10/12/16 pro ver 9.83

I was a big fan of PICC, until they turned OCG. I still have 9.60/9.63 std/pro compilers somewhere.

The new XC8 compilers are very good replacement of the PICC. They (1.12 is the one I tested) generated fast / small code even in free mode (better than the PICC std compilers).

The differences between XC8 and PICC/PICC18 are minor, mostly in fuse settings. So migration is easy.

I would suggest that you migrate to XC8 instead.

[SuzyC]

Thanks again, 22swg!

But this 16F1609 chip would be something to look at if it only had more I/O pins, only 20!
I need more I/O pins to use a one-chip solution.
Yes, it is supported by Hi-tech compiler.
With few pins, this means not having pins for i/o control, debugging and communication, so program development is very difficult and so much of the capability of the chip cannot be used because you must borrow from i/o Peter to pay peripheral Paul.

I would like my robot to be able, not handicapped by not having sufficient i/o. I have got now Master--->Slave i2c to work, so I have the ability for one Mr. Big chip to do something with many sensors, have some power of calculation as well as control my obedient Multiple Moron Motor Manager Modules (MMMMM)

Maybe that is where that Arduino ATMEGA2560 may come in handy if I can scale it down in size.

[SuzyC]

Thanks DannyF,

I downloaded the XC8 free version and installed it and was very disappointed. A large (95% of program memory used when compiled sucessfully with Hi-Tech Pro) C-source program that I had would not compile, giving me multiple "Cannot find xxxx bytes in p-sect errors".  XC8 free edition is  just crap, just like the free version of Hi-Tech Lite, gives the same low performance results because of no optimiziation. To get my source program to work I had to delete about 25% of my source code to get my source code to compile without running out of program memory, leaving me with a bloated, broken, does almost nothing result.

[dannyf]

If you care about code sizes, you should try pre-OCG compilers - 9.60 is my favorite. They however have limited support for newer chips.

[SuzyC]

Thanks DannyF.

Not limited support, no support for new chips.

That's what I am using now, Hi-Tech Pro 9.83 for PIC10/12/16, but I am wanting to use newer chips, graduate to a more powerful chip to control my robot.

So, at this point at ATMEL IDE installed and I just downloaded Kiel free edition(<32K compiled code) for ARM NX. What next? Eclipse?

[dannyf]

No. More coding. The issue you have is far less of an issue of the mcu, but coding.

[amwales]

I had to code up an i2c slave recently.
You may find the following links useful ( this is NOT my code ) but it helped me understand it alot.

http://www.guiott.com/Lino/Display/DisplayI2C.htm

Take a look at the i2c ISR here

http://code.google.com/p/lls-disp/source/browse/trunk/LlsDisplay/LlsDisplay.c

[dannyf]

Take a look at the i2c ISR here

It utilized a state machine there. Slaves without interrupt + state machine are very difficult to do.

[amwales]

Are you checking and clearing the WCOL bit?

from the pic18f26k22 datasheet ( same applies for the pic16f87xa )

Any write to the SSPxBUF register during transmission/reception of data will be ignored and the write collision detect bit, WCOL of the SSPxCON1 register, will be set. User software must clear the WCOL bit to allow the following write(s) to the SSPxBUF register to complete
successfully.

[SuzyC]

Thanks Amwales,

I see the sample code links are working with i2c firmware is displays and that is different from i2c with another MCU.
The WCOL bit is not likely to be a problem since at this point I have only one Master, so only one player is calling all the shots.

Maybe it is a Microchip  Silicon Error:  I see runt pulse widths (approx .5uS or less) of high i2c clock pulses occasionally captured on my digital scope, but having correct amplitude and offset position in the 9-bit parade, though inside the bounds of the data pulse.

Microchip reports this problem with SPI operation in their 2012 silicon errata for 16F886/7.

[SuzyC]

Thanks, DannyF

I am coding away.

I also notice that the ATMEGA2560 has no I2C exactly, just what they call "2-Wire", said by some to work the same way, but the way i2c operational states are named and handled and 2-wire initialization requires different coding.

The newest 6.2 version of ATMEL IDE does not offer support except for compiling/programming, no software debugging or simulation/emulation in software for the 2560, so without an expensive peripheral device, some kinda "ICE" costing many hundreds $$$$, I am kinda handicapped to get code to work.

So I gotta just study my code,  for to be buying that board, that's a lotsa clams.