CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

i2c_transfer for LTC2635
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
nickbd



Joined: 12 Jun 2013
Posts: 7

View user's profile Send private message

i2c_transfer for LTC2635
PostPosted: Sun Jan 13, 2019 10:39 pm     Reply with quote

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
Code:

#include <TestI2C_K42.h>
#use delay(internal=8MHz)
#pin_select SDA1=PIN_C4
#pin_select SCL1=PIN_C3
#use i2c(Master,slow=100000, I2C1)
//======================================
void main()
{
int8 my_data[3];
//10 bit DAC
   my_data[0] =0x00; //Write to DAC0
   my_data[1] =0x84; //Hi byte
   my_data[2] =0x80; //Lo byte
   while(TRUE)
   {
   i2c_transfer_out(0x22, my_data, 4);
   delay_us(100);
   }
}


I am using a logic analyzer so can see the correct data and also the ACK from the DAC. Don't understand why I need 4 for the number of bytes since only 3. If I change to 3 then only sends out 2 bytes because no ACK after the second one. If I use
Code:
#use delay(crystal=20000000)
then data is sent but the third byte is not sent correctly. I've fiddled with the speed value but that doesn't fix things.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Jan 14, 2019 12:48 am     Reply with quote

nickbd wrote:
#include <TestI2C_K42.h>
#use delay(internal=8MHz)

1. That's the program for the 8 MHz internal oscillator. Post your other
program for the 10 MHz external crystal.

2. Post the full part number of your PIC.

3. If it doesn't work with the hardware i2c, then try it with software i2c.
This will use the i2c_start(), i2c_write(), etc., functions.

4. What Vdd voltage are you using for the PIC, and for the LTC2635 ?

5. What package of the LTC2635 are you using ? QFN or MSOP ?

6. What connections do you have to the CA0, CA1, and CA2 pins.
(CA1 and CA2 are only available on the MSOP package).

7. Are you using a manufactured development board or breakout board
for the LTC2635 ? If so, post a link to the website for the board.
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Jan 14, 2019 6:10 am     Reply with quote

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: 19195

View user's profile Send private message

PostPosted: Mon Jan 14, 2019 6:40 am     Reply with quote

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.


Last edited by Ttelmah on Mon Jan 14, 2019 7:08 am; edited 1 time in total
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Jan 14, 2019 6:55 am     Reply with quote

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: 19195

View user's profile Send private message

PostPosted: Mon Jan 14, 2019 7:25 am     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Jan 14, 2019 7:46 am     Reply with quote

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: 19195

View user's profile Send private message

PostPosted: Mon Jan 14, 2019 8:45 am     Reply with quote

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

View user's profile Send private message

i2c_transfer for LTC2635
PostPosted: Mon Jan 14, 2019 10:53 am     Reply with quote

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
Code:
 I2C_Write(Saddress, pWdata, 3, _I2C_END_MODE_STOP);
dluu13



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

View user's profile Send private message Visit poster's website

no mssp
PostPosted: Mon Jan 14, 2019 11:01 am     Reply with quote

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: 19195

View user's profile Send private message

PostPosted: Mon Jan 14, 2019 11:36 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Jan 14, 2019 2:06 pm     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Jan 14, 2019 2:40 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Jan 14, 2019 2:54 pm     Reply with quote

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
Code:
         i2c_transfer(I2C_SLAVE_ADDRESS, wData, 2);
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Jan 14, 2019 2:59 pm     Reply with quote

and the example shows a one byte transfer.

I'll have to disassemble the code.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group