I vote for a close compatiblilty as possible. The most important for me on
the connector are the LCD, serial comm ports, address, and data bus.
The USB is important, but not so with OTG.
--Glen
On Friday 27 May 2005 9:20 am, Chris Jones wrote:
> Hi all,
>
> The design of Balloon 3 is coming along well, and has reached the point
> where there are some niggles to resolve.
>
> The first of these is the pinout of the backplane (Samtec) connector.
> Many of the pins will retain just the same functions as they have in
> Balloon 2 (the memory controls, data and address buses, PCMCIA, LCD and
> to some extent power) but others are going to have to change. The ones
> which change fall into a few areas:
>
> 1. Audio
> The backplane on loon 2 has the I2S signals for the audio codec on it.
> Balloon 3 will use an AC97 codec, and therefore these signals become
> meaningless. There are a couple of choices here:
> - present the AC97 audio signals on some other pins and leave the
> original I2S pins unconnected. We'd have to find 5 spare pins for this,
> which isn't too hard.
> - wire the AC97 signals to the old I2S pins in such as way so as to
> allow I2S to work as before when the PXA270 is put into I2S mode (which
> it can do) and find one more pin for the remaining AC97 signal.
> The latter strikes me as the most efficient option, allowing off-board
> codecs of both AC97 and I2S varieties without wasting pins. Thoughts?
>
> The backplane on loon 2 also includes a microphone input. Loon 3 won't
> have a microphone input, only a line-level one, to ease noise problems.
> Should we present this on the same pins, or different ones?
>
> 2. GPIO pins
> The loon 2 backplane presents GPIOs 0, 1 and 10-27 from the SA1110, most
> of which have well-defined functions (power switching, I2C, various
> interrupts, and so on). Not surprisingly, the GPIO allocation on loon 3
> is entirely different due to the PXA270's enormous selection of on-chip
> peripherals. Here there are a couple of options, I think:
> - slavishly wire up the same GPIOs 0, 1 and 10-27 from the PXA270. This
> would keep the labels the same but render the pins almost entirely
> useless. Some of them would even be duplicates of signals present
> elsewhere. I vote we don't do this.
> - find nearest equivalent signals for each pin as far as possible, and
> try to put general-purpose I/Os on the remaining ones. This should make
> it possible for backplane devices to work based on the signals they
> assume are present, but will present some software compatibility issues
> if anyone is doing direct GPIO twiddling, which they really shouldn't be
> ;-) Inevitably there will be a few pins with no equivalent (things like
> the onboard ID signal and RTC interrupt) but we can use them as general
> purpose signals.
>
> 3. Serial ports
> As luck would have it, PXA270 has 3 serial ports just like SA1110. I
> propose the following arbitrary mapping of one to the other:
> SA1110 COM1 (pinko): PXA270 BTUART (doubles as Bluetooth)
> SA1110 COM2 (bottom serial port): PXA270 FFUART (full-featured UART)
> SA1110 COM3 (console, top serial port): PXA270 STDUART (doubles as IrDA)
>
> Any complaints?
>
> 4. Other peripherals
> Because the PXA has a bucketload of other peripherals on board, we could
> bring some of them out to the backplane connector. I can see 30 spare
> pins on the Samtec connector. Peripherals not currently exposed on the
> Samtec include:
> - AC97 audio (but see above)
> - extra LCD signals (L_CS and L_A0)
> - FFUART serial handshake lines
> - MMC/SD
> - MSL (high speed parallel-ish bus)
> - Camera interface
> - Keypad (but these are mostly getting used as power control lines etc)
> - Samosa bus
> - USB OTG stuff (eeeuuurgghh)
>
> Any votes? My top choices would be the extra LCD and serial signals, for
> completeness, plus MMC and Camera in that order. MSL is mostly intended
> to go to the onboard FPGA.
>
> If there's anyone you know is not on the balloonboard list but will be
> affected by these decisions, please let me know and I'll copy them on
> the mail. All feedback most welcome, otherwise I'll make arbitrary
> decisions and not let you blame me for them...
>
> Chris
(text/plain)