Hello.

I working on a design and I was considering to use Intel PXA255 into
it. I have read in RTAI mailing list though that there are some
problems with the architecture (I am not sure if it's ARM architecture
related or PXA255 implementation specific) regarding interrupts: as
interrupt sources are multiplexed, treating them for a system such as
Linux makes developers' lives very difficult. Besides I have found
it's kind of handicapped as it lacks division instructions and its
timer scheme seems too limited (maybe because I did not understand
it).

So I started wondering if I shouldn't switch to another architecture
such as MIPS or PPC while I still can afford it. My main requirements
are I must run Linux/RTAI in it and it must have an LCD controller
that can drive a DSTN LCD in addition to the usual bunch of
peripherals (DMA, timers, serials). Ethernet and USB controllers are
welcome but not essencial. Sou I would appreciate comments on this
issue, links to comparisons between architectures, your own experience
with your architecture of choice if you can provide it and other
pertaining information.

I thank you very much in advance for any help.

Elder.

"Mad@Spammers" <ih8sp4m@yahoo.com> ???
news:ea82e822.0311040612.15a2da70@posting.google.c om ???...
<snip>
I think you can go check out linuxdevice.com, there is a directory for
hardware.
http://www.linuxdevices.com/directory/Hardware/
Hope this can help you

Shih-Ying Chou

Well, yes - ARM really has only two interrupts - IRQ and FIQ. How much of a
problem this is depends on:

1. how intelligently you assign hardware functions to events,
2. how much under-the-covers work you're willing to do, and
3. what you define as a "problem".

Are you expecting numerous nested interrupts, and a need to maintain rigid
levels of interrupt priority beyond "high" and "low"? Are you worried about
latency?

PowerPC is hotter and higher-performance than XScale (and more expensive,
too). There are of course variants which have all your needs in them. There
isn't an obvious showstopping reason, based on what you told us, why I would
say "yes, upgrade!". I would call Linux-on-ARM a very mature product, in
general, with not many functional warts. RTAI, I don't know.

--
-- Lewin A.R.W. Edwards (http://www.zws.com/)
Learn how to develop high-end embedded systems on a tight budget!
http://www.amazon.com/exec/obidos/AS...0676094/zws-20

"Lewin A.R.W. Edwards" <larwe@larwe.com> wrote in message news:<qL6cnfkoLYcPQjqiU-KYhg@broadviewnet.net>...
Latency is always a concern though I can stand latency of 200us or so.
What does worry me is that there is not seem to have a clean solution
for it in Linux (though from reading ARM Linux developers mailing list
archives I learned kernel 2.6 is structured in a way that makes
interrupt issues much easier to deal with.) So the issue is complex
solutions usually lead to complex problems as a consequence. However I
don't know if architectures such Power PC or MIPS do not have similar
problems.

I have seen comments a 100MHz PPC compares to the 200MHz XScale (or
ARMs, not sure).

It seems MPC823E could fit my needs pretty well but it is a fairly old
chip and Motorola's roadmap does not have any hint of a similar in the
future which makes me wonder about how wise would be choosing it on
the long term.

I hope PXA25x support becomes standard in ARM linux patch pretty soon
(rmk patch for 2.4.21 does not have any - and there is no pxa2 patch
for it either) as there is for StrongArm based boards (most
configuration files in ARM arch subtree are for SA).

Thanks and regards.

This is AFAIK also true for PPC external interrupts.

This only means you need a little interrupt scheduler, but there are
also ARM cpus with a real interrupt-controller which emulates vectored

interrupts. I don't know if this is true for the XScale derivates.

But I would guess there are working Xscale versions of Linux at least
I saw one or two products with it.

---
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@epost.de instead !

Argh! What exactly is the "problem"? When you say "a clean solution" it
brings to mind small-mustached computer science lecturers standing on a
podium in the Reichstag, striking the lectern with clawed hands and
shrieking "Thou shalt not GOTO!". This group is about engineering, not
science. A solution does not have to be "clean" to be elegant, functional
and reliable.

Do you have a specific problem that you feel will be worsened by the ARM
core's interrupt system? (Yes, I'll happily accept "I think there might be a
future maintenance/upgrade issue", as long as you can be a bit specific
about it). Or, do you simply have a vague suspicion of kludges unseen
lurking unavoidably in the arm-linux kernel as a result of the ARM interrupt
architecture? If the latter, I'd point out that every mainstream OS is kept
afloat by a raft of such kludges; they're the price of doing business with a
particular hardware architecture.

It depends on the PPC. And the ARM, for that matter. The two popular ARM
cores right now are ARM7 and ARM9, and they have very different performance.
It depends on bus width, memory type, cache availability, ...........

There are shipping Linux-based consumer products with PXA25x's. I would call
it readily available

--
-- Lewin A.R.W. Edwards (http://www.zws.com/)
Learn how to develop high-end embedded systems on a tight budget!
http://www.amazon.com/exec/obidos/AS...0676094/zws-20

42Bastian Schick <bastian42@yahoo.com> wrote:
Yeah, but he is looking at the 823, which can be configured for
non-multiplexed external interrupts. You are thinking of the stand alone
cpus, not the embedded parts.

As for the fear that there won't be a follow-on to the 823, I think it is
safe to believe there WILL be one, but it will be a LOT higher performance
and based around Book E. I could be wrong, of course :-P.

As for the concern about a latency of 200 usec or so, if I was writing my
own real time scheduler and had control over the device drivers, I could
guarantee the ability to nest at least 7 levels deep in that amount of
time on a 200 Mhz or faster 603e (not and get back, of course). Using
Linux, though, a non-real-time scheduler, your mileage WILL vary and you
will never (strong word, but true until you say "within a reasonable level
of confidence) be able to guarantee any particular latency.

And the PowerPC embedded chips.


--
Skipper Smith Helpful Knowledge Consulting
Worldwide Microprocessor Architecture Training
PowerPC, ColdFire, 68K, CPU32 Hardware and Software

/* Remove no-spam. from the reply address to send mail directly */

"Lewin A.R.W. Edwards" <larwe@larwe.com> wrote in message news:<08Odnfkjk8dVkDSiU-KYkg@broadviewnet.net>...
My problem specificaly is that I will have to adapt RTAI/newlxrt to
work with PXA255 as there is not such a port (there is for other ARMs
though including StrongARM) and there seems not to be anyone working
on it. More on that bellow.

KISS comes to my mind. By clean I meant simple. Dirty is usually
dissociated from elegant, functional and reliable in my experience.
Though it seems we have not much choice in Xscale's case.

I see your point and have to agree. As for the problem, there is not
properly a specificaly one, just bad feelings based upon what I have
read in mailing lists, particularly comments in RTAI's one and several
associated bugs to the complexity added by PXA's interrupts operation
mode. I have observed a bug consequence myself (latency escalation
under heavy processing load) which may be related to RTAI's interrupt
managing system.

Part of my discomfort is that Linux is at the present a moving target
as far as PXA25x is concerned. I browsed through ARM Linux development
mailing list archives and learned there won't be a pxa patch for 2.4.x
any time soon. So one must stick either with kernel 2.4.19 or go to
2.6 if wants PXA support *and* bug fixes to several bug fixes ever
since 2.4.19-rmk7-pxa2 was released (assuming somebody will backport
those to 2.4.x). Probably I am unnecessarily suffering by anticipation
as things will eventually stabilize (and maybe the backport will be
done). The question is how long it will take.

Regards.

Elder.

ih8sp4m@yahoo.com (Mad@Spammers) wrote in message
I agree with you that the Motorola commitment to the MPC823E is
minimal, but it is a variant of the MPC850 (pin compatible), the
MPC850 being the entry level member of the MPC8xx family. No doubt
that the long term support for the MPC8xx and MPC850 by Motorola will
be there. For how long can you expect to buy MPC823E parts? No doubt
about the MPC850 parts in this respect.

For user experience with the PPC architecture, look at
http://www.connotech.com (there is self-interest here). About
Linux/RTAI, I don't have experience with it. Perhaps your kernel/RT-OS
requirements are not that significant if you don't require network
connectivity.

- Thierry Moreau

Okay. Well, it sounds like you're at the start of a hardware/software design
project, and having qualms about committing down a particular HW path,
because the potential difficulty of HW/SW integration is shrouded in mist. I
sympathize deeply with that problem.

Having done a _little_ PPC development, and quite a lot of ARM development,
I'd have to say that ARM is considerably easier to understand. So for a
project where I know I'll have to be doing a lot of hand-rolling in assembly
language, I'd be instantly biased towards ARM for that reason only.

Yes, ARM requires some software handling of interrupt priorities [usually].
There's a little overhead there. But it's not onerous.

If there is no compelling reason to use 2.4, I'd lean heavily towards 2.6.
I'm trying to migrate myself, but I'm having trouble with some third-party
drivers that can't be compiled [yet?] - USB peripherals, all of them. Seems
a bunch of definitions were deleted or renamed in the USB handling code, and
2.4 drivers won't build as a result. Apart from that, I am very happy with
2.6 (on x86, anyway).

The complementary question is how long it will be before your hardware is
ready for the "real OS", too

--
-- Lewin A.R.W. Edwards (http://www.zws.com/)
Learn how to develop high-end embedded systems on a tight budget!
http://www.amazon.com/exec/obidos/AS...0676094/zws-20

"Lewin A.R.W. Edwards" <larwe@larwe.com> wrote in message news:<BZWdnfRwY-MJwjeiU-KYiw@broadviewnet.net>...
That's exactly the point.

Thanks. I appreciated it. :-)

That's part of the information I was after.

There's three reasons to use 2.4.x. First is stability: just remember
how long it took for 2.4 series to become stable (only with 2.4.16
IIRC and still there were some minor problems with 2.4.17). I hope 2.6
series follows 2.2 series track which became stable quite fast - IIRC
with 2.2.5. The second reasib is only now RTAI folks is starting to
actively (or should I say agressively) develop for 2.6. They seem to
be as conservative in some ways as my software buddys here (I started
with hardware and do software mostly but still design hardware). The
third reason you just mentioned: drivers.

In not more than three months. Still we have a PXA255 based board here
to start develping software. The reason I originaly posted is that
Intel support here in Brazil has been damned bad (I started with
Motorolas iMX based ADS - and their support was quite opposite to
Intels - unfortunately its LCD controller does not support DSTN
panels) and I started wondering if I shouldn't switch to another
architecture while in early development steps even though it should
delay my schedule. Your postings helped me to make up my mind and I
really appreciated them. As for support, I'm affraid I am on my own
(some corporations definetely are not small companies friendly).
Regarding Linux, I will stick with 2.4.19 and focus on RTAI which will
need some effort to work things out for my application.

Do you have experience with or recommend some JTAG tool aimed at GNU
toolchain?

Again, thanks a lot for your help.

Elder.

Hi,

Argh, what a weekend. Just catching up on my usenet and personal email,
waiting for the sword of Damocles to fall on Monday or Tuesday. Anyhow:

FWIW, I've been in the same situation many times over the years, and thus
far [with appropriate caveats, and YMMV, and other similar disclaimers] my
experience has been that deep research is not generally necessary to
discover the show-stoppers; they're usually discovered in the superficial
research stage. Yes, there are always nagging worries until the project is
actually working. Yes, there are likely to be code snippets that you're
either not proud of, or fiercely proud of (depending on your temperament and
hackishness . But all non-trivial projects are like that.

I don't know how XScale handles it, but Atmel for instance has a
simple-to-use interrupt controller. Since the vector area is at the bottom
of the address space, they exploit reverse address wraparound and put the
VIC at the top of the address space, so all you need to do is jump indirect
with a negative PC offset. The VIC supplies the absolute jump address. In
such cases, the software overhead is really minimal.

If you've got something that's REALLY important to service REALLY quickly,
you should be using FIQ anyway - that's what it's there for.

I have to wonder how much longer these panels are going to be available. I
don't know what size you're using, but these days we only see the larger
sizes (say, 10.4" and up) in the surplus channel. It seems that the major
production driver for panels in this size is monitors and laptops, and the
cost differential between DSTN and TFT is small enough that the passive
panels aren't in heavy demand.

Yeah, tell me about it. But with all the disadvantages, I'd still much
rather work for a small company.

YMMV again (and I say it this time with extra-heavy emphasis) but I use the
Macraigor Wiggler. Some people here have had unpleasant experiences with
Macraigor hardware, and dissatisfaction with their support. There are also
DIY clones of the Wiggler, search on Google for "jtag wiggler" and you're
sure to find schematics. Actually there were some URLs posted here in cae
not too long ago.

Main downside to the Wiggler is that it is only supported under cygwin.
There is a kind of complicated story surrounding that. Anyway, if you need
to work under Linux, the next step up offered by Macraigor is the Raven,
which is an Ethernet-connected device. It's almost an order of magnitude
more expensive, and I haven't used it, but it's probably the cheapest option
available, and it would be top of my list to try if I needed it.

--
-- Lewin A.R.W. Edwards (http://www.zws.com/)
Learn how to develop high-end embedded systems on a tight budget!
http://www.amazon.com/exec/obidos/AS...0676094/zws-20

"Lewin A.R.W. Edwards" <larwe@larwe.com> wrote in message news:<5fmrb.17936$Oo4.15911@newsread1.news.atl.ear thlink.net>...
much less expensive than TFTs. For larger sizes, I don't even know if
there are passives available and anyway I'd use TFT as cost woudn't be
that critical.

Same here. :-)

I think you meant the mpDemon. I've been recommended Abatron's tools
(but the only with GNU support is the BDI-2000 - much more expensive
than mpDemon). Do you know folks that use mpDemon with GNU tools?
Macraigor is not very detailed as far as information on their products
is concerned. Even mpDemon's data sheet does not say much (if there is
much to say).

Thanks for the hints and my best regards

Elder.

And even this can use the same technique to have multiple of them !

---
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@epost.de instead !