1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

RFC: "Comet" board with AT91RM9200

Discussion in 'Embedded' started by Hubert Hoegl, Feb 22, 2004.

  1. Hubert Hoegl

    Hubert Hoegl Guest

    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, Feb 22, 2004
    #1
    1. Advertisements

  2. Hubert Hoegl

    Jack Klein Guest

    comp.arch.embedded:

    A few comments based on putting together a board using this chip, and
    some of the others.
    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?
    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.
    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 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
     
    Jack Klein, Feb 22, 2004
    #2
    1. Advertisements

  3. Hubert Hoegl

    Jukka Marin Guest

    ["Followup-To:" header set to comp.arch.embedded.]
    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
     
    Jukka Marin, Feb 22, 2004
    #3
  4. Hubert Hoegl

    Jukka Marin Guest

    ["Followup-To:" header set to comp.arch.embedded.]
    You'll need to support I/O and memory mode for WLAN. True IDE is for
    FLASH cards only.

    -jm
     
    Jukka Marin, Feb 22, 2004
    #4
  5. Hubert Hoegl

    rick Guest

    <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.
     
    rick, Feb 22, 2004
    #5
  6. Hubert Hoegl

    Stan Katz Guest

    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
     
    Stan Katz, Feb 22, 2004
    #6

  7. 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.
     
    Ulf Samuelsson, Feb 22, 2004
    #7

  8. Thats why they have the PDC (Peripheral Data Controller).
     
    Ulf Samuelsson, Feb 22, 2004
    #8
  9. Hubert Hoegl

    Jack Klein Guest

    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
     
    Jack Klein, Feb 22, 2004
    #9
  10. Hubert Hoegl

    Jack Klein Guest

    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
     
    Jack Klein, Feb 22, 2004
    #10
  11. Hubert Hoegl

    Stan Katz Guest

    Thanks, I had heard about the SPI state machine problem, I'm definitely
    interested
    in any more detail you can add - I'm the one who has to get this thing
    working and
    I probably need all the help I can get.

    Stan
     
    Stan Katz, Feb 23, 2004
    #11
  12. Hubert Hoegl

    Hubert Hoegl Guest

    You are right, this would be a serious bottleneck. I will check the
    Micron MT48LC8M32B2 (8M x 32).
    You may be right. As an alternative to the 82C900 I consider to use
    the new ML9620
    (http://www.okisemi.com/jp/datadocs/doc-eng/ml9620.pdf).
    It has only one CAN interface, but that is not a problem for me.
    Who has any experiences with this device?
    Good idea, I've never considered this. Currently I will use the UARTs
    only for debugging and console i/o. Maybe in the future I will add
    IrDA datacommunication and a LIN interface. For LIN I first have to
    check whether the UART is capable to do the necessary timing. If it is
    not capable to do that, an external UART would be indeed the right choice.
    I don't know what the board will cost. We currently have no plans to
    sell the board. I hope that it will be cheaper than the commercial
    boards: The Cogent CSB337 costs about 400 USD and the Atmel
    AT91RM9200-DK ist even more expensive. I don't know the price for the
    third board, the ARM9-LOM
    http://www.dailzh.net/MyHtml/lom_arm9_project.htm. The costs will
    mainly be determined by the PCB and by manufacturing (soldering)
    costs. My funding includes schematics, PCB design, some prototypes (8
    pieces) and testing. I hope that we finally arrive at working
    prototypes somewhere in 2005. "We" is a freelancer and me, both working
    parttime on the project. Due to the GPL license I hope that other
    people out there find this project interesting. I could image that
    somebody wants a Comet prototype to help testing or some manufacturing
    company wants to build a pile of boards (probably I am far too
    optimistic).

    Hubert Hoegl
    E-mail:
    Home: http://www.fh-augsburg.de/~hhoegl/
     
    Hubert Hoegl, Feb 23, 2004
    #12
  13. Hi Hubert,
    Very nice work so far,
    You could also consider for the audio part of your design the hardware
    mp3 decoder from vlsi. Check www.vlsi.fi .

    Regards,

    Viron Papadopoulos.
     
    Viron Papadopoulos, Feb 24, 2004
    #13
  14. Hubert Hoegl

    Jack Klein Guest

    I know I said I would follow-up on this yesterday, but the guy I
    needed to talk to at work took Monday off, go figure.

    Here are the issues that we had with the 82C900:

    1. First, even though the RDY pin is a pure output, we could not get
    the part to work at all at first. We noticed on the Cogent board that
    they had a pull-up resistor on this pin, and once we added one to ours
    it started to work.

    2. You need to be very, very careful about any noise at all on the
    SPI clock line. It appears that the SPI 8-bit state machine on this
    part works even when it is not selected. For example, if you put two
    clock pulses into the part when it is not selected, then select it and
    start putting in more pulses, the RDY output changes state after six
    selected clocks. The two clocks it saw when not selected are counted.

    3. To go beyond a certain bit rate on the SPI interface, you need to
    use the RDY pin which is non-standard for SPI of course. My co-worker
    managed to maximize the communication rate after quite a bit of
    experimenting due to the great flexibility of the AT91RM9200's SPI
    peripheral.

    If you pull up the RDY pin and are careful with your SPI clock, the
    part is usable for relatively light duty. There is a lot of overhead,
    that is you get an interrupt from the controller, then you have to
    exchange an SPI packet (another interrupt) to determine that you can
    read a packet (another SPI transfer and interrupt) or can send a new
    packet (two SPI transfers and interrupts).

    We need to be able to handle several thousand packets per second total
    over multiple CAN channels with the ARM as the central controller, and
    overall we saw more overhead than we liked doing this with the two
    82C900's we had on the board. So we switched to three single
    controllers with 8-bit data bus interface, which takes much less
    processor effort. As an added bonus, the parallel controllers are 3.3
    volt so that reduces the 3.3/5 volt interfacing issues with the
    AT91RM9200.

    I don't want to sound overly negative about the part, if you take
    proper care of hardware issues 1 and 2, the part does work. We have
    CAN communications working with our first spin boards, although not at
    nearly the full level of traffic yet. So it might very well work in
    many applications.

    It is just that for our level of traffic, CAN via SPI was not one of
    the best ideas I (yes, I was the one who picked the Infineon chip in
    the first place) ever had.

    [cc to Stan and Hubert]

    --
    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
     
    Jack Klein, Feb 25, 2004
    #14
  15. Hubert Hoegl

    Jack Klein Guest

    [snip]

    I was probably too harsh in my comments about the 82C900, sorry, as I
    said I was posting from memory over the week end. See my separate
    post with follow up detail. Mostly because of the packet rate we need
    to support over multiple channels at the same time, we have switched
    to the OKI ML9620.

    My coworker, who wrote the drivers for the 82C900 and then wrote new
    ones for the ML9620 is quite pleased with the OKI part. We are using
    it at 500 kbps with extended frames and it works exactly as the data
    sheet specifies for us.

    --
    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
     
    Jack Klein, Feb 25, 2004
    #15
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.