EmbeddedRelated.com
Forums

RFC: "Comet" board with AT91RM9200

Started by Unknown February 21, 2004
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