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 CCS Technical Support

CCS i2c_slaveaddr() address is 2X from FTDI address

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
allenhuffman



Joined: 17 Jun 2019
Posts: 552
Location: Des Moines, Iowa, USA

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

CCS i2c_slaveaddr() address is 2X from FTDI address
PostPosted: Tue Oct 29, 2019 10:19 am     Reply with quote

Just curious ... I know I2C addressing has one of the bits in the 8-bit address to indicate read/write, but I have a question about how CCS uses this.

When I initialize an I2C address to 110 using i2c_slaveaddr() or in the #use I2C line, I have to use half that when talking to it via a PC and FTDI I2C interface. In my case, the PC side needs address 55 for the PIC initialized to 110 to see it. The PIC sees a 110 in the I2C address byte (01101110).

If I initialize the PIC to an odd address, like 111 (01101111), writing to address 55 responds with the PIC I2C address still reporting as 110.

I'm used to the address matching. I was wondering if someone knew why CCS did it this way. Maybe this is common, and the systems I have used just didn't do it this way. It makes some of our PIC code have address values that are larger than the 7-bit address allows.
_________________
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 ?
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Oct 29, 2019 10:23 am     Reply with quote

CCS uses 8-bit i2c address format. All their functions and #use
statements expect 8-bit format.

7-bit format is used by NXP.

To convert 7-bit format to 8-bit, simply left-shift the 7-bit format by 1.

Do not initialize a slave address to an odd number. It will not work.

Do not use decimal. Think and use hex for i2c addresses.

Do not use reserved i2c addresses for a slave.
allenhuffman



Joined: 17 Jun 2019
Posts: 552
Location: Des Moines, Iowa, USA

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

PostPosted: Tue Oct 29, 2019 10:29 am     Reply with quote

PCM programmer wrote:
CCS uses 8-bit i2c address format. All their functions and #use
statements expect 8-bit format.

7-bit format is used by NXP.


Ah, odd to me, but that explains it. The spec says it's a 7-bit format, so I was not understanding why were were using "impossible" values in the PIC code. I ran into this when I was trying to make some common header files between our PC application and the PIC code and realized they can't use the same values for our board addresses :-)

Update: Ah, I find it referenced on some sites:

Quote:
Some vendors incorrectly provide 8-bit addresses which include the read/write bit. Often times, you can determine if this is the case because they will provide one address for writing to the slave device and another to reading from the slave. In this situations. please only use the top seven bits of the address.


Well, I've seen worse. I was stunned to find that the "DMX" XLR-plug cables I'd used "forever" for stage lighting were NOT using the actual DMX specification connectors. I had never read the spec so I did not realize it was supposed to a DIN connector like my old Radio Shack computer used ;-)
_________________
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



Joined: 17 Jun 2019
Posts: 552
Location: Des Moines, Iowa, USA

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

PostPosted: Tue Oct 29, 2019 10:48 am     Reply with quote

I'm going to just make a macro in the PIC code so I can define all the addresses using the I2C 7-bit standard. Something like this, I guess:

Code:
// Convert standard I2C 7-bit address to non-standard PIC 8-bit address.
// address = 7-bit I2C address
// rw      = 0-read, 1-write
#define I2C_ADDRESS_TO_PIC(address,rw)    ((address<<1)|(rw))

Though maybe the rw bit isn't as necessary...
Code:
// Convert standard I2C 7-bit address to non-standard PIC 8-bit address.
// address = 7-bit I2C address
#define I2C_ADDRESS_TO_PIC(address)    (address<<1)

_________________
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



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

View user's profile Send private message

PostPosted: Tue Oct 29, 2019 1:20 pm     Reply with quote

XLR connectors were cheaper and EASIER to solder up, 'back then'.(yeah I did a LOT of band work 1/2 century ago, prePIC. and yes, MY TRS80 has a 5 pin DIN on the back for cassette tape.
As for the 7 bit vs 8 bit, the original spec was 7 ( a Philips(now NXP) thing). though the standard has 'slid' just like RS-232 which USED to be 25 pins...2 was xmt, 3 rec...that magically got changed and STILL cause me problems as 2 is rec, 3 is xmt and 9 pins....
sigh.....getting old and cranky...
I do like the MACRO idea though, might save losing some sleep.....
Ttelmah



Joined: 11 Mar 2010
Posts: 19499

View user's profile Send private message

PostPosted: Tue Oct 29, 2019 1:27 pm     Reply with quote

The distinction is between address and byte.

The 'address byte', has a 7bit address as the top seven bits, then the
R/W bit as the bottom bit. The PIC uses it's addresses in this format.
On the slave hardware address recognition, only the upper seven bits
are used. So only even 'addresses'. When sending the address byte, you
need the same format, but with the R/W bit included.
allenhuffman



Joined: 17 Jun 2019
Posts: 552
Location: Des Moines, Iowa, USA

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

PostPosted: Tue Nov 05, 2019 8:53 am     Reply with quote

temtronic wrote:
XLR connectors were cheaper and EASIER to solder up, 'back then'.(yeah I did a LOT of band work 1/2 century ago, prePIC. and yes, MY TRS80 has a 5 pin DIN on the back for cassette tape.
As for the 7 bit vs 8 bit, the original spec was 7 ( a Philips(now NXP) thing). though the standard has 'slid' just like RS-232 which USED to be 25 pins...2 was xmt, 3 rec...that magically got changed and STILL cause me problems as 2 is rec, 3 is xmt and 9 pins....
sigh.....getting old and cranky...
I do like the MACRO idea though, might save losing some sleep.....


"The great thing about standards . . . "

I was doing a bunch of retro TTL/RS-232 work on my old Radio Shack computer in recent years, and was stunned I could still buy DB9-DB25 adapters and TTL converters and such. Long live 232!

#StayOffMyLawn (there. old and cranky by new and hip)
_________________
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



Joined: 17 Jun 2019
Posts: 552
Location: Des Moines, Iowa, USA

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

PostPosted: Tue Nov 05, 2019 8:54 am     Reply with quote

Ttelmah wrote:
The distinction is between address and byte.

The 'address byte', has a 7bit address as the top seven bits, then the
R/W bit as the bottom bit. The PIC uses it's addresses in this format.
On the slave hardware address recognition, only the upper seven bits
are used. So only even 'addresses'. When sending the address byte, you
need the same format, but with the R/W bit included.


Does the hardware do anything with that bit?
_________________
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 ?
Ttelmah



Joined: 11 Mar 2010
Posts: 19499

View user's profile Send private message

PostPosted: Tue Nov 05, 2019 8:57 am     Reply with quote

Yes.

It is what flags the data direction for the subsequent transfer.
allenhuffman



Joined: 17 Jun 2019
Posts: 552
Location: Des Moines, Iowa, USA

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

PostPosted: Tue Nov 05, 2019 9:24 am     Reply with quote

Ttelmah wrote:
Yes.

It is what flags the data direction for the subsequent transfer.


I'll have to check our existing code. We have command messages that just write, and query messages that write then read a response. I had not noticed if our code is altering the address to set that bit. Or I guess that could be done by something in the API.
_________________
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 ?
Ttelmah



Joined: 11 Mar 2010
Posts: 19499

View user's profile Send private message

PostPosted: Tue Nov 05, 2019 9:53 am     Reply with quote

The bit is set or cleared in the master write. The slave sees this and reacts
accordingly.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
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