[Arm-netbook] UART

[Luke Kenneth Casson Leighton]

ok, now the reply :)


> From: f4eru <f4eru at free.fr>
> To: arm-netbook at lists.phcomp.co.uk
> Date: Tue, 27 Sep 2011 00:43:15 +0200
> Subject: UART
> Hello
>
>
> This project is neat ! I will definitely buy some boards if ever there
> will be a prod run.

 well, the plan is that there will be several CPU cards, and for
motherboards to start off with the "Mini Engineering Board" for
prototyping purposes, then move up to...

> a full fledged netbook with that interface would be nice also.

 ... things like full-fledged netbooks and also that monster 15in
laptop with a 1920x1080 LCD that gordon likes :)

> One thing lacking : as it could be used as a dev board, there should
> be two GPIOS specifically defined a TX and RX for an UART (dual use)

 ok - there's nothing to stop an individual CPU card from having:

 * absolutely anything on the front-facing part
 * absolutely any number of expansion headers, connectors etc.

 so, you _can_ have UART connector on the PCB of the CPU card, but
hidden underneath the PCMCIA shell of course.  for developer use, i'd
say this was ok.

 also, having found things like these Embedded Controllers (ARM Cortex
M3), i _really_ like them :)  these usually have lots of interfaces
such as RS232, RS485, some of the bigger ones even have Ethernet, CAN
Bus and SD/MMC.

 and, because the cost overall of a system with one of these Embedded
Controllers would be so much lower than using discrete ICs, it makes
sense to use them all the time _but_ that is NOT part of the
EOMA/PCMCIA specification, it is just a practical decision.

 am still looking for good low-cost ECs with good free software
toolchain and libraries, as well as a large existing community built
around them: the CPU used in the Leafpad "Maple" is the one that i
believe best fits these criteria, but i will be very pleased to hear
from people who can find something better.

> In the same spirit, other GPIOS could be defined as dual use for PWMs,
> SPI, whatever.
> As every SOC has these capabilities, why not specify them to be used
> in a standard manner ?

 ok, take a deep breath, let me go through the logic, please tell me
if you disagree

 * we have to keep it simple.  i'm concerned enough about voltage
level interoperability on the GPIOs (bi-directional GPIOs!) as it is
(across a wide range of CPUs)

 * once you specify something in the standard, that's it: _everyone_
has to conform to it.  so, once you say "yes it's ok to have SPI
anywhere on GPIO pins 1 to 16" then you are in deep, deep trouble,
because *all* CPU cards now have to support SPI _possibly_ being
somewhere on all GPIO pins, and _not_ all CPUs support multiplexing
like that, so now you are in trouble.

 * so let's say instead you have to support SPI possibly being on pins
0 to 4, well ok, what about multi-bit SPI, ok let's say it _might_ be
possible to have SPI multi-bit, whoops now you have a problem, plus
whoops, not all CPUs support multiplexing, so now those CPUs have to
have an external *bi-directional* crossbar switch - with tristate
capability and built-in level conversion - to select either SPI or
GPIO - it's all a complete dog's dinner.

 * yes, dual or triple use is part of the standard, so the GPIOs all
have to be tristate-capable, but i don't want to get complicated at
this stage: the main reason for specifying tristate is so that future
CPUs don't blow up older motherboards or vice-versa or both.

 * SPI and UART are serial buses: USB-2 and I2C are multi-device
buses.  multi-device buses have to take precedence, and SPI is quite a
lot of pins (relative to 68, not relative to 200 like on SO-DIMM)

 * if you assume it's ok to have a Cortex M3 Embedded Controller,
talking via USB to the main SoC, then you can have SPI, UART, PWMs
etc. etc. - just only through the Embedded Controller.

 * the advantage of picking a particular Embedded Controller is that
it becomes a kind of standard, for a particular motherboard.  if you
change the main CPU, you *do not* have to go through "ARM Linux Kernel
Hell" re-inventing platform files, and annoying Linus Torvalds and
making Russell King even more depressed.

 * even if you do not have an Embedded Controller, I2C is max of
4mbits/sec, that is surely enough for most purposes, and if not, you
go to USB-2 instead, that is _surely_ enough for all other purposes -
e.g. you can get e.g. a USB2 SD/MMC IC for about $1.50 and _surely_
you can get an I2C-to-RS232 converter IC from somewhere?

 * as absolute last resort, you can do bit-banging of GPIO (i've done
it before!) - RS232 is not hard to do over GPIO, esp. not for an
800mhz or above Cortex A9.

so it's a long story, but it's all-round safer and has several
advantages for software as well as hardware development to just say
"no, it's GPIO, and it's staying as GPIO".

the other possibility is this: there is the zynq-7000 series from
xilinx coming out soon.  this CPU has _massive_ flexibility.  here,
yes we would specify pins for use as RGB/TTL and as GPIO, but who is
to say that _you_ have to stick to that?  absolutely nobody :)

so you can dynamically reconfigure those pins to be anything you want.

i will find more details soon.

l.