On 23 Feb 2004 17:42:17 +0100, Hubert Hoegl <hoegl@fh-augsburg.de>
wrote in comp.sys.arm:

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

	[snip]

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

    [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

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
> 

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

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.


Hubert Hoegl <hoegl@pc.com> wrote in message news:<87ad3b7v4c.fsf@pc.com>...
> Hello,
> ....
> OPT  Audio Codec and Power Amplifier WM9705
> ....

Jack Klein <jackklein@spamcop.net> writes:

> 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?

You are right, this would be a serious bottleneck. I will check the 
Micron MT48LC8M32B2 (8M x 32).

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

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?

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

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.

> > 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?

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: Hubert.Hoegl@fh-augsburg.de
Home: http://www.fh-augsburg.de/~hhoegl/

> -- 
> 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" <jackklein@spamcop.net> wrote in message
news:p11i30t0h7th0mc6o739fomjv92rvkfl5j@4ax.com...
> On Sun, 22 Feb 2004 17:59:04 GMT, "Stan Katz" <stan@ctc-control.com>
> wrote in comp.arch.embedded:
snip

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

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

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

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

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


"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