<br><br><div class="gmail_quote">2012/1/9 lkcl luke <span dir="ltr"><<a href="mailto:luke.leighton@gmail.com">luke.leighton@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Jan 9, 2012 at 3:20 AM, Bari Ari <<a href="mailto:bari@onelabs.com">bari@onelabs.com</a>> wrote:<br>
> My understanding is that the FIR interface is muxed with UART2 and<br>
> supports SIR, CIR,MIR and FIR.<br>
><br>
> I'll be sure to go over all the muxed pins and let everyone chime in<br>
> before we finish the board layouts to make them as flexible as possible.<br>
<br>
i've been going over the pinouts and documented the options here, if<br>
anyone would like to help go over this:<br>
<br>
<a href="http://rhombus-tech.net/allwinner_a10/orders/" target="_blank">http://rhombus-tech.net/allwinner_a10/orders/</a><br>
<a href="http://rhombus-tech.net/allwinner_a10/pinouts/" target="_blank">http://rhombus-tech.net/allwinner_a10/pinouts/</a><br>
<br>
attached is a first revision (diagram)<br>
<br>
* 2pins: 1x USB-2<br>
* 8pins: 5-pin AC97 shared with 8-pin I2S Signals.<br>
* 2pins: PWM0 (PB2) and PWM1 (PI13)<br>
* 2pins: IR_TX and IR_RX (also GPIOs, one of which is EINT16)<br>
* 4pins: TV-Out<br>
* 4pins: 4-wire Resistive Touchscreen<br>
* 20pins: 2x LVDS<br>
<br>
almost all of those can be muxed to general-purpose IO, giving about 34 GPIOs<br>
<br>
then, also, by putting the other RGB/TTL (not the LVDS-capable one)<br>
onto the 68-pin connector it would be possible to flip those pins over<br>
to an IDE (PATA) port.<br>
<br>
i still haven't worked out what the GPIO pins should be. definitely<br>
more of the EINTNN pins. possibly one of the SD/MMCs, probably one of<br>
the SPIs: i haven't put one of those out anywhere, at all. probably<br>
one of the UARTs as well.<br>
<br>
hmmm... PI10 through to PI21 seem to be good candidates:<br>
<br>
# C17 SPI0_CS0/UART5_TX/EINT22/PI10<br>
# D17 SPI0_CLK/UART5_RX/EINT23/PI11<br>
# C16 SPI0_MODI/UART6_TX/EINT2/PI12<br>
# D16 SPI0_MISO/UART6_RX/EINT25/PI13<br>
# C15 SPI0_CS1/PS2_SCK1/TCLKIN0/EINT26/PI14<br>
# D15 SPI1_CS1/PS2_SDA1/TCLKIN1/EINT27/PI15<br>
# E17 SPI1_CS0/UART2_RTS/EINT28/PI16<br>
# E16 SPI1_CLK/UART2_CTS/EINT29/PI17<br>
# E15 SPI1_MOSI/UART2_TX/EINT30/PI18<br>
# D14 SPI1_MISO/UART2_RX/EINT31/PI19<br>
# E14 PS2_SCK0/UART7_TX/HSCL/PI20<br>
# E13 PS2_SDA0/UART7_RX/HSDA/PI21<br>
<br>
and maybe these:<br>
# A7 UART0_TX/IR1_TX/PB22<br>
# B7 UART0_RX/IR1_RX/PB23<br>
<br>
and, if nothing else, probably these:<br>
# C8 TWI2_SCK/PB20<br>
# C7 TWI2_SDA/PB21<br>
<br>
although if there are 2 left, it might be worthwhile doing analog<br>
audio out, somehow, even if it means a bit of extra circuitry.<br>
<br>
it's tricky because bizarre as it sounds we're running out of pins to<br>
choose from! :) pingroups A, C, D and S are already taken up. the<br>
ones in the "other" group are hard-wired and not GPIO capable.<br>
<br>
thoughts anyone?<br>
<br>
<br>
btw no i do *not* think it would be a good idea to have the<br>
LVDS-capable port on the 68-pin connector. not only would it then not<br>
be possible to conveniently get access to the PATA port, but also it<br>
would risk people going "oh look! LVDS! let's make a<br>
cheapo-motherboard that doesn't bother to respect EOMA-compliance".<br>
<br>
to be successful, standards have to be absolutely non-optional: it's<br>
enough of a risk to have these multiplexing options on the very first<br>
CPU card.<br>
<br>
if that's not clear enough, allow me to go through it. what happens<br>
if LVDS is available as an "option" alongside RGB/TTL?<br>
<br>
a) motherboards get created which have to be capable of detecting<br>
either LVDS _or_ RGB/TTL capable CPU cards. the cost has therefore<br>
just gone up.<br>
<br>
b) *all* CPU cards *must* now have circuitry (if the CPU doesn't have<br>
the exact same pinouts as the Allwinner A10) which flips LVDS _or_<br>
RGB/TTL onto the 68-pin connector. the cost has therefore gone up.<br>
<br>
either way, putting LVDS and RGB/TTL onto the 68-pin connector<br>
actually, far from providing nice benefits, actually destroys the<br>
entire project's viability. for the sake of a $1 IC (in higher-cost<br>
products anyway).<br>
<span class="HOEnZb"><font color="#888888"><br>
l.<br>
</font></span><br>_______________________________________________<br>
arm-netbook mailing list <a href="mailto:arm-netbook@lists.phcomp.co.uk">arm-netbook@lists.phcomp.co.uk</a><br>
<a href="http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook" target="_blank">http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook</a><br>
Send large attachments to <a href="mailto:arm-netbook@files.phcomp.co.uk">arm-netbook@files.phcomp.co.uk</a><br></blockquote></div><br><div>I looked at the pinouts desription in:</div><div><br></div><div> <a href="http://rhombus-tech.net/allwinner_a10/pinouts/" target="_blank">http://rhombus-tech.net/allwinner_a10/pinouts/</a></div>
<div><br></div><div>And more specifically in pin group D. Will the Smart Card (SIM Card) Interface continue to co-exist as multiplexed function along with RGB/TTL interface? After the decision to multiplex the RGB/TTL with PATA interface I wondered if there will be spare pins for multiplexing the Smart Card (SIM Card).</div>
<div>As for the necessity of Smart Card (SIM Card) Interface, it may be utilized in:</div><div><br></div><div>1. Consumer devices like mobile devices, where SIM card may be used.</div><div>2. Industrial devices like security access devices, ATMs and etc.</div>
<div><br></div><div>I make this comments from business point of view, not taking into account all technical considerations.</div><div><br></div><div>Iliya</div>