Difference between revisions of "Talk:Embedded Open Modular Architecture/EOMA68"

From eLinux.org
Jump to: navigation, search
(Alternative layout)
(One intermediate revision by the same user not shown)
Line 1: Line 1:
= High Power version =
+
= Confusion over definition of I2C Addresses =
  
ideas: convert 2 pins to extra power (as part of standard) and allow for Type III cards (8mm height).  that would give 10 watts and enough space for decent heat-sinks and heat removal. http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-January/001780.html http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-January/001822.html
+
There has been considerable confusion even when developing the EOMA68 specification, after finding datasheets that do not correctly describe their addresses.  The confusion stems from treating the first 8 bits as an 8-bit number (MSB first) and many datasheets - including that of the recommended part for the I2C EEPROM AT24C64) - propagate this confusion in ''direct'' violation of the I2C specification.
  
= Alternative layout =
+
To correctly identify an I2C address, the first 7 bits must be treated as a 7-bit decimal number (MSB first).  The 8th bit is a read-write indicator.  Many datasheets '''incorrectly''' report two separate I2C "addresses", one is double that of the correct address and the other is double plus one.
  
provides option of gigabit ethernet
+
'''Please ensure when complying with the EOMA68 specification that an EEPROM with the correct I2C address of 0x51 rather than 0xA2 and 0xA3 are used.'''
  
{|cellpadding="5" cellspacing="0" border="1" width="60%"
+
<pre>
!style="width:50%"|Row 1
+
>  so what you're saying is that just because (if you were reading the 8
!style="width:50%"|Row 2
+
> bits in sequence), the bit that comes *after* the I2Caddress (its LSB)
|-
+
> is in the place that, if it *was* an 8-bit address, you'd call it bit
|* 1 LCD Pixel Data bit 0 (Red0)
+
> 0.  but you should never consider this to be so, instead should read
|* 35 LCD Pixel Data bit 1 (Red1)
+
> the 7 bits only then treat the 8th bit as completely separate, right?
|-
+
>
|* 2 LCD Pixel Data bit 2 (Red2)
+
>  so that would explain how i managed to read 0xA2 as being the I2C
|* 36 LCD Pixel Data bit 3 (Red3)
+
> EEPROM read address and 0xA3 as the I2C EEPROM write address, when in
|-
+
> fact they're *both* 0x51 and the R/W bit has absolutely nothing to do
|* 3 LCD Pixel Data bit 4 (Red4)
+
> with the actual address, would that be right?
|* 37 LCD Pixel Data bit 5 (Red5)
+
 
|-
+
Yes. I don't remember where I had read that, but somehow I remembered
|* 4 LCD Pixel Data bit 6 (Red6)
+
that, to not be too surprised to hit actual cases of such confusion few
|* 38 LCD Pixel Data bit 7 (Red7)
+
times later. I didn't really do my own due diligence, but good chance
|-
+
to do it now. So, wikipedia https://en.wikipedia.org/wiki/I%C2%B2C
|* 5 LCD Pixel Data bit 8 (Green0)
+
links to "Official I2C Specification, NXP"
|* 39 LCD Pixel Data bit 9 (Green1)
+
http://www.nxp.com/documents/user_manual/UM10204.pdf . That clearly
|-
+
states in section 3.1.10 that "This address is seven bits long
|* 6 LCD Pixel Data bit 10 (Green2)
+
followed by an eighth bit which is a data direction bit (R/W)".
|* 40 LCD Pixel Data bit 11 (Green3)
+
Googling for "i2c address confusion" in particular finds
|-
+
http://www.totalphase.com/support/kb/10039/ which goes over 7/8 bit
|* 7 LCD Pixel Data bit 12 (Green4)
+
confusion and which one is correct.
|* 41 LCD Pixel Data bit 13 (Green5)
+
</pre>
|-
+
 
|* 8 LCD Pixel Data bit 14 (Green6)
+
= I2C EEPROM read/write =
|* 42 LCD Pixel Data bit 15 (Green7)
+
 
|-
+
* aseigo 2013nov05
|* 9 LCD Pixel Data bit 16 (Blue0)
+
 
|* 43 LCD Pixel Data bit 17 (Blue1)
+
http://lists.phcomp.co.uk/pipermail/arm-netbook/2013-November/009233.html
|-
+
 
|* 10 LCD Pixel Data bit 18 (Blue2)
+
there are three options:
|* 44 LCD Pixel Data bit 19 (Blue3)
+
 
|-
+
* a) the ID EEPROM must be writable
|* 11 LCD Pixel Data bit 20 (Blue4)
+
* b) the ID EEPROM must not be writable
|* 45 LCD Pixel Data bit 21 (Blue5)
+
* c) the ID EEPROM may be writable, but this should not be relied on by any
|-
+
software
|* 12 LCD Pixel Data bit 22 (Blue6)
+
 
|* 46 LCD Pixel Data bit 23 (Blue7)
+
c) may be writable, but portable software may not rely on this
|-
+
 
|* 13 LCD Pixel Clock
+
this is a middle ground which allows devices which would be in violation of
|* 47 LCD Vertical Synchronization
+
the standard in the (b) case to remain compliant, while allowing devices which
|-
+
really are best served by (a) to not only be compliant but also avoid having
|* 14 LCD Horizontal Synchronization
+
theoretically portable software not performing correctly on them.
|* 48 LCD Pixel data enable (TFT) output
+
 
|-
+
basically, (c) implies that the EEPROM must be treated as not-writable in the
|* 15 I2C Clock (SCL)
+
general case. any user actions or software that attemps to write to the EEPROM
|* 49 I2C Data (SDA)
+
is classified as non-portable and device-specific, and the EOMA68 would provide
|-
+
zero guarantees as to the expected behaviour in such cases.
|* 16 GPIO (0)
+
 
|* 50 GPIO (1)
+
as this allows for compliant generic chassis *and* mass-market consumer
|-
+
devices, i highly recommend (c)
|* 17 GPIO (2)
+
 
|* 51 GPIO (3)
+
* lkcl2013nov06: agreed.
|-
 
|* 18 GPIO (4)
 
|* 52 GPIO (5)
 
|-
 
|* 19 GPIO (6)
 
|* 53 GPIO (7)
 
|-
 
|* 20 GPIO (8)
 
|* 54 GPIO (9)
 
|-
 
|* 21 GPIO (10)
 
|* 55 GPIO (11)
 
|-
 
|* 22 GPIO (12)
 
|* 56 GPIO (13)
 
|-
 
|* 23 GPIO (14)
 
|* 57 GPIO (15)
 
|-
 
|* 24 PWR (5.0V)
 
|* 58 PWR (5.0V)
 
|-
 
|* 25 ---- not used ---- / 1000 Eth BI_DD+
 
|* 59 ---- not used ---- / 1000 Eth BI_DD-
 
|-
 
|* 26 10/100 Ethernet (RX+) / 1000 Eth BI_DB+
 
|* 60 10/100 Ethernet (RX-) / 1000 Eth BI_DB-
 
|-
 
|* 27 10/100 Ethernet (TX+) / 1000 Eth BI_DA+
 
|* 61 10/100 Ethernet (TX-) / 1000 Eth BI_DA-
 
|-
 
|* 28 ---- not used ---- / 1000 Eth BI_DC+
 
|* 62 ---- not used ---- / 1000 Eth BI_DC-
 
|-
 
|* 29 PWR (5.0V)
 
|* 63 PWR (5.0v)
 
|-
 
|* 30 USB2 (Data+)
 
|* 64 USB2 (Data-)
 
|-
 
|* 31 GROUND
 
|* 65 GROUND
 
|-
 
|* 32 SATA-II Transmit (A+)
 
|* 66 SATA-II Transmit (A-)
 
|-
 
|* 33 GROUND
 
|* 67 GROUND
 
|-
 
|* 34 SATA-II Receive (B+)
 
|* 68 SATA-II Receive (B-)
 
|}
 

Revision as of 02:13, 6 November 2013

Confusion over definition of I2C Addresses

There has been considerable confusion even when developing the EOMA68 specification, after finding datasheets that do not correctly describe their addresses. The confusion stems from treating the first 8 bits as an 8-bit number (MSB first) and many datasheets - including that of the recommended part for the I2C EEPROM AT24C64) - propagate this confusion in direct violation of the I2C specification.

To correctly identify an I2C address, the first 7 bits must be treated as a 7-bit decimal number (MSB first). The 8th bit is a read-write indicator. Many datasheets incorrectly report two separate I2C "addresses", one is double that of the correct address and the other is double plus one.

Please ensure when complying with the EOMA68 specification that an EEPROM with the correct I2C address of 0x51 rather than 0xA2 and 0xA3 are used.

>  so what you're saying is that just because (if you were reading the 8
> bits in sequence), the bit that comes *after* the I2Caddress (its LSB)
> is in the place that, if it *was* an 8-bit address, you'd call it bit
> 0.  but you should never consider this to be so, instead should read
> the 7 bits only then treat the 8th bit as completely separate, right?
>
>  so that would explain how i managed to read 0xA2 as being the I2C
> EEPROM read address and 0xA3 as the I2C EEPROM write address, when in
> fact they're *both* 0x51 and the R/W bit has absolutely nothing to do
> with the actual address, would that be right?

Yes. I don't remember where I had read that, but somehow I remembered
that, to not be too surprised to hit actual cases of such confusion few
times later. I didn't really do my own due diligence, but good chance
to do it now. So, wikipedia https://en.wikipedia.org/wiki/I%C2%B2C
links to "Official I2C Specification, NXP"
http://www.nxp.com/documents/user_manual/UM10204.pdf . That clearly
states in section 3.1.10 that "This address is seven bits long
followed by an eighth bit which is a data direction bit (R/W)".
Googling for "i2c address confusion" in particular finds
http://www.totalphase.com/support/kb/10039/ which goes over 7/8 bit
confusion and which one is correct.

I2C EEPROM read/write

  • aseigo 2013nov05

http://lists.phcomp.co.uk/pipermail/arm-netbook/2013-November/009233.html

there are three options:

  • a) the ID EEPROM must be writable
  • b) the ID EEPROM must not be writable
  • c) the ID EEPROM may be writable, but this should not be relied on by any

software

c) may be writable, but portable software may not rely on this

this is a middle ground which allows devices which would be in violation of the standard in the (b) case to remain compliant, while allowing devices which really are best served by (a) to not only be compliant but also avoid having theoretically portable software not performing correctly on them.

basically, (c) implies that the EEPROM must be treated as not-writable in the general case. any user actions or software that attemps to write to the EEPROM is classified as non-portable and device-specific, and the EOMA68 would provide zero guarantees as to the expected behaviour in such cases.

as this allows for compliant generic chassis *and* mass-market consumer devices, i highly recommend (c)

  • lkcl2013nov06: agreed.