RFC: "Comet" board with AT91RM9200

Hello,

we are designing a microcomputer named "Comet" based on the Atmel
AT91RM9200 controller. All design files and software will be licensed
under the GPL.

Currently the schematics is all what we have. We probably packed too much
building blocks into the design. Before we cut down the design and start
building the PCB it would be nice to hear what you think which optional
building blocks should turn to essential. The ESS blocks are  necessary for my
job, the OPT blocks are nice to have, but make my design more complicated.

ESS  AT91RM92000 with PQFP-208 package
ESS  USB host and function interface
ESS  16/32-MByte Flash Memory, 16-bit 
ESS  64-MByte SDRAM, 16-bit
ESS  RTC DS1338
ESS  Twin-CAN Controller 82C900 or Oki ML9620
ESS  CPLD for custom tasks XCR3128XL-12TQ144C (with prototyping area)
ESS  Debug- and Modem-Port (2 x RS-232)
ESS  Single supply voltage 12 to 24 Volt, on-board voltage generation
ESS  CompactFlash Interface in True-IDE mode (for WLAN cards)
ESS  Connectors on Comet: Power, CAN, USB host/device, JTAG, RS-232, Ethernet 
OPT  512K SRAM (to be used instead of SDRAM, e.g. for eCos)
OPT  Serial Atmel Dataflash device, 8 MByte
OPT  Epson graphics controller S1D13706 for QVGA displays
OPT  Interface for simple 20x4 character LCD display 
OPT  PS/2 keyboard and mouse connector UR6HCPS2-SP40
OPT  Audio Codec and Power Amplifier WM9705
OPT  LIN Subbus
OPT  MM/SD/DataFlash-Card Interface
OPT  SmartMedia Interface
OPT  SmartCard Interface

Another design decision which is not yet clear is the type of the expansion
connector. I would like to add two connectors to the bottom of the PCB to
insert Comet into some target system. The connector type ranges from VG64 (64
pins, 2.54 mm) to Hirose/Molex (120 pins, 0.8 mm). What do you think?

Thank you,

Hubert

---

Comet License (GPL)
   http://www.fh-augsburg.de/~hhoegl/proj/comet/COPYING  

Overview
   http://www.fh-augsburg.de/~hhoegl/proj/comet/comet-cs/index.html

Schematics (Protel)
   http://www.fh-augsburg.de/~hhoegl/proj/comet/COMET_SCHEMATIC_V1_02.pdf

Mailing List 
   http://rabbit.informatik.fh-augsburg.de:8080/mailman/listinfo/comet

My Email Address
   Hubert.Hoegl@fh-augsburg.de

On 22 Feb 2004 02:36:51 +0100, Hubert Hoegl <hoegl@pc.com> wrote in
comp.arch.embedded:

A few comments based on putting together a board using this chip, and
some of the others.

> Hello,
> 
> we are designing a microcomputer named "Comet" based on the Atmel
> AT91RM9200 controller. All design files and software will be licensed
> under the GPL.
> 
> Currently the schematics is all what we have. We probably packed too much
> building blocks into the design. Before we cut down the design and start
> building the PCB it would be nice to hear what you think which optional
> building blocks should turn to essential. The ESS blocks are  necessary for my
> job, the OPT blocks are nice to have, but make my design more complicated.
> 
> ESS  AT91RM92000 with PQFP-208 package
> ESS  USB host and function interface
> ESS  16/32-MByte Flash Memory, 16-bit 
> ESS  64-MByte SDRAM, 16-bit

The chip supports 32-bit SDRAM.  Given that the maximum SDRAM bus
speed is only around up to about 60 MHz, using 16-bit SDRAM would make
it a real bottle-neck in the system when it is used.  Why not 32-bit
SDRAM?

> ESS  RTC DS1338
> ESS  Twin-CAN Controller 82C900 or Oki ML9620

A word of advice, stay away from the 82C900.  It is a very broken
piece of crap.  We dumped it after all the problems we had on our
first spin prototype boards.  I would strongly suggest you look at
something else.  Especially if you are planning to use them in SPI
mode.  Some of the things that are broken with this chip have no real
work arounds.

> ESS  CPLD for custom tasks XCR3128XL-12TQ144C (with prototyping area)
> ESS  Debug- and Modem-Port (2 x RS-232)

If you are using the on chip serial ports, they are very lame, no
FIFOs so the processor has to deal with one interrupt for every
character sent and every character received.  TI and others make some
very nice single and dual UARTs with 16 to 64 byte transmit and
receive FIFOs fairly cheap.

> ESS  Single supply voltage 12 to 24 Volt, on-board voltage generation
> ESS  CompactFlash Interface in True-IDE mode (for WLAN cards)
> ESS  Connectors on Comet: Power, CAN, USB host/device, JTAG, RS-232, Ethernet 
> OPT  512K SRAM (to be used instead of SDRAM, e.g. for eCos)
> OPT  Serial Atmel Dataflash device, 8 MByte
> OPT  Epson graphics controller S1D13706 for QVGA displays
> OPT  Interface for simple 20x4 character LCD display 
> OPT  PS/2 keyboard and mouse connector UR6HCPS2-SP40
> OPT  Audio Codec and Power Amplifier WM9705
> OPT  LIN Subbus
> OPT  MM/SD/DataFlash-Card Interface
> OPT  SmartMedia Interface
> OPT  SmartCard Interface
> 
> Another design decision which is not yet clear is the type of the expansion
> connector. I would like to add two connectors to the bottom of the PCB to
> insert Comet into some target system. The connector type ranges from VG64 (64
> pins, 2.54 mm) to Hirose/Molex (120 pins, 0.8 mm). What do you think?
> 
> Thank you,
> 
> Hubert

How much is the board going to sell for?

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

["Followup-To:" header set to comp.arch.embedded.]
On 2004-02-22, Jack Klein <jackklein@spamcop.net> wrote:
> On 22 Feb 2004 02:36:51 +0100, Hubert Hoegl <hoegl@pc.com> wrote in
> comp.arch.embedded:
>> ESS  Debug- and Modem-Port (2 x RS-232)
>
> If you are using the on chip serial ports, they are very lame, no
> FIFOs so the processor has to deal with one interrupt for every
> character sent and every character received.  TI and others make some
> very nice single and dual UARTs with 16 to 64 byte transmit and
> receive FIFOs fairly cheap.

How about the PDC - is that no good?  We were going to rely on the internal
UARTs, but if they're that bad (ie. if PDC doesn't help), we may be thinking
of using a wrong chip.

  -jm

["Followup-To:" header set to comp.arch.embedded.]
On 2004-02-22, Hubert Hoegl <hoegl@pc.com> wrote:
> ESS  CompactFlash Interface in True-IDE mode (for WLAN cards)

You'll need to support I/O and memory mode for WLAN.  True IDE is for
FLASH cards only.

  -jm

<snip>
> If you are using the on chip serial ports, they are very lame, no
> FIFOs so the processor has to deal with one interrupt for every
> character sent and every character received.  TI and others make some
> very nice single and dual UARTs with 16 to 64 byte transmit and
> receive FIFOs fairly cheap.
>
<snip>

This section of the 9200 data sheet:

"The USART supports the connection to the Peripheral Data Controller, which
enables data
transfers to the transmitter and from the receiver.  The PDC provides chained
buffer management
without any intervention of the processor."
Seems to indicate the UART takes some load off of the processor?  I haven't
studied this in detail, but I just remember reading this section.

"Jack Klein" <jackklein@spamcop.net> wrote in message
news:gfig305ocve5gu2ol1ljb63pd812444tfo@4ax.com...
> On 22 Feb 2004 02:36:51 +0100, Hubert Hoegl <hoegl@pc.com> wrote in
> comp.arch.embedded:

snip

>
> > ESS  RTC DS1338
> > ESS  Twin-CAN Controller 82C900 or Oki ML9620
>
> A word of advice, stay away from the 82C900.  It is a very broken
> piece of crap.  We dumped it after all the problems we had on our
> first spin prototype boards.  I would strongly suggest you look at
> something else.  Especially if you are planning to use them in SPI
> mode.  Some of the things that are broken with this chip have no real
> work arounds.
>

Can you give any more details on the problems, I have a project that is
using this - hardware is already defined but I need to get it working.

I haven't been able to find any Errata information on the website so if
you have any url's to them that would be much appreciated.

Stan Katz

"Hubert Hoegl" <hoegl@pc.com> skrev i meddelandet
news:87ad3b7v4c.fsf@pc.com...
> Hello,
>
> we are designing a microcomputer named "Comet" based on the Atmel
> AT91RM9200 controller. All design files and software will be licensed
> under the GPL.
>
> Currently the schematics is all what we have. We probably packed too much
> building blocks into the design. Before we cut down the design and start
> building the PCB it would be nice to hear what you think which optional
> building blocks should turn to essential. The ESS blocks are  necessary
for my
> job, the OPT blocks are nice to have, but make my design more complicated.
>
> ESS  AT91RM92000 with PQFP-208 package
> ESS  USB host and function interface
> ESS  16/32-MByte Flash Memory, 16-bit
> ESS  64-MByte SDRAM, 16-bit
> ESS  RTC DS1338
> ESS  Twin-CAN Controller 82C900 or Oki ML9620
> ESS  CPLD for custom tasks XCR3128XL-12TQ144C (with prototyping area)
> ESS  Debug- and Modem-Port (2 x RS-232)
> ESS  Single supply voltage 12 to 24 Volt, on-board voltage generation
> ESS  CompactFlash Interface in True-IDE mode (for WLAN cards)
> ESS  Connectors on Comet: Power, CAN, USB host/device, JTAG, RS-232,
Ethernet
> OPT  512K SRAM (to be used instead of SDRAM, e.g. for eCos)
> OPT  Serial Atmel Dataflash device, 8 MByte
> OPT  Epson graphics controller S1D13706 for QVGA displays
> OPT  Interface for simple 20x4 character LCD display
> OPT  PS/2 keyboard and mouse connector UR6HCPS2-SP40
> OPT  Audio Codec and Power Amplifier WM9705
> OPT  LIN Subbus
> OPT  MM/SD/DataFlash-Card Interface
> OPT  SmartMedia Interface
> OPT  SmartCard Interface
>
> Another design decision which is not yet clear is the type of the
expansion
> connector. I would like to add two connectors to the bottom of the PCB to
> insert Comet into some target system. The connector type ranges from VG64
(64
> pins, 2.54 mm) to Hirose/Molex (120 pins, 0.8 mm). What do you think?
>
> Thank you,
>
> Hubert


I think you 'd be better of skipping the PS/2 connector and adding a USB Hub
for 5 USB Host ports.
Not so sure that the SSC will work with AC97, you might want to use I2S.


-- 
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB

> > ESS  CPLD for custom tasks XCR3128XL-12TQ144C (with prototyping area)
> > ESS  Debug- and Modem-Port (2 x RS-232)
>
> If you are using the on chip serial ports, they are very lame, no
> FIFOs so the processor has to deal with one interrupt for every
> character sent and every character received.  TI and others make some
> very nice single and dual UARTs with 16 to 64 byte transmit and
> receive FIFOs fairly cheap.
>


Thats why they have the PDC (Peripheral Data Controller).


-- 
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB

On Sun, 22 Feb 2004 17:59:04 GMT, "Stan Katz" <stan@ctc-control.com>
wrote in comp.arch.embedded:

> 
> "Jack Klein" <jackklein@spamcop.net> wrote in message
> news:gfig305ocve5gu2ol1ljb63pd812444tfo@4ax.com...
> > On 22 Feb 2004 02:36:51 +0100, Hubert Hoegl <hoegl@pc.com> wrote in
> > comp.arch.embedded:
> 
> snip
> 
> >
> > > ESS  RTC DS1338
> > > ESS  Twin-CAN Controller 82C900 or Oki ML9620
> >
> > A word of advice, stay away from the 82C900.  It is a very broken
> > piece of crap.  We dumped it after all the problems we had on our
> > first spin prototype boards.  I would strongly suggest you look at
> > something else.  Especially if you are planning to use them in SPI
> > mode.  Some of the things that are broken with this chip have no real
> > work arounds.
> >
> 
> Can you give any more details on the problems, I have a project that is
> using this - hardware is already defined but I need to get it working.
> 
> I haven't been able to find any Errata information on the website so if
> you have any url's to them that would be much appreciated.
> 
> Stan Katz

OK, but I need to point out a few things first.  I'm posting from home
on a weekend, not from work where the project is.  This applies to
using the Infineon part over SPI.  And finally I am not the one who
had to write the drivers to get the part working, do I really can't be
very specific because I just don't remember the exact details.

As usually happens, our first spin prototype board had various
problems.  When they had difficulty getting this part of the design to
work, we were not sure whether it was a hardware of software problem.
When we learned that the Cogent board used the same CAN ship, and also
connected over SPI, we bought one so our guys could see if the problem
was their code or our board.

It turned out that they had connected one pin on the part differently
than we did, something you could not see a reason for from the
Infineon data sheet.  Sorry I don't remember what pin it was.

We made some changes on our board and eventually got it working to a
certain extent, but there are some things about the chip that are
strange.  There is some sort of state machine involved in the SPI
interface that even resetting the chip would resolve.  Only removing
and reapplying power can clear it up if it gets out of synch.

As I said, we have gotten out first spin prototypes working with the
part, but we decided to change to a different part on the second spin.
This was not only because of the issues with 82C900 but also because
the system specifications had changed.  Our internal CAN network, with
the ARM board is the master, got larger and had much more traffic one.

Initially you would think it would not be a problem to manage two or
three separate CAN channels at 500 Kbit/sec over a 6 Mbit/Sec SPI
interface, but you end up with the processor seeing multiple
interrupts for each packet in both directions.  We changed to a
controller with an 8-bit parallel data bus interface.  If I remember
correctly, the new part is by Philips.

I will refresh my memory at work tomorrow and try to post more detail
Monday night.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

On Sun, 22 Feb 2004 20:06:13 +0100, "Ulf Samuelsson"
<ulf@atmel.nospam.com> wrote in comp.arch.embedded:

> 
> > > ESS  CPLD for custom tasks XCR3128XL-12TQ144C (with prototyping area)
> > > ESS  Debug- and Modem-Port (2 x RS-232)
> >
> > If you are using the on chip serial ports, they are very lame, no
> > FIFOs so the processor has to deal with one interrupt for every
> > character sent and every character received.  TI and others make some
> > very nice single and dual UARTs with 16 to 64 byte transmit and
> > receive FIFOs fairly cheap.
> >
> 
> 
> Thats why they have the PDC (Peripheral Data Controller).

Ulf, I did not mean to make it sound so insulting, we are actually
quite happy with the part.  Maybe the PDC would have done the job as
well but we didn't look into it too much for a few reasons.

First was the fact that in the end we needed to provide six serial
ports.  Second, our manufacturing people wanted us to avoid BGA
packages, so we using the QFP and couldn't spare the pins for the
serial ports anyway.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html