i2c_transfer for LTC2635

nickbd · Joined: 12 Jun 2013 Posts: 7

I am using the LTC2635 4Ch DAC (10bit version). I have this working properly with MikroC but with CCS 5.081 it works with the internal 8MHz clock but not using the 10MHz external crystal I'm using. Appreciate any advice on this. Here is the program

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

temtronic · Posted: Mon Jan 14, 2019 6:10 am

some thoughts...

can you confirm that PCM P's I2C scanner program does properly locate the
chip at address 0x22 ?

is the PIC running at 10Mhz? (correct caps for xtal)

correct I2C pullups for speed,VDD, and layout ?

what happens when you use the 'old' method of sending I2C data ?

Jay

Ttelmah · Joined: 11 Mar 2010 Posts: 19538

He can't.

On this chip, the 'old' method is not being supported. I must admit I think it should be for reverse compatibility... Sad

Also because the new code has problems.

I think PCM_Programmers suggestion of switching to software I2C is
probably the way to go, since this then allows the standard functions to
be used.

temtronic · Posted: Mon Jan 14, 2019 6:55 am

Hay Mr. T.

You mean something like this...

i2c_start();
i2c_write(0X22);
i2c_write(0X00);
i2c_write(0X84);
i2c_write(0x80);
i2c_stop();

ISN'T allowed ??

What about bitbanged I2C ?

just curious..
also not sure what PIC he's using.. though I have had a cold for 3 or 4 weeks now...

Jay

Ttelmah · Joined: 11 Mar 2010 Posts: 19538

Yes. This has been covered here in the last couple of weeks.

He is (I assume from the filename given), using a K42 PIC.
Have a look at this thread:

<http://www.ccsinfo.com/forum/viewtopic.php?t=57675>

These are different from just about any other PIC, in not having the
MSSP peripheral. Instead they have a separate I2C peripheral.
The default setup being used by CCS with these configures them for
the 'auto transmit' mode, where they will automatically generate a
'start' when data is loaded for transmission, and assumes you will
use the I2C_transfer command to handle a transfer.

Fortunately, if he switches to using software I2C, the standard
functions should then work.
Honestly this is where I'd start.

The I2C_transfer command should be able to handle odd byte numbers,
if it doesn't then it is fundamentally flawed.
Why though code that works at one clock speed doesn't at another,
is another issue. I'd honestly suspect oscillator fuse settings are
likely to be the problem. PCM_Programmer has asked for the example
program for 10MHz, and this is really vital.

temtronic · Posted: Mon Jan 14, 2019 7:46 am

yuck... must be a 'cost saving' idea to not have a 'tried and true' MSSP ??
anyways... it'd be interesting to see the mikeROE C code to see what the difference is as it worked . More importantly would be the listing to see the assembler.

kinda makes me happy I'm 'stuck' with the 18F46K22 and don't have to deal with new PICs and their quirks !

Ttelmah · Joined: 11 Mar 2010 Posts: 19538

The new peripheral, has multi byte buffering, so potentially can do a lot
more 'for you', and give less latency between bytes. However comes at the
cost of having to setup the whole transfer 'in advance'.

nickbd · Joined: 12 Jun 2013 Posts: 7

Thanks for all the info. Just to clarify. I have a 20MHz xtal (not 10MHz-typo). Using the PIC18F46K42 uproc. This is 5V uproc. Also LTC2635 is running at 5V. I have my own board design so software using MikroC version and CCS is running on same hardware. Also have used a 24LC16 EEPROM on the same PC board and I2C bus (different address of course) and that works with CCS and MikroC code but the 2416.c driver does not use the i2c_transfer-also using 20MHz xtal. Also hardware is set up with pull ups etc. I tried using force_sw with both the internal 8MHz and 20MHz xtal and get nothing. Using the bit bashing there is no output on the I2C bus with HW or SW. Just for reference this is the line from the MikroC code for multibyte transfer to the DAC

dluu13 · Joined: 28 Sep 2018 Posts: 395 Location: Toronto, ON

hmm, I'm been using the PIC24FJ128GA204 dev board which has the dedicated i2c peripheral. I did not FORCE_SW but I am able to use the i2c_write functions as I did with the MSSP.

Ttelmah · Joined: 11 Mar 2010 Posts: 19538

The peripheral in the DsPIC 24, 30 etc., is not the same as the one in
this PIC, but does have very similar buffering, and on these CCS do emulate
the old behaviour. It really needs to be pointed out to them that this option
should be provided, especially for reverse compatibility, and particularly
since the I2C_transfer code seems to have some major issues (particularly
not supporting odd byte counts....).

nickbd · Joined: 12 Jun 2013 Posts: 7

Interesting about possible problems for odd byte counts since I have to use the wCount of 4 instead of 3 to transfer the 3 bytes. If it is set to 3 which is the correct value only 2 bytes are sent.

temtronic · Posted: Mon Jan 14, 2019 2:40 pm

OK silly idea but...since I don't have i2c_transfer_out()... to test..
perhaps the # of bytes has to include the address where they're going ?
If I read it right 4 DOES send all 3 'data' bytes ?

Jay

nickbd · Joined: 12 Jun 2013 Posts: 7

In the description of i2c_transfer_out it says
wData - Pointer to data to transfer to device.
wCount - Number of bytes to transfer to device.
Also in the CCS example ex_i2c_master_hw_k42.c where you are sending one byte of data and the one byte address (the example is for small EEPROMs withouth paging) they have

Ttelmah · Joined: 11 Mar 2010 Posts: 19538

and the example shows a one byte transfer.

I'll have to disassemble the code.