A5 vendors

Understandable.

I would gladly trade code samples (away) for complete and ACCURATE documentation. Too often, I've found bugs in published software/hardware "samples"... i.e., good to convey a general *concept* but often not addressing important details or -- *gasp* -- bugs in the silicon!

My design philosophy relies heavily on *specification*. Tell me how the devices (hardware/software/tools) that I am using will (!!!) behave and I can design accordingly. *I* can evaluate the cost of workarounds for KNOWN bugs and see if it still makes sense to use a particular component. Or not.

But, my process doesn't well tolerate "surprises". Esp if those surprises are in key areas of the design (like the VM system!). E.g., I can tolerate an I2C i/f only delivering 14b of data reliably to an audio D/AC. But, if it "randomly" decides WHICH 14b to deliver correctly, then that i/f is effectively useless to me.

Colleagues have expressed "qualification" in their comments on TI devices in the (recent) past. I.e., bugs tend *not* to get fixed so pray everything "broken" is documented as such.

I suspect a cultural issue. I noticed when doing custom buys from Japanese firms there was a different bias in how they approached the problem:

*We'd* want to know what they could *do* (affordably) while they wanted to know what we *wanted*. Left us wondering how we'd be able to decide if we were getting good value as their capabilities would be masked by the specifications we placed on the deliverables ("Yup! Everything meets the spec! But, who knows how much select-at-test happened to cull these from their production lot: 1%? 99%??")

Yes. But, aside from the cost to download, I think you can rebuild the PDF's and shrink them accordingly. I've not looked at their internals to see

*why* they are so large (not an issue for me)

Fair 'nough.

Reply to
Don Y
Loading thread data ...

Is this your *own* port? Or, something from the Linux4SAM group? (presumably, the latter would have a more conservative implementation as they have to address *all* devices in the family)

And Ulf seems to have gone missing...

Good luck with your effort! I'd be interested in any "surprises" you encounter -- hopefully none "spectacular"!

Reply to
Don Y

Is this an *Atmel* sourced board (i.e., "Xplained")? Or, third party?

Which D3 device is populated? (e.g., the Xplained has a D36; I would target the D31 and D35 -- unless the D36 cost premium was insignficant)

I may opt to port *just* my VM system and see what sorts of issues arise -- and, how Atmel responds to those -- before taking the plunge and formally embracing the device.

Reply to
Don Y

You know as well as I do that this is only the theory - so many things influence the cost of a SoC that the exact core type is a minor issue, and it will often be overwhelmed by other factors. Statistically, there is probably a higher chance that the ideal chip for your use is an A5 - but only statistically. Your original post made A5 seem the most important requirement, when that is clearly not the case - once that is dropped, all your other questions and concerns make sense.

What does your favourite distributor recommend? If I were in your situation, that is the first person I would ask - they are the people who will be supplying you with the chips, the development boards, and the support.

Yes, but since the A5 is a relatively new core, your choices will be fewer and the competition is less - you might easily find a chip with an older core that costs less for more features.

I agree that it makes more sense to start with the A5 than the A57 - but I think it makes even more sense to ignore the exact core type at the start of your search.

If you need a second MAC, then my guess is that that requirement will push you out of the realm of the lowest price chips - and out of the realm of A5 devices. First find the selection of chips that fit your peripheral needs - then consider other factors such as price, packaging, and long-term availability.

As an alternative idea here, you might consider using a chip with a single MAC along with a 3-way Ethernet switch - these are available with a MII (or RMII) interface and two PHY interfaces, along with Layer 2 VLAN support and management. Since you will need an external PHY anyway, this might be the cheapest way to get the two independent interfaces (though the documentation for how to set up port-based VLAN switching may not be very clear).

Indeed - but as these are the only ones I have personal experience with, they are the only ones I could mention here.

Reply to
David Brown

Of course! And, the decision that makes sense today may not stand the test of time as others adopt fits *their* needs.

My initial post asked for information on A5 vendors. I would assume readers would show me the respect of assuming that I had "done my homework" and wasn't looking for -- each of which they would then want to see *justified* and offer alternative suggestions.

They'll gladly sell me whatever I am willing to buy. "Local" usage (or lack thereof) can bias their "advice": if you work in a cluster of telecom companies but *aren't* doing telecom work, chances are the "local stock" (and sales experiences) will match your needs poorly.

And the older core might go away sooner. :> It's always a crap shoot. I'm banking on ARM Ltd. having a much better/broader understanding of The Market than I do -- or any disti's, etc. I.e., they've chosen to invest

*their* effort/dollars in this product offering. Presumably because they see a need for it. I (and I suspect almost *all* OEMs) don't have the resources to investigate all sectors of a particular market before making a choice as to which components to use/avoid. So, leverage the efforts of someone (e.g., ARM) who has a more highly vested interest in that knowledge.

I *did* "ignore the exact core type at the start of my search". (Again, assume I have *done* my homework by the nature of the question posed). I ruled out the M-series and R-series devices based on the lack of MMU support. That left the A-series devices (in ARM's portfolio). Of these, the A5 gave me what I needed in terms of available features -- it didn't force me to accept The Kitchen Sink but let me pick a couple of different (related) devices to bias my price point without having to reinvest in all new tools, codebase, etc.

That left *one* issue: who to buy the ARM IP from -- hence the subject line of my post! That decision involves specifics of the individual product offerings from each vendor *around* that A5 technology. And price. And, support.

I can freely explore the details of the various parts offered/announced. I can also get pricing information (at least in 1K qty's... I'm not going to get involved in bigger qty pricing at this stage of the selection process).

What I can't "lookup" is support experiences (beyond app notes which are often of dubious quality and/or recycled from ARM directly). In particular, how glitches/bugs in the designs are handled by the manufacturers. A bug that has significant impact TO ME (but perhaps not to someone else) that isn't addressed can be the kiss of death for a design. OTOH, if the vendor is responsive and folds those fixes into *continuing* updates to the technology, then it's just a momentary inconvenience (I've had to place orders where specific masks were required to meet our needs; not fun but at least it keeps product moving).

The A5's come with 1 Gb, 1 100Mb or both MACs. There are M3's with similar hardware complements -- but no MMU. (I did some prototyping work on some of the designs with M3's -- but without adding the VM functionality, obviously)

So, my A5 selection reflects all of this "homework".

I considered that. But, the two independent interfaces is a better fit. Especially for 1588-ish work (the A5's support 1588 on the Gb i/f -- but not on the 100Mb).

My point was that I had already been through this exercise to "settle" on the A5's. Had the A5 *not* had some of the I/O's I need, I would have considered stepping *up* to a different core (assuming the I/O's were available on *that* core).

[There's a *long* list of "required" capabilities, I/O's, etc. As I didn't need c.a.e denizens make my *device* selection for me, I didn't bother mentioning any of them.]

I'd also looked at different classes of devices for different functionality (e.g., motes and servers). And, even big.LITTLE to dedicate a processor to handling the network. Bottom line, the A5 seems to have "enough" capability to address my needs without going into more exotic/heterogeneous implementations.

I'm going to follow Stephen's (and Simon's) lead and buy 4 or 5 (identical) EVB's so I can implement my VM system and see what sorts of problems I stumble upon. And, how the vendor responds to any problems that I report. This will allow me to get a feel for what the device *might* be like in production (i.e., no guarantee that it isn't "re-bugged" at a later date!)

I'll have to see how little I can implement to exercise what needs to be "proven". If all goes well, I can start designing boards based on those results.

Reply to
Don Y

There is quite a bit of luck involved in predicting the future of components!

I would have preferred that you showed the group the respect of giving your /real/ requirements, rather than just stating an artificial one and then making us guess or ask for more information. And you could have shown that you'd done your homework by giving examples of some chips or vendors that you are considering, but asking for opinions on.

I managed to summarise your "laundry list" in a single short paragraph - it doesn't need to take more than that, unless people want more detail.

Maybe I'm lucky, but any of our four biggest distributors are happy to give solid technical recommendations for components, including the possibility of training or expert help, and information about stock, availability, and sometimes inside information about vendor's future plans.

I will certainly assume that you did your homework - you never ask for advice in this group without having done solid research in advance. But while I knew from your first post that you had thought about this, I had no way of knowing /what/ research you had done, or why you thought the A5 was the single possible choice of core.

I am not trying to say that you are wrong about the A5 - if vendors are making the right SoC's for your use around an A5 core, and view them as a long-term chips and not just cheap short-term ones, then it is probably a good fit.

But your first post screams out for the question "why an A5" ?

You came to us with half an answer - we need to know the question before we can find the other half of the answer, and we must challenge the accuracy of the half-answer you have given.

And what is the risk here? You are worried that if you say you need an MMU, people will ask why? Either you know the answer and have a good reason for using it (and being the helpful person you are, you would probably enjoy teaching others here about it), or the ensuing discussion would also be helpful for you to clarify your own understanding of the problem.

These are all important aspects. They are very difficult to answer, and there is no good way to extrapolate other people's past experiences to your own future ones, but maybe you'll get some general idea.

No, the A5's do /not/ come with any sort of Ethernet.

There are some SoC's with A5 cores and MACs in those combinations - but that is /nothing/ to do with the core. There are other SoC's with different cores with two MACs, and no doubt SoC's with A5 cores and more or fewer MACs.

My guess (that SoC's with A5 cores and dual MACs would be hard to find) turned out to be wrong, but the point is still that it is not the /core/ that is the deciding factor.

Again, you are mixing apples and bananas. A5 is the cpu core - it does not support 1588 or anything else related to Ethernet. If you want to discuss a particular SoC, that's fine - but it is not an A5.

I agree that two independent MACs is often a better fit, unless hardware layout issues make the switch more suitable. And it will make accurate timing with 1588 easier.

Pick the important ones. There is no need to mention UARTs, SPI, etc., unless you have very unusual requirements.

A key point that you missed in your first posts was what you want to do with the device - the automatic assumption when someone mentions a Cortex A device is that they will be running Linux on it. Anything is is unusual, and is worth mentioning early on. In particular, since you are running your own OS, it is likely that you will have very different memory requirements from a "typical" embedded Linux system. So maybe this would be a good choice:

These are mainly for industrial and automotive applications, so they will be long-term devices (unlike devices targeted at consumer systems). I haven't used the Vybrid chips, but my experience with Freescale as a vendor has been good.

Reply to
David Brown

One of the things we have learned over the last 15 years or so is not to write O/S software for these devices - there's still a NetWinder in the building. Let the Linux weenies do it for you. Then find someone who *knows* what hard real time means and *pay* them to install the patches.

The major decision for us all is whther to build or buy the compute section of the hardware. With a quad-core ARM-7 board (RPi B2) at GBP 27, approx USD 41, the balance is tipping rapidly in favour of buy. There are many other suppliers of quad-core boards in this price bracket, e.g. Olimex.

Even you will go missing one day ...

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

Yes, the Xplained board with a D36.

Depending on the CPU, you just need to be careful with instruction set selection switches. For example, ARM32 code for Cortex-A has more restrictions than (say) for an ARM11.

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

OK. The D35 (or 36) and D31 were two of the candidates I was investigating. I'll put one on order. Not sure when I'll have time -- colleagues in town for a status meeting. Advantage of living somewhere *warm* at this time of year is *you* don't have to travel (they are more than eager to come *to* you! :> ). DISadvantage is you end up having to do a fair bit of "hosting".

[But, at least I get to set the schedule -- no early morning meetings!! :> ]

If they're documented, I'll have no problem. I'm mainly concerned about the "OhShits" -- stuff that *isn't* documented (or, documented incorrectly) that you have to discover for yourself... "the hard way".

I figure if I purchase a few of these I can deploy some test code (running just on the VM and a trimmed down network stack) to exercise the features about which I'm most concerned... Couple of hundred dollars for disposable boards easily outweighs the cost of having to put something together (just for test purposes).

Thx!

Reply to
Don Y

There's a difference between trying to backfill HRT solutions to an OTS OS vs. designing a system with the features you need "up front". HRT is simple: overprovision your design so you hit every deadline. Verify this on paper, then in testing. Done.

I try to move "most" problems to SRT solutions (as most problems really *are* SRT -- but just a lot easier to deal with if you make the deadlines *hard*! No need to resolve the pesky issues of "well, what do I do *if* I miss a deadline?"). So, instead of NO deadline handler (in a system that is completely HRT, you've decided that deadlines MUST be met so the only thing you have to deal with for a missed deadline is KILL THE JOB), I need hooks for one and mechanisms that let the code "adapt" to the new set of deadlines/values.

SRT means you have to come up with a (often variable) response to the "deadline missed" scenario. Reevaluate your relative priorities in light of this (should I keep working on this task? At the risk of making some other task miss its deadline? Or, should I just dump the task and move on??). Solutions tend to get more complicated (and, thus, the mechanisms on which they rely tend to be more complex).

E.g., HRT with Linux can be accomplished by running Linux on a HRT understructure that caters to your HRT needs and let Linux itself be on a *par* with those needs (instead of forcing it to provide the HRT guarantees itself). This lets you sidestep things like designing a RT network stack, VM/MM system, etc.

I take a similar approach (though w/o Linux) putting all the RT stuff on my RTOS and hosting "userland" tasks in a scripting language (Inferno/Limbo derived) that runs atop all that. So, *what* the system does can be easily scripted while the details of *how* it manages to "get it done" can be hidden in RT services "beneath" it all.

If I didn't have particular physical constraints on my final deployment, hands down, I wouldn't bother with (core) hardware, nowadays (e.g., the network speakers have to fit in a 1G Jbox; about 1x2x1"). Granted, you still have to design/fab something that

*interfaces* that OTS solution to your particular needs. But, unless you're really pinching pennies, you're probably better served letting someone else deal with the "more demanding" parts of the layout.

E.g., I have rearranged my system's design so it relies on a SINGLE

*truly* high performance node (database server). It's simply not economical for me to try to design a piece of hardware that can run at that sort of performance level, disk support, etc. Even a low end "PC" will typically outperform what I can build and at a fraction of the cost.

Yup. My NNTP proxy keeps clamping down on the number of posts that it "exposes" to me (one of my goals in designing it; also a chance to explore algorithms for filtering out unwanted mail, phone contacts! Some of the results have been unexpected -- yet in a pleasant way!). As a result, I spend far less time with News than I did even 6 mos ago! Get older and you have less time to spend on activities that aren't directly contributing to your own productivity ("Youth wasted on The Young, etc." :> )

Hopefully, Ulf's absence is by his *choice* and nothing else...

(sigh) I'd best get to my first meeting lest I catch an (friendly) earful about "oversleeping" or somesuch...

Reply to
Don Y

Hi David,

Apologies for the delay in replying -- folks in town for a "status meeting" have kept me tied up "playing host" for the past week. It's always amusing how these always happen *here* when there are several feet of snow on the ground "there"! :>

[OTOH, no way you'd get me to Chicago at this time of year -- let alone Beantown! "Another 18 inches"?? Ick!]

So "playing host" for ~12 hours/day doesn't leave me with much energy for email/news/etc. afterwards (esp having to prepare demos on most days). April will be Vegas -- or SoCal -- so that will be a lot less stressful for me!

Watch your mail -- I'll try to reply in the next few days... My InBox overfloweth :-/

Reply to
Don Y

No problem - if you want to carry on the discussion and think there is more we can get out of it, that's fine. But I know how it is when you are "out of the loop" for a week and things pile up - don't prioritise a reply here just for my sake.

mvh.,

David

Reply to
David Brown

Some of it melted - only ~40 inches in the open areas. Drifts and piles are higher of course.

And there's no need to exaggerate ... we're only expecting another 12 or so out of *this* storm.

George

Reply to
George Neuner

Yeah, "taking time off" is one of those annoying contradictions: take it off *now*, but MAKE IT UP *later*! (something about "free lunches" comes to mind :-/ ) I see I have another laptop to "fix". (sigh) Like TV's, never let folks know you can "fix" computers! :-/

OTOH, I'm learning there is real value to "looking away" from time to time. There was a van Vogt line that came to mind about vision being clearest just after the eye shifts position... I'll have to go looking for it (I know which of three books that likely contains it -- all of which are due to be reread soon, regardless! :> )

Reply to
Don Y

Any worse than `78? It *seems* like you've, at least, had "advanced warning" of all of these recent storms. IIRC, in `78 it was just "we're expecting some snow, tomorrow" and, thus, caught everyone by surprise with the intensity of that ~day-and-a-half of snow (followed by rain at the worst possible time/temp)

I think 80, here, today...

Reply to
Don Y

Depends who you talk to. The snow fall from the 1st storm 10 days ago actually was higher than 1978: 34in vs 28. But unlike '78 we didn't get an ice storm on the back end.

We got another 20in from a second storm 4 days later, plus some flurries almost every day. We had 2 days of melting temps which cut down the pack a little, but now we're getting another ~15in and we're expecting single digit temps for a while.

Biggest problem is no where to put it. The piles are out of reach of everything but cranes and big front loaders. Boston is completely out of room - all the snow lots are filled to capacity. They are running

3 dozen snow melters 24/7 at $1K/hr.

My 42in front yard fence is buried everywhere but at the gate. The snow on the back deck is head high, but you might recall it's in a hollow surrounded by a rock garden: snow blows in and stays. The heated bird bath that attracts the wildlife is just a sink hole in the snow 8-)

Head high piles either side of the driveway and walk. If I climb up on the plow pile across the street, I can look down at my roof.

George

Reply to
George Neuner
8<

How quickly did it accumulate? IIRC, 78 was roughly an inch per hour. And, as I said, it didn't receive a lot of pre-storm alerts... just "yet another snow storm" (ISTR the Civic Center died a few weeks before that -- i.e., "snow" wasn't an unusual experience! :> )

Melt is the worst! Just means you'll have crunchy snow (at best) and slick streets (more commonly!). I used to avoid clearing the driveway and sidewalks until long after the snow had ended so I could see what would follow (precip/temps).

Also, I don't recall a parking ban in '78 prior to the storm. So, lots of vehicles with "driver-side damage" :>

River/bay too far to haul? Or, frozen over?

... with ominous "steam" wafting from it! :>

I miss snow. The *only* time I would "get up early" (being more of a night-owl) was to watch folks scurrying off to work in that mess! :>

Of course, the *few* times we've had anything "white" falling from the skies *here* has sent everyone into utter PANIC! Sheesh! Amusing when you consider how many of them are "winter visitors" who should be *familiar* with the stuff! :-/

[Perhaps it's not INCONVENIENCE/COMFORT that causes them to winter here, but, rather, a FEAR of "those flittering white things"!]

Next set of guests are coming from upper Minn. I don't think they've seen *freezing* temps for months! :-/

Reply to
Don Y

About the same - 34in in roughly 30 hours. But according to the news, it was the greatest single storm snowfall since they've been keeping records.

The 2nd storm was long duration (3 days) so the accumulation was gradual but it still dumped another 20in on top of the 1st storm (which hadn't melted).

This current storm dumped 10in in 4 hours this morning, but then lightened to flurries which have continued all day and have given us another 5-6in.

No real problems with cars being damaged. The mayor banned travel and opened up the Common garages and city lots so some residents could get their cars off the street. But there are 2.6 cars for every parking space in Boston the side streets are parked up anyway. Some still haven't been plowed 10 days after the first storm.

Illegal. Snow from the street is "dirty". Melters put it down the sewer so the treatment plant can process it.

I can't even get to the outlet to unplug it [breaker kills other stuff too]. I hope there's actually water in it [snow falling in] so the heating element doesn't burn out.

Same here. Being originally from western NY, I don't mind snow. I vastly prefer snow to rain. But eastern MA averages only 50in/yr, so when 50in falls in a week everyone panics.

George

Reply to
George Neuner

Boston just closed almost all mass transit for tomorrow. Total so far from 24th Jan through today here is 65". Another few inches likely tonight. Good thing we don't really have to go anywhere!

The 78 storm was indeed more concentrated and shut things down for about a week IIRC. But this round the piles are getting too tall for the snow-blowers and plows.

We're in Acton; where are you George?

Aaarrgggg...

Reply to
Dave Nadler

"Better you than me!" :> Actually, we had a fair bit of rain last week (or maybe it was the week before? Last week is a bit of a blur for me) which probably ended up in your lawn...

That was always a problem in Chicago as well. Same reasons. In the burbs, you at least had lawns on which to pile it.

Garden hose from 20 feet with careful consideration of angle of incidence to the bath? Or, a snowball fight with a stationary target?? :>

I can recall HUGE snowfalls as a kid. Creating "forts" in the snow by "digging sideways" into the stuff in the yard. And, tall drifts (used to *walk* onto the roof of the local grammar school -- maybe 12ft?). Biggest pisser was the city plow and the mountains of snow/ice that would inevitably get thrown up on each "corner" (where driveway meets roadway) of the driveway -- creating a nice pocket for the "melt" to accumulate... inevitably refreezing into a frozen *lake* at the base of the driveway (significant hill).

In Chicago, snow was a welcome thing -- meant it was reasonably warm! (-26F w/ -83 WC my personal "record" :< 3 minute exposed flesh warnings! ick)

Here, rain is welcome (obvious reasons). Amazing to see folks stop what they are doing and watch it rain. Or, walk out *in* it. I don't think I've seen anyone wear a genuine "raincoat" in all the years I've been here -- you just *walk* in it ("Hey, it's just WATER!").

OTOH, Winter rains are the dreary sort you find in the NE and Midwest... slow and prolonged. Grey skies all day long Depressing. Odd to think I've lived in places where that was the *norm*! :-/

Reply to
Don Y

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.