| View previous topic :: View next topic |
| Author |
Message |
Csaba
Joined: 05 May 2012
Posts: 25
|
 Posted: Sun Jun 24, 2012 12:23 pm Post subject: i2c address clarification |
 |
|
Dear Colleagues,
I just like to get a clarification regarding i2c address usage in i2creceive/i2csend with BASCOM.
i2c addresses defined as 7-bit values in the range &h00 - &h7F. This address appears for example in a catalog description of a part with i2c bus access.
The actual I2C-BUS-ADDRESS-BYTE sent on the i2c bus is obtained by shifting the i2c address left 1 position, and copying a read/write bit to the smallest bit position.
BASCOM uses this this shifted form I2C-BUS-ADDRESS-BYTE in i2creceive/i2csend. (I don't know the case with $lib "I2C_TWI.LBX", so with hardware TWI usage.)
Am I right?
Most probably this is stated in the books/forum letters a million times, but I've missed to find it.
First it caused some problems for me when tried to attach i2c devices.
Thanks,
Csaba |
|
| Back to top |
|
 |
i.dobson
Joined: 05 Jan 2006
Posts: 1571
Location: Basel, Switzerland
|
| Posted: Sun Jun 24, 2012 1:26 pm Post subject: |
|
|
Hi,
Correct. Every i2c device has 2 addresses, one for read and one for write. The lowest bit is the R/W flag.
I think theres a simple i2c bus scan in the samples dir. Note the step 2 for the for/next loop.
| Code: | '------------------------------------------------------------------
' (c) 1995-2007 MCS
' i2cscan.bas
'purpose : scan all i2c addresses to find slave chips
'use this sample in combination with twi-slave.bas
'Micro: Mega88
'------------------------------------------------------------------
$regfile = "M88def.dat" ' the used chip
$crystal = 8000000 ' frequency used
$baud = 19200 ' baud rate
Dim B As Byte
Config Scl = Portc.5 ' we need to provide the SCL pin name
Config Sda = Portc.4 ' we need to provide the SDA pin name
'we use the TWI pins of the Mega88
$lib "i2c_twi.lbx" ' we do not use software emulated I2C but the TWI
Print "Scan start"
For B = 0 To 254 Step 2 'for all odd addresses
I2cstart 'send start
I2cwbyte B 'send address
If Err = 0 Then 'we got an ack
Print "Slave at : " ; B ; " hex : " ; Hex(b) ; " bin : " ; Bin(b)
End If
I2cstop 'free bus
Next
Print "End Scan"
End |
Regards
Ian Dobson
_________________
Walking on water and writing software to specification is easy if they're frozen. |
|
| Back to top |
|
|
Csaba
Joined: 05 May 2012
Posts: 25
|
| Posted: Sun Jun 24, 2012 1:35 pm Post subject: |
|
|
Dear Ian,
Thanks for the answer.
The case, is that I'd like it to be written in the manual. "How to prepare a BASCOM i2c address from an i2c address?"
But it is good for it to be here, too. Anyone - like me - can find it here, when in doubt.
Regards,
Csaba |
|
| Back to top |
|
|
i.dobson
Joined: 05 Jan 2006
Posts: 1571
Location: Basel, Switzerland
|
| Posted: Sun Jun 24, 2012 1:58 pm Post subject: |
|
|
Hi,
I'd say it's already in the help text:-
| Quote: | As said a data transfer can occur after a start condition of the master. The length of data sent over I²C is always 8 bit this includes a read/write direction bit, so you can effectively send 7 bits every time.
The most significant bit MSB is always passed first on the bus.
If the master writes to the bus the R/W bit = 0 and if the master reads the R/W bit = 1.
After the R/W bit the master should generate one clock period for an acknowledgement ACK. |
see the chapter "Using the i2c protocol" in the help text.
Regards
Ian Dobson
_________________
Walking on water and writing software to specification is easy if they're frozen. |
|
| Back to top |
|
|
MWS
Joined: 22 Aug 2009
Posts: 2335
|
| Posted: Sun Jun 24, 2012 1:58 pm Post subject: |
|
|
| Csaba wrote: | | The case, is that I'd like it to be written in the manual. "How to prepare a BASCOM i2c address from an i2c address?" |
What manual ? And why do you think you must prepare i.e. convert any address ? Bascom does not use a different address definition.
The only stumbling block can be, that for some devices their according data sheets name the I2C-address as 7-bit address without the read/write bit.
You have then to connect strings yourself, example:
I2C (7bit) base address = &h20 = &b0100000
The actual I2C write address which Bascom expects:
&b01000000 = &h40
Read address:
&b01000001 = &h41
But that is I2C-knowledge and not necessarily Bascom-knowledge. |
|
| Back to top |
|
|
Csaba
Joined: 05 May 2012
Posts: 25
|
| Posted: Sun Jun 24, 2012 2:46 pm Post subject: |
|
|
Dear MWS,
I disagree.
I2C addresses are in the range 0 - 7F. They can be even and odd numbers.
If you read it in a catalog, the addresses are stated so. In every catalog I've seen. Probably PHILIPS defined it to be so.
If you use some other language - and BASCOM is not in an isolated software island - in their i2c routines (in ATMEL-C examples, STM examples, NXP examples) you find to use the 7bit i2c address. The routines make the shift inside themselves, there. Generally, one defines a 7 bit i2c address in C.
The least significant bit is not read/write only, e.g. for slave i2c programs.
If you convert or interface something from C to BASCOM, you will catch this "discrepancy" sooner or later.
But. It is completely fine to use it the "BASCOM WAY". Just it has to be written somewhere, to find it easily for beginners, like me.
As I used to say, it would be some minor improvement.
BASCOM is having an extensive documentation with a lot of examples, etc. That I meant as a "manual".
You are used to BASCOM, as I see. But should you interface with a device on i2c with a colleague writing his part in C, you must tell him your address shifted 1 bit right.
If you attach a device, which states it's i2c address to be 7F, than you have to use in BASCOM
Const New_i2c_device_address = &hFE ' BASCOM addresses are in the range 0 - FF, but can be EVEN numbers only.
Regards,
Csaba |
|
| Back to top |
|
|
MWS
Joined: 22 Aug 2009
Posts: 2335
|
| Posted: Sun Jun 24, 2012 3:31 pm Post subject: |
|
|
Csaba,
| Csaba wrote: | | I2C addresses are in the range 0 - 7F. They can be even and odd numbers. |
think you're on the wrong track, and the right way is self-explaining if you have a look on how Bascom sends the address.
This comes from the ds1307 sample:
| Code: | I2cwbyte Ds1307w
' ...
I2cwbyte Ds1307r |
As you see the address is written by the same standard command I2cwbyte, which is also used for register and data access.
Now ask yourself: how would it be possible with a 7 bit I2C address and this standard command to differentiate a read from a write ?
I feel this is self-explaining, if one thinks about.
However, if Bascom would provide dedicated functions called I2cwradr and I2cwwadr, I would think differently and then I would give you the point.
About C, you either use there prefab'd functions or you write these yourself and control therein any register access, but in the very end an 8 Bit value has to be written into TWDR, and this value is made up from a 7bit address + 1bit r/w, here's a short C example from a typical AVR data sheet:
| Code: | TWDR = SLA_W;
TWCR = (1<<TWINT) | (1<<TWEN); |
You may notice that SLA_W exactly corresponds the way how Bascom expects the address.
So I say that Bascom is here much closer to Atmel AVR than C-addressing with 7bit is. The reason is, Bascom AVR is dedicated to AVR, while C does the abstraction on it's lowest layer, as it must work for other controllers too, which may need different control to send the r/w bit.
Edit:
I did my explanation on base of I2cwbyte, for not omitting your initial question about I2csend/receive:
a) of course it's consistently used there too
b) it is exactly explained in the help for the I2csend command:
| Quote: | I2C uses a 7 bit address from bit 1 to bit 7. Bit 0 is used to specify a read/write operation. In BASCOM the byte transmission address is used for I2C.
This means that an I2C 7-bit address of 1 becomes &B10 = 2. And we say the address is 2. This is done so you can copy the address from the data sheets which are in the same format in most cases. So if you work with 7 bit address, you need to multiply the address by 2. |
|
|
| Back to top |
|
|
Csaba
Joined: 05 May 2012
Posts: 25
|
| Posted: Sun Jun 24, 2012 11:20 pm Post subject: |
|
|
Dear MWS,
The issue is solved with your last quotation. That was the sentence I missed from my bascom manual. Thanks for showing me, it's already there.
I've just downloaded the newest version of "BASCOM-AVR user manual". It is clear and fine in this issue, unlike my older one. Sorry, it was my mistake to use an older manual.
As for the C question, my ATMEL created TWI-C source contained this line:
TWI_Slave_Initialise( (TWI_slaveAddress<<TWI_ADR_BITS) | (TRUE<<TWI_GEN_BIT) );
Which gave me a false impression about using i2c addresses.
So the issue is solved. Thanks for your help!
Regards,
Csaba |
|
| Back to top |
|
|
MWS
Joined: 22 Aug 2009
Posts: 2335
|
| Posted: Mon Jun 25, 2012 1:57 am Post subject: |
|
|
Csaba,
| Csaba wrote: | | The issue is solved with your last quotation. That was the sentence I missed from my bascom manual. |
Also found the quote a bit late...
| Quote: | As for the C question, my ATMEL created TWI-C source contained this line:
TWI_Slave_Initialise( (TWI_slaveAddress<<TWI_ADR_BITS) | (TRUE<<TWI_GEN_BIT) ); |
Looked up the complete code, where this line is from. The use is differently, as it sets TWAR for making the TWI slave respond to the right address.
But it is somehow similar to how it's done for the r/w address. It does one left shift of the slave 7bit address together with an "or" of the general call bit.
As said the target is TWAR here, in contrary as master the slave address is written to TWDR.
You're welcome. |
|
| Back to top |
|
|
Csaba
Joined: 05 May 2012
Posts: 25
|
| Posted: Mon Jun 25, 2012 2:25 am Post subject: |
|
|
Dear MWS,
This manual I've downloaded now is GREAT!
You cannot compare it with the one I've used. (avr20manual 201_11_7.pdf, 368 pages <-> 1000+ pages of the new)
I'd never started this discussion, if I had this one.
Thanks,
Csaba |
|
| Back to top |
|
|
|
|
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
You cannot attach files in this forum
You cannot download files in this forum
|
|
FAQ
Search
Register
Log in
