[Arm-netbook] UART

[Baybal Ni]

Zync will likely be an overkill. What is its price?

Are we looking for 32 bit mcu? PIC32 was long time on my mind, but
it's MIPS core based. This is not bad by itself, but we may be ending
providing support for two architectures at once if we will go with arm
for CPU. It has open toolchain. It also have extensive IO and its
price shouldn't be bigger than a buck in minimal configuration.

STM32, dont know much about it.

Freescale has quite functional and performant M3 based Kinetis MCUs.
Its downside is packaging. It comes in 200+ pins configurations.

There are also atmel 32bit cortex based mcu. Their biggest plus is
that new arduino is based around them.

On 26 September 2011 17:09, Luke Kenneth Casson Leighton
<luke.leighton at gmail.com> wrote:
> 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.
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk