View previous topic :: View next topic |
Author |
Message |
barikjk
Joined: 08 Dec 2012 Posts: 5
|
software ver hardware I2C |
Posted: Fri Apr 05, 2013 3:58 am |
|
|
Hello friends
I have implemented hardware I2C in pic18F4550. sometimes the processor is stuck. I want to know if software based i2C implementation will be better?
thanks all |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9226 Location: Greensville,Ontario
|
|
Posted: Fri Apr 05, 2013 5:33 am |
|
|
Without knowing the I2C device or seeing your code I can only offer these comments.
1) Generally speaking, hardware I2C should be better, providing it conforms to the I2C specs laid out decades ago.
2)You can quickly test HW vs SW I2C ! CCS C compiler will generate software I2C for any pins that do not connect to the internal I2C HW.
This use I2C(...option...) allows you to have multiple I2C busses on a PIC.
3)'sometimes the processor gets stuck' sounds more like a logic(code) problem than an internal hardware I2C problem, though bad wiring or even static might be the trouble.
For more help, please post a small,compilable program that fails, your compiler version, and the I2C device being used.The more information you supply the quicker the replies from more people.
hth
jay |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19515
|
|
Posted: Fri Apr 05, 2013 7:16 am |
|
|
Is this a slave or a master?.
Slave can _only_ be done in hardware.
If this is a slave, the 4550, has some quite nasty errata on the port, which could cause problems.
There is also one that is 'board dependant' regarding initialisation as a master. Have had half a dozen designs without this problem then had a board that would do it just about every time. Had to switch to manually initialising the chip rather than using #use i2c, and setting the tris before doing this, to ensure the chip initialised correctly....
Best Wishes |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Apr 05, 2013 10:49 am |
|
|
Quote: | 1) Generally speaking, hardware I2C should be better, providing it
conforms to the I2C specs laid out decades ago.
|
I disagree with this one, because the general case is that for PICs,
the MSSP module will have one or more erratas on it. And not just
for slave mode, but for Master mode as well.
The software i2c master code implemented in the CCS #use i2c() code
consists of toggling i/o ports pins between "output low" and floating.
It's lot more easy to make that reliable, and it is more reliable.
If you have problems with a hardware i2c master (ie., using FORCE_HW
with #use i2c), then try the software master library code. (Remove
the FORCE_HW). |
|
|
rnielsen
Joined: 23 Sep 2003 Posts: 852 Location: Utah
|
|
Posted: Fri Apr 05, 2013 12:36 pm |
|
|
I've had I2C buses get 'stuck' before and after examining it with an oscilloscope I found that I've had noise on the bus or my timing was so marginal that every once in a great while a device would miss a pulse and it would send it into neverland.
I suggest you get a scope and examine your signals. Slave PICs need hardware mode. Masters can run in hardware or software mode. I've had to bit-bang my bus before because my bus lines were too long. A scope really helps to see how the bus is performing.
Ronald |
|
|
|