A5 vendors

Is that a paper size? There is a lot more to paper than just its size.

--

Rick

I think Don's talking about the ARM Cortex A5.

I've no experience with them myself however.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world

Me neither. Don, you may be a c.a.e pioneer.

Personally, I may have a use for the M7, if it can do double-precision floating point way fast.

--
www.wescottdesign.com

Why specifically A5? Normally you don't want to specify the exact core, but rather the features you need (speed, SIMD, etc.) in the core, and the features you need in the chip itself (size, power, cost, availability, features, packaging, supplier, error rate, etc.). There are lots of criteria in choosing a Cortex-A chip - the exact core is seldom relevant.

Will your application be bare metal Linux hard/soft real time requirements?

I have an Atmel SAMA5D3 board on my desk.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com 
MicroProcessor Engineering Ltd - More Real, Less Time 
133 Hill Lane, Southampton SO15 5AF, England 
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 
web: http://www.mpeforth.com - free VFX Forth downloads

That's what we wanted, too. However, double-precision floats are an option in the M7 profile, and all the M7 devices I have read about are single-precision only.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com 
MicroProcessor Engineering Ltd - More Real, Less Time 
133 Hill Lane, Southampton SO15 5AF, England 
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 
web: http://www.mpeforth.com - free VFX Forth downloads

Assume (roughly) functionality has costs. I.e., pay for *only* what you

*need*.

The above suggests finding the smallest/cheapest/least-performant device that fits other goals.

["Applications" in the following refers to actual uses I have on the bench; not "pie-in-the-sky wish-lists"]

Low power, high level of integration, etc. all stand without saying...

I can live with a 32b machine (but not 16 -- and unwilling to pay for 64)

I can live with a single core -- thus, not willing to pay for big.LITTLE, either.

FPU isn't necessary -- though I can *exploit* (i.e., probably not worth paying for them as I can emulate the required operations in software in the resources available) even single precision in some cases.

DSP/SIMD not necessary -- though I can *exploit* (see above) them in *some* applications.

Support for demand paged MMU (with hardware protection).

Particular I/O's that can be exploited include LCD and camera interfaces (GPIO's, etc. tend to fall out of the equation for most devices -- though extra counter/timers can always find use! At *some* cost)

At least one 100Mb MAC/PHY -- preferably 1588 capable (though I can work around that). A *second* MAC is handy in some applications (ideally also 1588).

Tools can always be acquired to fit *a* need. But, I'm not keen on having to buy/learn N sets of tools for N different solutions (to N different applications).

The MMU requirement rules out all but the A-series, AFAICT (in ARM product offerings -- I'd be willing to look at other vendors/families). The I/O's can be addressed by products in other series, but the MMU is too hard to live without. A5 *seems* to be the low point on the (current) performance/feature curve given the above constraints. (Have I missed something?)

And, hopefully will be around a bit longer than some of the earlier v7 devices. It also seems to have hooks to let me add some of those features as apps are willing to pay for them (e.g., "IP camera" is far more willing to pay for DSP functions than a "weather station")

I don't want to, for example, have to write another version of the RTOS to deal with some other vendor's MMU, a different set of drivers for some other NIC, timers, etc. And, a homogeneous system solution lets me optimize at even lower levels in the design (e.g., data can be implicitly typed as I know the characteristics of the recipient device -- no endian conversions, floating point format conversions, struct packing changes, etc.)

But, with different fabs offering the same, "conceptually", IP, it boils down to which are most "on top of" the designs. I.e., fix/acknowledge problems in the silicon *earliest*, etc.

[No idea what their licensing arrangements with ARM are -- does buying a license to some IP entitle them to all *updates* to that IP? In which case, it's "just" a matter of when they choose to update their fab? OTOH, if IP updates *add* to the costs of fab update, then I suspect they are a lot less anxious to push fixes into production as they might otherwise be!]

Would you have chosen a different point in the A-series family?

"bare metal" in the sense that there is no (C)OTS OS running on it.

No. See above.

Yes.

See my reply to David's post for more specifics. The MMU requirement seems to limit the ARM products to the A-series devices. Though, as I said, there, I'd be willing to look at other (non-ARM) families.

I have proof-of-concept implementations running on x86 SBC's (easiest "development boards" with MMU support to get a hold of "in quantity"). I had originally planned to move many nodes onto dumber "motes" and was targeting the M3 devices for that. But, am now shifting the implementation to push more of the server functionality into the "remotes" -- which means they start to look more like the server than the original (dumb) "motes". Entirely different coding style...

Have you done any (bare-metal) work with it to be able to comment as to how "robust" (reliable? predictable?) the processor's design? And, how "responsive"/cooperative the vendor (Atmel) is to any problems you've encountered? I.e., are they "on your side" or just trying to keep every "sold" product as "SOLD" (at YOUR expense/hassle/grief)?

Crudbuckets. Fortunately I need it for a back-burner personal project, so I can wait.

If I ever get desperate and want to throw a bunch of man-hours at it, I can do the job using fixed-point 64-bit math and a whole bunch of careful scaling -- but it would take rewriting some fairly heavy duty algorithms, and I'd really rather wait.

--
www.wescottdesign.com

[snip]

Hmmm. Bare metal MMU on a Cortex-A series MCU.

Been there, done that (in this case multiple A8 series MCUs). :-)

If the A5 is anything like the A8 then don't assume that MMU settings which work on one A5 MCU will work on another A5 MCU.

I wrote up some of my experiences last year when (as I've just discovered) you were asking about the ARM v7 MMU. Here's a pointer to a website which archives comp.arch.embedded and has the discussion in question:

It might be worthwhile for you to keep my discoveries in mind in case you hit the same issues with the A5 MCUs.

It may also be worthwhile for you to see where you stand with things like cache invalidation on the A5; I was surprised to see options available on traditional MMU capable ARM MCUs retired on the A8.

Warning: I browse with Javascript disabled by default, so I don't know if you are going to get hit by multiple adverts and popups when visiting that URL.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world

Yes, I recall discussing bits of this with you in a previous life. I was wondering if you'd chime in with any "updates"...

Aside from your gripes about TI's policies, would you opine as to which vendors (fabs) to prefer/avoid? I.e., they're all largely making the same *kit*...

Yes, you'd said that in your past experience. Any update as to possible cause?

Yes, I have that discussion saved in my NNTP client.

There are advantages to SMALLER caches! :>

I've got the browser here so tightly clamped that I usually have the opposite problem: sites that "don't work" because I've got turned off, crippled, etc. [SWMBO grumbles about it, from time to time; though nary a week or two goes by without her hearing of one of her friends having a "broken" computer (malware)]

Bare metal and (demand paging) MMU requirements do not make much sense. Are you trying to develop your own RTOS ?

What for do you need that MMU, why not link everything, including processor startup, device drivers and your application into a single big executable file and transfer it somehow to the target processor by inserting SD card or loading electrically (needs permanent boot) code?

Setting up the MMU is often a pain, not to mention any demand paging system. Just run everything in a single linear address space.

RTOS is already written. But, on x86 hardware. AFAICT, there's not a low power, low cost, highly integrated version available.

Single flat address space (no protection domains) leads to less reliable code. It also makes it harder to identify and locate problems (at debug

*and* run-time) E.g., why is the kernel (Linux, BSD, Windows, etc.) given special treatment? Why not link everything in a single address space? Think of how much *simpler* the entire system MIGHT be!

With a paged MMU, the OS has information that isn't available to any other sort of implementation. E.g., who referenced what and when; faster out-of-band comms; information hiding; zero-copy sematics; etc. Exploiting this leads to a different coding style -- one where you concentrate on what you want to *do* instead of the mechanisms by which you do it.

The SAMA5D3x is a Cortex A5, and Atmael say they have bare-metal code for it. This should have double-precision hardware. The EVBs are not expensive.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com 
MicroProcessor Engineering Ltd - More Real, Less Time 
133 Hill Lane, Southampton SO15 5AF, England 
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 
web: http://www.mpeforth.com - free VFX Forth downloads

We haven't started the bare-metal stuff yet, just installed our Linux software.

It's too early to tell how responsive Atmel will be.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com 
MicroProcessor Engineering Ltd - More Real, Less Time 
133 Hill Lane, Southampton SO15 5AF, England 
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 
web: http://www.mpeforth.com - free VFX Forth downloads

In other words, no, you do /not/ specifically need a Cortex A5.

You need a chip with an MMU, reasonable processing power (multiple 100 MHz, but not multi-core, with FPU/SIMD as nice to have), and with at least a 100 Mb MAC. (Requiring an Ethernet PHY will reduce the choice of devices to close to zero.) You don't even require the chip to be an ARM device - it could be PPC or MIPS as alternatives.

Apart from that, you want long-term availability and low cost.

None of that suggests a requirement for a Cortex A5 core.

From my own experience, the only chip of this sort that I have used is a Freescale i.mx6 device, and we've been happy with the devices. These are a very popular range, and at least some of the i.mx6 devices are part of Freescale's long-term availability program. They happen to be Cortex-A9 cores - but that should not matter to you.

The problem with that is as a hobbyist, _my_ priorities are completely different from yours. :-)

For example, while I have absolutely no problem with building my own circuits around smaller PDIP based MCUs, my hardware skills don't extend to building my own boards around the bigger stuff such as the Cortex-A8 range.

As a result, I am only exposed to larger MCUs which are available on hobbyist priced boards, which will be a subset of the options available to you.

Now, having said that, I do like the TI documentation on it's MCUs. Yes, I know the access to sample code sucks, and yes, I got caught with the MMU problem, but the documentation _overall_ is rather good (IMHO).

It's not just the Cortex-A material as well. I've also been looking at the MSP430 documentation (because I'm interested in a closer look in the future) and that documentation "appears" to also be rather good.

For a couple of other examples, the Freescale documentation wasn't as good on the board I looked at (iMX233, which is traditional ARM not Cortex-A) but was generally workable IIRC and the documentation on the Chinese Allwinner Cortex-A jobs was absolutely appalling (when it existed at all :-( ).

On the old SAM7S range, I thought the Atmel documentation was rather good but I've no knowledge of recent Atmel ARM MCUs. Be aware however that Atmel PDFs are now rather stupid sizes (at least for the AVRs) because someone doesn't know how to properly create PDFs.

No. In the end, I just accepted that was the case and moved on.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world

No -- I could *also* use an A15, etc. :> But, if you:

Assume (roughly) functionality has costs. I.e., pay for *only* what you *need*.

Then, buying a device with capabilities beyond your needs increases cost. (Yes, I know the price:performance ratio can be upset by all sorts of factors. But, with *hundreds* of ARM offerings from dozens of fabs, trying to build a comparison matrix of ALL possible choices is a silly effort. And, the resulting decision can be invalidated by the chosen vendor dropping support, altering its pricing strategy, etc.)

Given that ARM claims:

"The ARM Cortex-A5 processor is the smallest, lowest cost and lowest power ARMv7 application processor"

I.e., ARM's positioning for the A5 seems to be *at* the low end of the performance spectrum suggesting they haven't loaded it up with "extra" features that would bias its cost upwards. Assuming it is well received by the market (in the long run), then it seems this positioning would tend to hold and drive price accordingly.

(Of course, if all the volume moves to the high end of the spectrum, then all bets are off. But, such a change could also be a problem for folks trying to acquire inventory and competing with others buying in *huge* lots -- everything "on allocation")

It makes sense (to me) to start *there* -- and not at the opposite end of the spectrum (e.g., A57) and work your way *down*!

Correct. Though note the other I/O's that I *will* require! E.g., if they aren't available from *some* vendor in a particular device family, it means adding external components to provide that functionality (a second MAC). And, adding anything external typically costs you "something" as pins (that would otherwise be used to make certain integrated I/Os available) are freed up to interface with that device.

Didn't say it *had* to be an A5. Rather, from my survey of Cortex A series parts (MMU requirement), the A5 offered enough performance and the right set of possible I/O's (depends on the actual fab to see what they pin out) to address my needs without leaving me paying for unused/unneeded features or capabilities.

They don't have a second MAC available. And, they seem geared towards "display devices" -- tablets, phones, etc. -- with a heavy resource investment (silicon) in providing that support.

The OP wrote 18 paragraphs which you summarized and gave an answer to in just 5 paragraphs. I think you must have compressed out most of his content... or was it really that magniloquent?

--

Rick