View previous topic :: View next topic |
Author |
Message |
ELCouz
Joined: 18 Jul 2007 Posts: 427 Location: Montreal,Quebec
|
Default I2C Speed? |
Posted: Thu Jan 01, 2015 2:58 pm |
|
|
Code: | #use I2C(master,sda=PIN_B0, scl=PIN_B1) |
What is the default speed (clock rate)?
Can't find the default fallback speed value when not specified in the USE statement.
Thanks! _________________ Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
dyeatman
Joined: 06 Sep 2003 Posts: 1934 Location: Norman, OK
|
|
Posted: Thu Jan 01, 2015 4:00 pm |
|
|
slow (100khz) is the default rate when not specified. _________________ Google and Forum Search are some of your best tools!!!! |
|
|
ELCouz
Joined: 18 Jul 2007 Posts: 427 Location: Montreal,Quebec
|
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Jan 01, 2015 4:07 pm |
|
|
For software i2c with vs. 5.034, I get the following measurements of the
SCL frequency on my scope:
Code: |
PIC Osc freq SCL freq
1 MHz 16 KHz
4 MHz 63 KHz
8 MHz 92 KHz
16 MHz 95 KHz
32 MHz 98 KHz
|
So the conclusion is you have to be running the PIC at about 20 MHz
or higher, to get close to the nominal 100 KHz i2c speed. |
|
|
ELCouz
Joined: 18 Jul 2007 Posts: 427 Location: Montreal,Quebec
|
|
Posted: Thu Jan 01, 2015 4:10 pm |
|
|
By judging from the data you have, PCM Programmer... fast mode and fast mode plus are hard to achieve in software i2c.
High speed mode (3.4mhz) is out of question in software. _________________ Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Jan 01, 2015 4:20 pm |
|
|
Attempting i2c Fast mode with the 32 MHz internal oscillator and 4.7 K
pullups, I get 370 KHz for the SCL frequency. The pullups on my board
are what is slowing it down. If I had stiffer pullups, it would be close to
400 KHz.
Code: |
#include <18F4520.h>
#fuses INTRC_IO, NOWDT, BROWNOUT, PUT
#use delay(internal=32M)
#use I2C(master,sda=PIN_C4, scl=PIN_C3, FAST, FORCE_SW) |
|
|
|
ELCouz
Joined: 18 Jul 2007 Posts: 427 Location: Montreal,Quebec
|
|
Posted: Thu Jan 01, 2015 4:37 pm |
|
|
PCM programmer wrote: | Attempting i2c Fast mode with the 32 MHz internal oscillator and 4.7 K
pullups, I get 370 KHz for the SCL frequency. The pullups on my board
are what is slowing it down. If I had stiffer pullups, it would be close to
400 KHz.
Code: |
#include <18F4520.h>
#fuses INTRC_IO, NOWDT, BROWNOUT, PUT
#use delay(internal=32M)
#use I2C(master,sda=PIN_C4, scl=PIN_C3, FAST, FORCE_SW) |
|
I wonder what are the clock tolerance for I2C device (average)...
I know UART 3% deviation is still acceptable... _________________ Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Jan 01, 2015 4:44 pm |
|
|
Clock tolerance doesn't matter with i2c because i2c has a clock (SCL). |
|
|
ELCouz
Joined: 18 Jul 2007 Posts: 427 Location: Montreal,Quebec
|
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19552
|
|
Posted: Fri Jan 02, 2015 1:29 am |
|
|
Yes, the key difference between synchronous, and asynchronous comms.
Worth understanding that the soft I2C, will always 'err slow'. If you have particular CPU clock, and with the instruction counts involved, one extra delay cycle in each half of the loop gives 98kHz, while the next possible speed 'up' is 100.1kHz, the software will choose the slower speed. It'll never go 'over' the specified speed. The steps get smaller as the CPU speed goes up, so it's just about getting as close as it can to 100kHz at 8MHz, and can't get near below this. This tallies with PCM_programmers finding of it doing 370kHz at 40MHz, for the 'fast' mode. It's using a minimum time of 22 instructions for each bit (remember it has to keep the half cycles matching, so 11 per half cycle - determined by the shift, test, output). So would need 8.8MHz as the minimum to actually get to 100KHz, and 35.2MHz to get to 400KHz. |
|
|
ELCouz
Joined: 18 Jul 2007 Posts: 427 Location: Montreal,Quebec
|
|
Posted: Fri Jan 02, 2015 7:27 am |
|
|
Ttelmah wrote: | Yes, the key difference between synchronous, and asynchronous comms.
Worth understanding that the soft I2C, will always 'err slow'. If you have particular CPU clock, and with the instruction counts involved, one extra delay cycle in each half of the loop gives 98kHz, while the next possible speed 'up' is 100.1kHz, the software will choose the slower speed. It'll never go 'over' the specified speed. The steps get smaller as the CPU speed goes up, so it's just about getting as close as it can to 100kHz at 8MHz, and can't get near below this. This tallies with PCM_programmers finding of it doing 370kHz at 40MHz, for the 'fast' mode. It's using a minimum time of 22 instructions for each bit (remember it has to keep the half cycles matching, so 11 per half cycle - determined by the shift, test, output). So would need 8.8MHz as the minimum to actually get to 100KHz, and 35.2MHz to get to 400KHz. |
Thanks for the explanations guys!
What about fast mode plus (In hardware/ Software I2C) ?
I know it's relatively new standard c.2007 _________________ Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19552
|
|
Posted: Fri Jan 02, 2015 11:53 am |
|
|
The hardware I2C, will happily go way beyond 400KHz. Just use FAST=xxxxxx to specify the speed you want. The PIC hardware drivers meet he FM+ current and slew rate requirements. Tends to work more reliably if you switch to using active pull-ups. |
|
|
ELCouz
Joined: 18 Jul 2007 Posts: 427 Location: Montreal,Quebec
|
|
Posted: Fri Jan 02, 2015 1:40 pm |
|
|
Ttelmah wrote: | The hardware I2C, will happily go way beyond 400KHz. Just use FAST=xxxxxx to specify the speed you want. The PIC hardware drivers meet he FM+ current and slew rate requirements. Tends to work more reliably if you switch to using active pull-ups. |
Thank you Ttelmah!
Have a nice day guys _________________ Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19552
|
|
Posted: Sat Jan 03, 2015 2:44 am |
|
|
As one further comment, the PIC can generate FS+, but cannot generate HS.
On the 'HS' standard, the actual bus waveforms are changed to a 2:1 mark/space ratio, and this the standard PIC hardware can't do. Active 'transition' drive high is also required.
I haven't checked if any of the latest PIC's have added support for this (quite possible, though I haven't seen it).
It is worth noting though that HS masters are required to start the transaction as an FS+ transaction, and only change up to HS once the slave acknowledges it can do this, so devices that offer this mode can still talk to the PIC and the PIC can still talk to devices that offer this. |
|
|
ELCouz
Joined: 18 Jul 2007 Posts: 427 Location: Montreal,Quebec
|
|
Posted: Sat Jan 03, 2015 5:42 am |
|
|
Ttelmah wrote: | As one further comment, the PIC can generate FS+, but cannot generate HS.
On the 'HS' standard, the actual bus waveforms are changed to a 2:1 mark/space ratio, and this the standard PIC hardware can't do. Active 'transition' drive high is also required.
I haven't checked if any of the latest PIC's have added support for this (quite possible, though I haven't seen it).
It is worth noting though that HS masters are required to start the transaction as an FS+ transaction, and only change up to HS once the slave acknowledges it can do this, so devices that offer this mode can still talk to the PIC and the PIC can still talk to devices that offer this. |
Luckily, only a handful of I2C devices are supporting High Speed (3.4 mHz). Not very common unless using specialized stuff. _________________ Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
|