Undefined identifier -- i2c_speed

allenhuffman · Posted: Mon Apr 17, 2023 8:08 am

The compiler is unable to link to i2c_speed() in my project.

P24FJ64GA002
PCD 5.114

This board acts as an I2C slave device from a PC host program, and then acts as an I2C master for sub-boards (a message multiplexer, basically). I was trying to add a new I2C message (internal protocol) to change the subnet bus speed for testing. Here is how we initialize the subnet:

allenhuffman · Posted: Mon Apr 17, 2023 10:46 am

On another one of our boards, using 24FJ256GA106, i2c_speed() is in use and links in fine. Both projects look like they initialize the same way:

Ttelmah · Joined: 11 Mar 2010 Posts: 19513

You don't need 'FORCE_HW', setting the port name (I2C1), automatically
forces the hardware port to be used.
Your chip has the i2c peripheral, not the MSSP. On this speed has to be
changed with i2c_init, not i2c_speed.

i2c_init(SUBNET_BUS, 100000);

etc..

allenhuffman · Posted: Wed Apr 19, 2023 8:39 pm

PrinceNai · Joined: 31 Oct 2016 Posts: 479 Location: Montenegro

Ttelmah · Joined: 11 Mar 2010 Posts: 19513

Historically, the MSSP, was the multi-function synchronous serial port.
Could be programmed to do SPI, or I2C.
Then on some of the PIC24/30/33's, Microchip separated the peripherals,
and gave an SPI peripheral, and a separate I2C peripheral. These function
somewhat differently to the MSSP. There are actually two different versions
of the I2C peripheral as well!.
Problem is that CCS 'hides' lots of things, so (for example), you have
#USE I2C, and don't have to worry which type of hardware you actually
have, but then differences do appear when you want to do things like
change speed. Hence, despite the 'hiding', you still need to be aware of
which peripheral you do actually have.
On the more sophisticated I2C peripheral, you cannot actually 'do' I2C_read
and I2C_write, having to use the automatic block transfer, since this does
not support single byte operation at all. Yours is the intermediate one that
does still allow read/write, but still has different registers for the baud rate
control. I2C_speed is not supported on this.
Key always is the .h file for each processor. On the ones with this peripheral,
you will not find I2C_speed listed. On the ones with the block only
peripheral, you won't find I2C_read or I2C_write. This file is an essential
'first call' when programming PIC's, especially when moving stuff between
different chips.

allenhuffman · Posted: Thu Apr 20, 2023 8:58 am

Great information as always! Than you.

Alas, I cannot use i2c_init() with a variable, it seems:

allenhuffman · Posted: Thu Apr 20, 2023 9:00 am

Well that ended quickly... The datasheet says:

allenhuffman · Posted: Thu Apr 20, 2023 9:16 am

Testing #use I2C with faster speeds works -- 500 shows that speed in my Saleae logic analyzer capture.

Setting to 1000000 caused the board to lock, being restarted by the watchdog timer.

(Testing at 500, 600, 700, 800 and 900 "worked" but retesting 1000Khz had that issue. I guess we stick with the slow FAST speed.)

#TheMoreYouKnow
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?

allenhuffman · Posted: Thu Apr 20, 2023 9:31 am

ChatGPT says it can do 1 MHz, and I asked where it got that information and it said the data sheet. Exploring the datasheet further:

https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/39881e.pdf

...shows Table 16-1 listing the 1 MHz speed that causes mine to flake out. But, at least there's hope ;-) We've already changed the PIC used on this board once, so if we have to swap it again I guess we can.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?

temtronic · Posted: Thu Apr 20, 2023 10:00 am

Really you actually believe what ChatGPT says??

As for speed...possible hardware issue (board clean, correct pullups,etc.), for software...possible bugs (wrong speed setting in registers , ??)

allenhuffman · Posted: Thu Apr 20, 2023 10:06 am

Ttelmah · Joined: 11 Mar 2010 Posts: 19513

On I2C, above 400KHz, you are running 'fast mode plus'. On this, _active
pull-ups are normally required_. It depends on the bus capacitance,
but unless the capacitance is very low, you are unlikely to meet the rise
time requirements, without either using current sources or a genuine
active pull-up.
Look at the LTC4311, which is a typical pull-up device for such a bus.
If the bus is short and low capacitance, you may well be able to get away
by just dropping the pull-up resistors. The key point about devices
supporting these higher speeds, is that they have higher gate output
drive currents, which allow stronger pull-ups to be used (and improve the
pull-down speed).
Also look at 'rise time accelerators', which is another term for the active
pull-ups. These have switched FET's to actually reduce the rise time, while
not drawing more current once the line is stable high or low.

allenhuffman · Posted: Fri Apr 21, 2023 11:58 am

Ttelmah · Joined: 11 Mar 2010 Posts: 19513

3 to 27, implies a huge rise in bus capacitance.
What are your pull-ups?. Assume this is a 3.3v system?.
Tc and Tr are specified as 120nSec max for a 1MHz I2C bus. This
gives a Rp(max) of Tr/(0.8473*Cb). So for a bus capacitance of 200pF,
this gives 708R. Now with 27 devices, 200pF, is going to be close to the
minimum possible capacitance. So to have any hope of working you need
to either clock slower, or drop the pull-ups to perhaps 700R.