Henrik Johnsson <henrik.johnsson@emw.ericsson.se> wrote in
news:ch6bj6$t94$1@newstree.wise.edt.ericsson.se: 

>>> I had a moment and took a quick look.  This doesn't scare me that
>>> much. I've implemented FPGA-based SDRAM controllers from scratch.  I
>>> can see the value in the flexibility offered, despite the complexity
>>> it adds.  I can also see how some embedded guys could be horrified at
>>> the prospect of dealing with the UPM.
>> 
>> Oh, it's not that, it's just that twiddling some signals on half-clock
>> boundaries and others on quarter clock boundaries with the RAM words in
>> a table listed top to bottom with time running down from top to bottom
>> WRT to cycles gets complicated. The documentation is not overly clear,
>> nor does the UPM diagramming tool seem to help (me at least) I spent a
>> solid day getting the single beat read and write cycles to work (from
>> scratch because I wanted to learn the UPM) and then wasted a week on
>> the burst cycles. I finally gave up and used an app. note. When booting
>> the 405GPr for the first time about 2 years later, I wrote a few simple
>> bits to a couple of registers and I was done in about an hour of
>> tweaking. 
>> 
> 
> The UPM can be quite a pest, but Freescale has an "UPM Programming
> Tool" that can be downloaded. I haven't tested it myself, but I assume 
> it can at least help in getting things up and running a bit faster.

The version I used was less helpful than just reading the data book.

-- 
- Mark ->
--

Mark A. Odell <odellmark@hotmail.com> wrote:
> "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in
> news:a4oZc.14534$Hz7.4772@newssvr29.news.prodigy.com: 
> 
>>> Read well the UPM documentation before committing to the 8xx.
>> 
>> I had a moment and took a quick look.  This doesn't scare me that much.
>> I've implemented FPGA-based SDRAM controllers from scratch.  I can see
>> the value in the flexibility offered, despite the complexity it adds.  I
>> can also see how some embedded guys could be horrified at the prospect
>> of dealing with the UPM.
> 
> Oh, it's not that, it's just that twiddling some signals on half-clock
> boundaries and others on quarter clock boundaries with the RAM words in a
> table listed top to bottom with time running down from top to bottom WRT
> to cycles gets complicated. The documentation is not overly clear, nor
> does the UPM diagramming tool seem to help (me at least) I spent a solid
> day getting the single beat read and write cycles to work (from scratch
> because I wanted to learn the UPM) and then wasted a week on the burst
> cycles. I finally gave up and used an app. note. When booting the 405GPr
> for the first time about 2 years later, I wrote a few simple bits to a
> couple of registers and I was done in about an hour of tweaking. 
> 

The UPM can be quite a pest, but Freescale has an "UPM Programming
Tool" that can be downloaded. I haven't tested it myself, but I assume 
it can at least help in getting things up and running a bit faster.

/Henrik

-- 

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in
news:a4oZc.14534$Hz7.4772@newssvr29.news.prodigy.com: 

>> Read well the UPM documentation before committing to the 8xx.
> 
> I had a moment and took a quick look.  This doesn't scare me that much.
> I've implemented FPGA-based SDRAM controllers from scratch.  I can see
> the value in the flexibility offered, despite the complexity it adds.  I
> can also see how some embedded guys could be horrified at the prospect
> of dealing with the UPM.

Oh, it's not that, it's just that twiddling some signals on half-clock
boundaries and others on quarter clock boundaries with the RAM words in a
table listed top to bottom with time running down from top to bottom WRT
to cycles gets complicated. The documentation is not overly clear, nor
does the UPM diagramming tool seem to help (me at least) I spent a solid
day getting the single beat read and write cycles to work (from scratch
because I wanted to learn the UPM) and then wasted a week on the burst
cycles. I finally gave up and used an app. note. When booting the 405GPr
for the first time about 2 years later, I wrote a few simple bits to a
couple of registers and I was done in about an hour of tweaking. 

> I'll have to dig further, at this point in time I am not to bothered by
> UPM. 

Fair enough.

-- 
- Mark ->
--

> Read well the UPM documentation before committing to the 8xx.

I had a moment and took a quick look.  This doesn't scare me that much.
I've implemented FPGA-based SDRAM controllers from scratch.  I can see the
value in the flexibility offered, despite the complexity it adds.  I can
also see how some embedded guys could be horrified at the prospect of
dealing with the UPM.

I'll have to dig further, at this point in time I am not to bothered by UPM.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"

> If you choose the 870 you will soon join the UPM haters club
> when attempting to use SDRAM. Unlike the MPC8xx family, the PPC4xx family
> (which can also run Linux) has a *real* SDRAM controller, set a couple of
> bits and say "go" - done. Read well the UPM documentation before
> committing to the 8xx.

This is something of concern.  I don't have time for complications.  I'll
read the UPM docs and comment.

Thanks,


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:<xIUYc.13941$862.1578@newssvr29.news.prodigy.com>...
> I've been considering the idea of adopting the Freescale (a.k.a. Motorola)
> MPC870 processor for a board requiring ethernet, serial, USB (host and
> device), I2C and SPI connectivity, among other things.  The processor would
> run FPGA-based signal processing hardware on the same board, handle
> configuration, firmware uploading and remote control/monitoring functions.

I can only agree that the MPC8xx processor family is a good fit. I
suppose you can put the other comments about SDRAM interfacing into
perspective (i.e. it should be doable).

> One of the interesting things about this family of processors is that, I am
> told, they will run a version of Linux.  This, to me, means that a huge body
> of work is already done and one can concentrate on application-specific
> code.

Well, beware that Linux personalization to your system design can lead
to project cost and delays. You might consider other kernels with
real-time characteristics. There are a number of them, including eCos
and the ABCD Proto-Kernel (on my web site), and a nomber of non open
source alternatives.
 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: thierry.moreau@connotech.com

On Tue, 31 Aug 2004 06:15:57 GMT, "Martin Euredjian"
<0_0_0_0_@pacbell.net> wrote in comp.arch.embedded:

> I've been considering the idea of adopting the Freescale (a.k.a. Motorola)
> MPC870 processor for a board requiring ethernet, serial, USB (host and
> device), I2C and SPI connectivity, among other things.  The processor would
> run FPGA-based signal processing hardware on the same board, handle
> configuration, firmware uploading and remote control/monitoring functions.
> 
> One of the interesting things about this family of processors is that, I am
> told, they will run a version of Linux.  This, to me, means that a huge body
> of work is already done and one can concentrate on application-specific
> code.
> 
> The current version of the board has a Cygnal (whatever they are called now)
> 8051 high-speed derivative.  Implementing sophisticated connectivity is
> rather painful using this device.  Here hardware cost is not as important as
> development speed and the ability to work at a higher level of abstraction.
> 
> I'm looking for opinon as to the capabilities of these Freescale processors
> and, perhaps, suggestions for other devices I should be looking at.
> 
> Thanks,

Atmel's AT91RM9200 is an ARM 920T with MMU so it can run regular
Linux.  In fact, I think Atmel has, or had, a distro you can download
from their web site.

Among the on-chip peripherals are both USB 1.1 host and USB 1.1
device, SPI and I2C.  Plus SDRAM, Compact Flash, regular flash, and
others.  Last I looked, some 32-bit micros had USB host on chip, but
not many have USB device.

It might fit well if you need USB 1.1.  If you need USB 2.0, you will
probably need to go to external USB chips.

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

Mark A. Odell <odellmark@hotmail.com> wrote:
> 
> Not for nothing, but I found the IBM (now AMCC) 405GPr to be *far* easier
> to bring up. If you choose the 870 you will soon join the UPM haters club
> when attempting to use SDRAM. Unlike the MPC8xx family, the PPC4xx family
> (which can also run Linux) has a *real* SDRAM controller, set a couple of
> bits and say "go" - done. Read well the UPM documentation before
> committing to the 8xx. 

*READ* the Motorola documentation for any 5xx or 8xx? 

Shudder.

The MPC555 and MPC56x have been by far the worst-documented
microcontrollers I've ever encountered. Sure, there are aspects of the
system architecture that are complex, but does the documentation need to
refer to the same thing by three different terms? Does it need to change
notational conventions almost on a chapter by chapter basis?

Motorola documentation was superb on the HC08/11/12 line and on the
68k/CPU32s. Quite how it all went so brown and sloppy on the MPCs I
don't know...

pete
-- 
pete@fenelon.com "there's no room for enigmas in built-up areas"

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in
news:xIUYc.13941$862.1578@newssvr29.news.prodigy.com: 

> I've been considering the idea of adopting the Freescale (a.k.a.
> Motorola) MPC870 processor for a board requiring ethernet, serial, USB
> (host and device), I2C and SPI connectivity, among other things.  The
> processor would run FPGA-based signal processing hardware on the same
> board, handle configuration, firmware uploading and remote
> control/monitoring functions.

Not for nothing, but I found the IBM (now AMCC) 405GPr to be *far* easier
to bring up. If you choose the 870 you will soon join the UPM haters club
when attempting to use SDRAM. Unlike the MPC8xx family, the PPC4xx family
(which can also run Linux) has a *real* SDRAM controller, set a couple of
bits and say "go" - done. Read well the UPM documentation before
committing to the 8xx. 

-- 
- Mark ->
--

Paul E. Bennett <peb@amleth.demon.co.uk> wrote:
: Martin Euredjian wrote:
: 
:> I've been considering the idea of adopting the Freescale (a.k.a. Motorola)
:> MPC870 processor for a board requiring ethernet, serial, USB (host and

[SNIP]

:> One of the interesting things about this family of processors is that, I
:> am told, they will run a version of Linux.  This, to me, means that a huge

It's within the official CVS.

:> I'm looking for opinon as to the capabilities of these Freescale
:> processors and, perhaps, suggestions for other devices I should be looking

Main competitior is, of cause, ARM7/ARM9.
Faster ARMs compete against MPC82xx/PPC44x series PowerPCs. 

MPC8xx are mature, solid chips with a nice architecture. Though they will
work well for general purposes, it is in serial communication (20Mb/s HDLC)
its' dual core (PPC+CPM) architecture will excel. For full speed 100Base-T
you should aim at the 100MHz++ versions.

: As this is a Power PCX chip you may find that you can implement IEE1275 
: "Open Firmware" on the base level machine then run FreeBSD or a Unix on top 

There is no Open Source "Open Firmware" project. At least not for PPC8yxx.
Open Firmware is a desktop issue. Use the U-Boot boot loader instead:

    http://www.denx.de/e/index1.php
    http://www.penguinppc.org/

-- 
  ******************************************************
  Never ever underestimate the power of human stupidity.
  -Robert Anson Heinlein

		GeirFRS@INVALID.and.so.forth
  ******************************************************