Embedded Open Modular Architecture/EOMA68/FAQ
This section is more informal than the specification. Its main purpose is to highlight, from key conversations held on the Internet, what is special about EOMA68 when compared to other standards.
- 1 OK, but why do you want EOMA to be installed/removed more often - I want to understand why granny would want to do this?
- 2 Why are the interfaces in EOMA68 mandatory?
- 3 Why are there so many pins dedicated to the LCD? 21 pins out of 68 is a lot: surely some other interface such as composite video (VGA) could be used for example?
- 4 We have a device where we want to save cost by assuming that all CPU Cards will come with the same ports as the very first CPU Card (the Allwinner A10). Is that ok?
- 5 Could you please modify the EOMA68 Standard so that it at least requires Micro-SD, or HDMI, or USB-OTG?
- 6 We heard that EOMA68 is restricted to very low screen resolutions, and that 1080p is not supported.
OK, but why do you want EOMA to be installed/removed more often - I want to understand why granny would want to do this?
" SO-DIMM sockets have a lifecycle of about .... something like 25 cycles *total*. Maybe not Granny but a professional who has an EOMA68-compliant Digital SLR Camera, as well as an EOMA68-compliant smartphone, tablet, laptop, and 30in LCD monitor at work and a games console at home. They might end up inserting/removing their EOMA68 CPU Cards up to 10 times a *day*. The potential here is *huge*. it covers virtually every mass-volume electronics system you can think of, in the world. With the exception of the hard-core gaming industry, the high-end server market, high-end / real-time video editing Industry and ... err... i run out of examples where EOMA68 could not be used. oh yeah: portable watches :)"
- From: http://ibot.rikers.org/%23arm-netbook/20120929.html.gz @ 18:57.53 (slightly reformatted)
Why are the interfaces in EOMA68 mandatory?
EOMA68 is a mass-volume user standard, not a factory-installation standard. Imagine a situation where a customer buys a CPU Card where there was no support for one of the USB ports, for example. They would be extremely annoyed when plugging it in to device that required both USB ports, to find that half the internal peripherals were inaccessible. This would result in returns of products, threatening the viability and acceptability of the standard.
About the only situation where not supporting some of the interfaces would be acceptable is a "pass-through card", especially one that's pre-installed, say in an LCD product that can be upgraded to a TV or a PC. Leaving out access to SPI-based peripherals on a pass-through card would make sense. Ideally however a "perfect" pass-through card would have a USB-to-MicroSD converter on it, as well as a USB Hub to give access to the 2 EOMA68 USB interfaces, and some form of HDMI/DVI to RGB/TTL converter in order to comply as sensibly as possible to the EOMA68 standard.
Why are there so many pins dedicated to the LCD? 21 pins out of 68 is a lot: surely some other interface such as composite video (VGA) could be used for example?
VGA is surprisingly power-hungry as it is 75 ohms, and, at higher resolutions the analog R,G,B lines would be running at exceptionally high frequencies. An 18-pin parallel digital bus runs at much lower speeds, using less power. Additionally, the EOMA68 Standard is designed for use for devices with LCD panels all the way from around 320x240 all the way up to 1920x1080 if the CPU supports that rate. If the standard required Composite Video, the cost of the ICs for converting from RGB/TTL to VGA plus the cost of converting back from VGA into RGB/TTL would threaten the viability of a low-cost product due to the additional cost. The larger products can however much easier absorb the cost of an LVDS or other converter IC. So the main reasons are: economics of scale. Also, the remaining 47 pins are perfectly sufficient for providing general-purpose "multi-peripheral" interfaces (I2C, SPI, SD/MMC, USB).
We have a device where we want to save cost by assuming that all CPU Cards will come with the same ports as the very first CPU Card (the Allwinner A10). Is that ok?
It would be best not make any such assumptions when developing products. Future CPU Cards will include, for example, a built-in 3G antenna at the end (just as there are now with 3G cards for the legacy PCMCIA standard), where it will be important to keep any metal away from the antenna. Such CPU Cards could not have metal connectors like HDMI, or USB-OTG or Micro-SD; Micro-SD, just like with the SIM Card, would have to be top-loaded through the case. Products should be designed with this in mind. Realistically, however, end-users will clearly be able to see from the specification of a particular CPU Card what connectors it has.
Could you please modify the EOMA68 Standard so that it at least requires Micro-SD, or HDMI, or USB-OTG?
Taking each of these in turn, the answer has to be no, each for different reasons:
- HDMI - some ultra-low-cost SoCs only have one video output (usually RGB/TTL LCD out). The cost of an RGB/TTL LCD to HDMI Converter IC is often $5 and requires a $50,000 HDMI License! To require an HDMI output, apart from R.F. interference with a 3G CPU Card's antenna, would make such low-cost SoCs prohibitively expensive.
- USB-OTG - again: many ultra-low-cost SoCs only have USB2. Whilst many of them have 2 USB2 interfaces, if one came along which only had 1x USB interface, then if USB-OTG user-facing was part of the EOMA68 Standard it would be necessary to put down a $1.50 USB-OTG Hub IC and other components, automatically eliminating any competitive advantage of using that lower-cost SoC in the first place.
- Micro-SD here it is different, but the same story. Even Micro-SD is quite wide (16mm) so in cases where a 3rd party EOMA68 CPU Card Manufacturer makes a card with many connectors on the end, there simply may not be space for Micro-SD, and they may choose to make the Micro-SD "top-loading", or even leave it out altogether and use NAND Flash only.
We heard that EOMA68 is restricted to very low screen resolutions, and that 1080p is not supported.
This is not true. There are two variants: Type I (3.3mm high) which is designated for 1920x1080 RGB/TTL output, and Type II (5.0mm high) which is designated for up to 1366x768 RGB/TTL output. The height restriction prevents Type II cards being slotted into Type I sockets (where they simply won't work).
There is no restriction on the use of user-facing video outputs - HD or 4k outputs are perfectly acceptable.