32 bit architecture advice (ARM, PPC etc.)

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.

Reply to
ih8sp4m
Loading thread data ...

"Mad@Spammers" ??? news: snipped-for-privacy@posting.google.com ???...

I think you can go check out linuxdevice.com, there is a directory for hardware.

formatting link
Hope this can help you

Shih-Ying Chou

Reply to
Steve 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

formatting link
Learn how to develop high-end embedded systems on a tight budget!
formatting link

Reply to
Lewin A.R.W. Edwards

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.

Reply to
ih8sp4m

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 :-)
 Click to see the full signature
Reply to
42Bastian Schick

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.

expensive,

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

formatting link
Learn how to develop high-end embedded systems on a tight budget!
formatting link

Reply to
Lewin A.R.W. Edwards

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
 Click to see the full signature
Reply to
Skipper Smith

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.

Reply to
ih8sp4m

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

formatting link
(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

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

formatting link
Learn how to develop high-end embedded systems on a tight budget!
formatting link

Reply to
Lewin A.R.W. Edwards

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.

Reply to
ih8sp4m

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:

mist. I

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.

[usually].

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

formatting link
Learn how to develop high-end embedded systems on a tight budget!
formatting link

Reply to
Lewin A.R.W. Edwards

I'm going to use 7.4" mono (and colour, eventually.) by Nanya. Still 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.

Reply to
ih8sp4m

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 :-)
 Click to see the full signature
Reply to
42Bastian Schick

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.