View source for Talk:Embedded Open Modular Architecture/EOMA68
- 1 Power Provision
- 2 Confusion over definition of I2C Addresses
- 3 I2C EEPROM read/write
- 4 Copy of Wikipedia EOMA68 page before it gets deleted
need to clarify power provision, add a separate section to the specification. need to take into account type I, II and III cards as well.
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
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
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.
Copy of Wikipedia EOMA68 page before it gets deleted
A lot of collaborative effort went into writing this page, however there was such a huge amount of misunderstandings, lack of trust and completely inaccurate editing by "experienced" wikipedia editors that it was decided that a copy should be taken before it was destroyed.
EOMA68 is an open technical standard for low-power modular computing, authored by Luke Kenneth Casson Leighton. EOMA68 is designed to save money long-term for end-users, reduce e-waste and promote green computing by facilitating "Computing module" re-use, and is also designed with low space requirements and low power consumption in mind. EOMA68 is an "interface-aggregation" standard that is not restricted to processors or to general-purpose computing at all: a pass-through card or FPGA Card is permitted by the standard. EOMA68 is based around re-use of legacy PCMCIA. Unlike many single-board computers, EOMA68 cards would therefore have all the benefits of the slim form factor and robust protective housing from legacy PCMCIA cards.
- 54 mm × 85.6 mm; 5mm variant (Type II)
- 54 mm × 85.6 mm; 3.3mm variant (Type I)
Type I is reserved for up to 1366x768 RGB/TTL video output; Type II is reserved for up to 1920x1080 RGB/TTL video output, on the basis that a Type I 3.3mm card may fit into a Type II 5.0mm socket but not vice versa. Thus, a module with a lower-capacity video output will physically be prevented from being used with incompatible higher-resolution devices, preventing any possible confusion about interoperability.
The EOMA68 specification defines an aggregated set of non-optional general-purpose interfaces which are themselves open and in common use for several decades.
- 1× USB 2.0 or below
- 1× USB 3.1 or below
- 1× SDIO up to 4-bit
- RGB/TTL up to 18-bit, minimum 1366x768 for "Type I" and 1920x1080 for "Type II".
- I²C Bus
- SPI (Serial Peripheral Interface Bus) up to 4-bit
- 1x 2-pin UART (Tx, Rx only)
- 4x External-interrupt-capable GPIO (EINT)
- 1x PWM (Pulse-width modulation)
All pins (with the exception of USB, I2C, RGB/TTL, 5V power and Ground pins) must be dual-function GPIO that uses CMOS-level signalling relative to a Reference Voltage, VREF supplied from EOMA68 Card. Additional general-purpose interfaces of any kind (HDMI, Wi-Fi, Audio, USB-OTG and many more) are permitted at the user-facing end (just as was with PCMCIA) on a per-module basis.
EOMA68 re-uses legacy PCMCIA connectors, housings, sockets and assemblies but is not electrically or electronically compatible with the legacy PCMCIA standard. Just as with PCMCIA, the user-facing end of EOMA68 may be used for any purpose, such as provision of WIFI antennae, HDMI or USB-OTG connectors.
EOMA68 is unusual (but not unique) in that all its interfaces are mandatory. Examples of the very few other "aggregation" style specifications that require all interfaces to be mandatory include PC/104 and COM Express. The consequences of mandatory interfaces are that there is no possible source of confusion for end-users throughout the entire projected standard's lifetime.
Mandatory interface requirements is frequently confused with mandatory restrictions on speed of the interfaces, however this is not the case. A good example is SD/MMC, which includes hardware-level speed auto-negotiation as well as data path auto-negotiation. Connecting an EOMA68 module with a 4-pin SD/MMC implementation into an EOMA68 socket with a 2-pin SD/MMC interface (so that the other 2 pins may be used for GPIO) will result in automatic hardware-level auto-negotiation to use the available connected 2 pins. Another good example is USB 3.1, which is down-speed compatible with all prior USB standards, depending not only on the pins that are connected but also on protocol-level negotiation over the USB bus itself (called USB "chirping").
Template:Unreferenced section One intended use case is for a CPU, memory and motherboard to be completely contained in the EOMA68 form factor, with a host (designated a "Housing" in EOMA68 terminology) comprising mostly peripherals to be using that card for all or most of its computing power. The "Housing" would therefore typically provide a screen and one or more human interface devices and have the form factor of, for example, a laptop, or a desktop, or a tablet, or a hand-held games console.
An alternative use case is for the card to be used standalone, as a robust single-board computer. In this use case scenario, the user-facing end of the EOMA68 card would have power input (such as in the form of USB-OTG) and video output (typically HDMI). In this instance it would be near-identical in functionality to a Stick PC.
Another use case is the Pass-through Card. This in effect simply "passes through" the pins of EOMA68 to more easily-accessible connectors at the other end, potentially performing aggregation or conversion (such as RGB/TTL to HDMI). The use of Pass-through Cards turns Housings into simple peripherals that may be plugged into other computing devices, for example via USB and HDMI. A Laptop "Housing" could therefore act as a second (battery operated) screen and keyboard for a laptop, tablet, smartphone or Desktop PC. An engineering variant of the Pass-through Card would simply provide direct and convenient access to the (small) pinouts of EOMA68 to a form that is easier for electronics engineers to experiment with, such as to a 68 Pin header.
Claimed "eco" benefits
When a new CPU is manufactured (and used in an EOMA68 Computer Card), it is possible to upgrade "Housings" merely by replacing only the Computer Card, and to re-purpose the older one in alternative EOMA68-compatible Housings. The rest of the hardware is left as-is and may be kept in service indefinitely. Thus, by ensuring that older Computer Cards and Housings are kept out of landfill, it may be reasonably claimed that EOMA68 is eco-conscious and helps reduce e-waste.
Additionally, the cost of developing custom connectors, sockets, housings and casework is extremely high, typically requires ordering of extremely large numbers of units, as well as being time-consuming to designTemplate:Citation needed. The re-use of an existing legacy set of appropriate connectors, sockets, housings and casework from a prior legacy standard (PCMCIA) also helps justify the "eco" aspect of EOMA68, through enormous cost and time savings in both development and deployment, as well as allowing much lower initial quantities of parts.
Also, to ensure that counter-claims of the hardware being unavailable once it is no longer in production (such as a company going out of business), thus effectively neutralising any long-term eco-benefits by making it impossible to repair, manufacture replacements or find spare parts, EOMA68's first designs follow the highly successful Arduino collaborative and cooperative model, where both the hardware and software is made entirely public.
In August 2016, the first publicly-available hardware compliant with EOMA-68 was crowd-funded through Crowd Supply. The first Computing Module in the series, the EOMA68-A20, was offered in a "Libre Tea" variant with the Parabola GNU/Linux-libre operating system installed, and is a candidate for Respects Your Freedom certification. Additional hardware included two "Housings" - a Micro-Desktop and a 15.6in Laptop - as well as a break-out board for engineers and a Pass-through Card. The only implementations currently available are the Type II EOMA68 cards (5.0mm height).
- Specification homepage at elinux.org
|Thread title||Replies||Last modified|
|shipping ever?||0||16:23, 2 August 2019|
|Requirements for SD/MMC and SPI||1||08:57, 31 July 2016|
|Requirements for RGB/TTL - 16 vs 18 bit bus||1||08:57, 31 July 2016|
You do not have permission to edit this page, for the following reasons:
- The action you have requested is limited to users in the group: Users.
- You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.
You can view and copy the source of this page.
"In essence, the SD/MMC committee have caused a bit of trouble, here, but it may be best to trust their experience in that SD/MMC Cards have probably not, for some considerable time, been actually using SPI mode, but have been offering the 2, 4 (and now 8) lane capability for a long, long time."
By 2-bit, do we mean the SD/MMC mode where data is transferred one bit at a time over either command or data lines? Just to get the terminology right, I believe SD calls it 1-bit SD.
"EOMA-68's RGB/TTL interface is 18-bit-wide. If a particular SoC only has e.g. 16-bit or 15-bit RGB/TTL then the LSB (lower) bits MUST be set to logic output level 0 when the LCD interface is enabled: they must NOT be left floating or tri-state. This ensures that devices which are expecting the full 18-bits do not receive noise on the lower bits of each of the R,G and B 8-bit inputs."
While I agree floating is bad, I'm not certain requiring those pins to be grounded is the best solution as it will prevent the display from ever showing full Red, Blue, Green, or White. Instead, if enough drive-strength is available, any extra LSBs can be tied to the corresponding MSBs for each channel. Or, it could be tied to other pins driven by actual data.