RFC: "Comet" board with AT91RM9200

On 22 Feb 2004 02:36:51 +0100, Hubert Hoegl wrote in 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

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

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

-jm

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.

snip

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" skrev i meddelandet news: snipped-for-privacy@pc.com...

for my

Ethernet

expansion

(64

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

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" wrote in comp.arch.embedded:

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" wrote in comp.arch.embedded:

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

snip

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

my

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

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.

Ethernet

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

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: snipped-for-privacy@fh-augsburg.de Home:

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

.

Regards,

Viron Papadopoulos.

On Sun, 22 Feb 2004 17:59:04 GMT, "Stan Katz" wrote in comp.arch.embedded:

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.

1. 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.

2. 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

On 23 Feb 2004 17:42:17 +0100, Hubert Hoegl wrote in comp.sys.arm:

[snip]

[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