How do you choose an ARM family

 How do you choose an ARM family

How do I go about picking an architecture ? My first thoughts suggested Cortex M3 but the more I look into it the less sure I am.

Obviously I don't to go to the trouble of learning a new technology only to find that I've made a bad processor choice (ie nearly end of line). I've spent many hours looking at many websites and have yet to find any high-level stuff on choosing my first ARM device.

If there's one thing wrong with ARM its the almost infinite number of devices

I'm an embedded developer wanting to undertake my first ARM project, so I'm completely new to the ARM architecture. I want a low power device with serial, USB and some ADC channels.

 RE: Cortex M3

The Cortex M3 is supposed to be an "easy (easier?) to use" ARM - so I guess that would be the one to start with?

Being quite new, the manufacturers & distributors are pushing it quite hard - so you should be able to find some introductory seminars/workshops (probably free) without too much trouble...

Personally, I would recommend a Luminary Micro (now TI) kit to start with: they are cheap, and you get a complete, ready-to-go kit - including tools - all in the box.

 RE: Cortex M3

Thanks Andy, I am extremely grateful that you took the time to reply. I was beginning to lean towards the Cortex M3 and I think your reply seals the deal. I am now confident to press on ahead with my first ARM project.

Best wishes from UK,

John

 RE: Best wishes from UK

You're welcome.

From England!

 RE: Best wishes from UK

I don't think Cortex or normal ARM kernel is too important.

Look for a reasonably recently release. Each new release tends to either be cheaper or add more goodies. And being new means the manufacturer (still) believes in it.

Having so huge number of choices, you must really make a list of your requirements. Besides the obvious (number of UART, ...) you should go a bit more into details.

Do you require FIFO or DMA for the UART?
Do you require FIFO or DMA for SPI?
Do you require battery-backed RAM?
Do you require low-power sleep modes?
Do you require the family to have big brothers with lots of flash or RAM, in case your code grows larger than planned?
Do you require the family to have big brothers with more I/O pins, in case you want to later build a deluxe edition of your product?
Does Keil simulate all the peripherials you need, or do they just simulate the core?
If you call a distributor - what chips would they recommend?
Is it 5V-compliant in case you need to mix 3.3V and 5V logic?
Can it produce the low core voltage internally, or does it require dual voltage sources?
Does the manufacturer (or someone else) have a good set of sample code that makes use of most of the peripherial functions of the chip?
Do you have special needs for ISP and IAP? Speed of erasing flash sectors? Suitable sector sizes? Built-in boot loader, or requirement that you write one?
Does it seem "popular" if you surf around a bit?

If all you want is to learn to use ARM chips, then you should probably give the biggest priorities to "popular", and good availability of sample code. Then go for the evaluation board that has the coolest surrounding electronics (display, USB connector, temperature sensor, ...) for a reasonable price.

 RE: evaluation board that has the coolest surrounding electronics

Beware of "evaluation boards" that have loads of "goodies" on them.

Very often, these "goodies" can just get in the way of your own requirements.

And, these days, disabling the "goodies" is not just a question of fitting or removing jumpers - you have to fit or remove tiny, surface-mount zero-ohm resistors...

They can be great if you just want to "play" with what's there - but can be a real pain if you have an actual aapplication in mind...

This is general across the board - by no means specific to any kind of ARM.

 RE: evaluation board that has the coolest surrounding electronics

Lots of goodies is nice, but should be completemented with lots of jumpers so that you can decide if they will consume processor pins or not. A board requiring (de)soldering to deactivate the goodies is lousy. It must be quick and easy to switch between the evaluation-board hardware and own hardware and then back again, in case the software (or the own hardware) doesn't work as expected.

But note that my recommendation to look for a evaluation board with lots of goodies was for someone interested in learning how to use a processor - not someone interested in designing their own products around an ARM chip. If the goal is to develop own products, then it is often better with a evaluation board with pin headers allowing the processor to be mated with prototype boards. A big prototyping area can be nice, but are best if you can afford to buy multiple evaluation boards.

 requiring (de)soldering to deactivate the goodies is lousy

I thoroughly agree.

It is, however, the trend these days.

:-(

And I do take your point about the distinction between learning/experimenting and actually trying to develop an application.

 RE: Cortex M3

John;
I believe that one of the devices in the Cortex-M3 family will be an excellent choice.
I think the Luminary devices are great chips. I just worry about which chips that TI will cull from it broad device selections. With the TMS430 (not ARM), the TMS470, the OMAP35xx series only the shooting stars will make the cut. I know exactly which device will be cut. The very next Luminary chip I select for a project will be the first victim : (
For the Cortex M-3, I suggest that you review Joseph Yiu "The Definitive Guide to the ARM Cortex-M3". The ISBN: 978-0-7506-8534-4. You can review the book at http://www.books.elsevier.com. It's a UK book house.
Also, available is the Cortex_M3 Technical Reference Manual (TRM) at http://www.arm.com/documentation/ARMProcessor_Cores/index.html
Bradford

 RE: How do you choose an ARM family

I want a low power device with serial, USB and some ADC channels.

I think those are the requirements you should focus on (repeating others' remearks here.) Not the 'ARM family.'
What's an 'ARM family' anyway? Is it the CPU core? ARM7TDMI is among the most popular in general-purpose MCU's. Cortex M3 is emerging as the new leader. Whatever you pick, you'll still program in C (most likely.)
I've had an experience of transitioning from an ARM7TDMI-based MCU to Coldfire V2. The latter is big-endian as opposed to the little-endian ARM7TDMI. To my surprise, it wasn't painful at all. As long as you write in well-styled C, you won't have problems running your code on any 32-bit CPU.
For every new architecture, things like startup code and device drivers have to be written. That's something to keep in mind. Apart from that, I don't think the choice of a CPU family is that critical.

 RE: How do you choose an ARM family

look at what you need

 RE: How do you choose an ARM family

if you are just trying to learn about the chips, it is a lot easier: the idiosyncrasy among the various ARM chips, even across vendors, is much less than for other chips, like PIC. that is especially true if you stay with a high-level language, like C.

however, if you start to use OEM libraries in your code, the program will become very platform dependent and far less portable, unless you rewrite the library functions for another chip - which is doable but can be burdensome.

if you are picking a chip for a particular design, I would prototype it on a dev board, figuring out how much resources you need and upon completion, pick the device that matches the current and future needs for that project.

 RE: How do you choose an ARM family

It is always very dangerous to make use of manufacturer-specific libraries.

For commercial use, you should have full access to the source code, and a license that allows you to run the code on _any_ processor, even if different manufacturer or non-ARM architecture.

I'm not too fond of the libraries some manufacturers supplies with the intention to make it easy to move between different chips from them. It might sound good, but the main reason for the manufacturer-supplied libraries is to make it hard for you as customer to move to a different manufacturer. Having millions invested in a product and find that you can't move to a different manufacturer to save $2/device, or to get a working chip after the original chip stops being produced can be very interesting...

 RE: How do you choose an ARM family

"For commercial use, you should have full access to the source code, and a license that allows you to run the code on _any_ processor, even if different manufacturer or non-ARM architecture."

I would be surprised if that (moving the code to _any_ processor, even if different manufacturer) is the case with OEM libraries - at least in my experience.

a big discussion is going on right now with TI's purchase of Luminary, and the resulting possibility to run Luminary libraries on TI chips. the Luminary library provides full source code to its libraries and it is not hard at all to port it to other TI chips, ARM or not, or other manufacturers' as well.

But legally, you are NOT supposed to do that.

if you can provide a few examples where an OEM library can be legally run on other manufacturer's chips, I am happy to see that.

 RE: a big discussion is going on right now

Right now?

Really?

 RE: a big discussion is going on right now

Simulation also.... helps a lot to get the product soon quick.

I feel Keil is better for ARM and C51 cores..

Chinni

 RE: How do you choose an ARM family

No, I would have big troubles supplying examples. But that is why I warn about taking the easy route and use the OEM libraries without first having made a full analysis of the implications.

 RE: How do you choose an ARM family

"No, I would have big troubles supplying examples. "

because such OEM libraries don't exist - any OEM would be crazy to invest in a library only to help competition by allowing such libraries to be used on its competitor's chips.

"But that is why I warn about taking the easy route and use the OEM libraries without first having made a full analysis of the implications."

your caution is the right one but for the wrong reason.

 RE: How do you choose an ARM family

your caution is the right one but for the wrong reason.

No. Per's caution is due to the impact such libraries can have on the performance, stability and in the end, SAFETY of systems. it is rahter your line of argumentation that is redundant from an engineering point of view.

 RE: How do you choose an ARM family

"Per's caution is due to the impact such libraries can have on the performance, stability and in the end, SAFETY of systems. "

can you point out for us the exact sentences where Per argued in a way consistent with your representation above?

Just don't want to put words in Per's mouth, you know.

 RE: How do you choose an ARM family

I believe that is the reason he specifically referred to "source code".

 RE: How do you choose an ARM family

"For commercial use, you should have full access to the source code..."

 RE: How do you choose an ARM family

"For commercial use, you should have full access to the source code..."

which part of that talked about "performance, stability and in the end SAFETY"?

are you suggesting that having, or not having, access to the source code will hurt "the performance, stability and in the end, SAFETY of systems".

if so, how?

if not, what exactly did you mean?

 RE: How do you choose an ARM family

Return to my original post. I did wrote:

"It is always very dangerous to make use of manufacturer-specific libraries.

For commercial use, you should have full access to the source code, and a license that allows you to run the code on _any_ processor, even if different manufacturer or non-ARM architecture."

I never said that manufacturers have libraries with licenses that allows you to move them to other architectures and/or manufacturers products.

I did say that a manufactuer-supplied library can be very dangerous to use.

And I did say that you should look for libraries that has source code and an acceptable license. These libraries would most probably _not_ be manufacturer-supplied, but libraries you buy from 3party companies, or libraries that have a LGPL license or similar.

When you invest greatly in a product, you must make sure that you are not squeezed into a situation where you must either start from scratch because your processor gets dropped, or where you must continue with one manufacturer even if another manufacturer has a way better product.

The question is how to best protect your investment, and to allow your company to make the business decisions, and not your component suppliers.

You may find that your nice product is too small - you get a customer that says: We will buy 10k units/year if you just have one more ethernet connector and 12-bit instead of 10-bit ADC. With full control over the sources, you may be able to port your 99% C/C++ code to _any_ available ARM. With 40% of your sources locked to a specific manufactuer, you may no longer just adjust the peripherial mappings for another chip, but suddenly also rewrite, test, document, ... the 40% of the code that you are not allowed to reuse.

And you may suddenly find out that you need 12 months for such a step, but a competitor can supply a customized OEM product in 3-6 months. Oops. Deal lost because you where not in control of the source code for your important product.

In the end, the chip manufacturers do not supply their libraries to be nice and make it easier to use their chips. The main reason is to lock you in. That the libraries _may_ simplify some things is a bonus, but not the primary goal. The only simplification that was intended was the amount of work needed to to move within their chips compared to the work of moving to a competitors chips.

 RE: How do you choose an ARM family

"For commercial use, you should have full access to the source code, and a license that allows you to run the code on _any_ processor, even if different manufacturer or non-ARM architecture."

and you cannot provide any examples of such libraries that would allow its licensees to use on _any_ processor.

it is a theoretical possibility and practical impossibility.

unfortunately, we live in a world that "should" has no value. "Per should be a billionaire" doesn't buy a $0.49 burger at McDonald's, :).

 RE: a theoretical possibility and practical impossibility

Not at all!

There are many commercial libraries that can be licensed to any suitable target; eg, most commercial TCP/IP stacks.

 RE: a theoretical possibility and practical impossibility

"most commercial TCP/IP stacks."

and you can eat BigMac with BK seasoning too, :).

while entertaining, your argument does sound irrelevant to our discussion here.

 RE: a theoretical possibility and practical impossibility

I did not find Andy's argument entertaining one bit (in the case). He is simply right.

 RE: a theoretical possibility and practical impossibility

I meant of course,
"I did not find Andy's argument entertaining one bit (in this case). He is simply right."

 RE: a theoretical possibility and practical impossibility

tamir, have you managed to find Per's writing that suggests that his caution against the use of OEM libraries "is due to the impact such libraries can have on the performance, stability and in the end, SAFETY of systems. "?

Just don't want to put words in Per's mouth, you know.

 RE: a theoretical possibility and practical impossibility

I already explained to you where, and even provided a quote.

 RE: a theoretical possibility and practical impossibility

tamir, are you talking about this "quote"

"For commercial use, you should have full access to the source code..."

which part of that talked about "performance, stability and in the end SAFETY"?

are you suggesting that having, or not having, access to the source code will hurt "the performance, stability and in the end, SAFETY of systems".

if so, how?

if not, what exactly did you mean?

 RE: a theoretical possibility and practical impossibility

try to focus on the end of the quote. namely, the expression that start with a "s" (a blatant clue, surely you agree).
if you need more, just say so. Ahh, whatever, I'll give you one more: the next character is "o". now it's a no-brainer.

 RE: a theoretical possibility and practical impossibility

tamir, thanks for that clue, not.

which part of that talked about "performance, stability and in the end SAFETY"?

are you suggesting that having, or not having, access to the source code will hurt "the performance, stability and in the end, SAFETY of systems".

if so, how?

if not, what exactly did you mean?

if you cannot answer the questions, please just admit to it and we will excuse you on your behalf.

thanks in advance.

 RE: a theoretical possibility and practical impossibility

I never like this, but it is a software release date and a reason to celebrate to let get it on!

 RE: a theoretical possibility and practical impossibility

I meant: "I'm never like this, but it is a software release date and a reason to celebrate to let get it on!"

 RE: a theoretical possibility and practical impossibility

Mr Tamir.

What are you on { about } ?

 RE: a theoretical possibility and practical impossibility

release P004 rocks...!

 RE: a theoretical possibility and practical impossibility

tamir, don't give up. don't EVER give up, :).

 RE: a theoretical possibility and practical impossibility

I'm not. Actually, now that RTX related problems have been solved (I hope; will know more the coming days when the feedback from the client(s) arrives) there is a real possibility to making it to the original deadline. Say, Ashley, are you related to "Jack Sprat" [or maybe I should say: ARE you "Jack Sprat"? Sorry Per for resuming the kindergarten for a while; I'm actually enjoying myself. this was a good day - have I mentioned release P004 yet? :-) ]
ho and Ashley you forgot to grade me!

 RE: which part of that talked about ... SAFETY?

Per did use the word, "dangerous".

But I don't think he was talking (particularly) about hazards to persons or property - I think he was talking about business risks.

As in, "there is a danger [business risk] that not having the source code may leave your project/product high & dry"

I think.

 RE: which part of that talked about ... SAFETY?

"I think he was talking about business risks."

nice try. I would give you an F for effort.

 RE: which part of that talked about ... SAFETY?

This thread quickly evolved into a kindergarten brawl, for no apparent reason.

Why should I be required to give examples to something I'm not claiming?

The probability of bugs is similar whoever wrote the code. A much used library from a manufactuer should - hopefully - be reasonably well-tested by all the users.

But I was talking about the business risks of using a library you don't have the source code - and suitable license - for.

With the source code, you can perform security reviews, looking for buffer overflows, resource leaks...

With the source code (and most licenses), you can correct bugs without need to wait for a new official release, and without worrying about the supplier vanishing.

With the source and a suitable license, you can not only fix any bugs, but also move the complete source code to new platforms.

Since a chip manufacturer isn't likely to supply general libraries with full source and BSD, LGPL or similar licenses, you should be very careful about using them. You may end up with a very serious nose bleed.

The CRTL can also be a bit problematic, but the advantage with the CRTL is that there exists a large number of suitable licensed C runtime libraries, so a company can replace printf(), strxxx(), time(), ... with alternative implementations without having to start from scratch, as long as the target has some safety margins in case the alternative implementation takes more code space, RAM or executes a bit slower.

 I recall a case

With the source code (and most licenses), you can correct bugs without need to wait for a new official release, and without worrying about the supplier vanishing.
A ticket machine was violating the J1708 protocol and created many errors on the bus. When the manufacturer was approached they, of course, replied "no such thing". After being shown proof they stated "this will be fixed in the next release out in October next year (my emphasis).

Erik

 RE: which part of that talked about ... SAFETY?

"Why should I be required to give examples to something I'm not claiming?"

sounds like you are unclaiming what you just claimed. what do you think this guy/gal was claiming when s/he said:

"For commercial use, you should have full access to the source code, and a license that allows you to run the code on _any_ processor, even if different manufacturer or non-ARM architecture."

no answer is required, :).

 RE: which part of that talked about ... SAFETY?

so Andy, you are conceeding on that the two other fronts (performance and stability), Per didn't think using OEM libraries would have adverse effect? could you work that out with tamir? :)

"As in, "there is a danger [business risk] that not having the source code may leave your project/product high & dry""

so it would not have any adverse impact on "SAFETY" (aka business risk) if you have access to the source code?

does that make it OK to use the Luminary libraries? could you please work that out with Per? :)

 Reversed logic

So, I give you an F for your reading skills.

Where did the following text explicitly mention that you should use OEM libraries with generous licenses?

"For commercial use, you should have full access to the source code, and a license that allows you to run the code on _any_ processor, even if different manufacturer or non-ARM architecture."

The above text indirectly says that you should look for _general_ libraries and _stay_away_ from manufacturer-supplied libraries.

This was further strengthened if you had also quoted the sentence directly above: "It is always very dangerous to make use of manufacturer-specific libraries."

That is a good reason why it is quite strange that you require me to supply examples of OEM libraries with LGPL, BSD or similar license even if such examples does exist.

If I should supply examples to my claims, then it woould be more reasonable to expect examples of restricted licenses common with manufacturer-supplied libraries - not examples of free manufacturer-supplied libraries.

Do you often expect people to back their claims by examples that are negating the claims?

 Per gives advice based on experience and then ....

... some young whippersnapper SHOUTS "prove it"

If we can not share our experience whithout being "taken to court" then some of us will need to start charging (which we do when required to 'prove')

Erik

 RE: Per gives advice based on experience and then ....

'If we can not share our experience whithout being "taken to court" then some of us will need to start charging (which we do when required to 'prove')'

you sure can share your experience whenever you want. That doesn't mean that others have to take your experience at face value.

if you cannot stand the heat, you should probably stay out of the kitchen.

 RE: Reversed logic

'Where did the following text explicitly mention that you should use OEM libraries with generous licenses?'

why should I defend a question that I didn't ask?

you get F for your reading comprehension.

 RE: Reversed logic

woman, you have an attitude! yuk! :-)

 RE: Reversed logic

"why should I defend a question that I didn't ask?"

So you don't even understand your own posts?

"if you can provide a few examples where an OEM library can be legally run on other manufacturer's chips, I am happy to see that."

 RE: Reversed logic

is it less than truthful if the whole discussion has been able the use of OEM libraries - I am the first person mentioning that and you follow right up with your "commercial library" concept, which the OEM libraries are a subset of it.

now, you are saying that you followed up in a thread about the use of OEM libraries so you can talk about the use of non-OEM libraries that allow you full source code access, of which you can find none?

so you are essentially suggesting that we should use libraries that do not exist?

????????????????????????????????????????

is this some kind of mind trick?

 RE: Reversed logic

Good writing practices says one or three punctuation characters. Not two. Not more than three. But then sentences are expected to start with a capital letter.

Do read my post again. I warn aganst the use of manufacturer-specific libraries or any other kind of libraries, where you do not have full control. And full control includes access to the source and a license that allows you to use it.

I have never once said that manufacturers likes to give out their libraries with full source and carte blanche licenses. But I have claimed that the main reason for such libraries is to bind you harder to their products.

The only trick involved is a trick often used by the manufacturers. If you are going to use a manufacturer-supplied library, you should at least do it with your eyes open!

The ARM chips are powerful enough that you can most of the time have very good separations between hardware and business logic. When you design all of the code, you can be very careful about where to place this separation. When using a manufacturer-supplied library, you will instead end up having your business logic littered with copyrighted function calls. You can't just rewrite the library implementation if you try to move to another processor, because you need to match the original function prototypes - and the original header file is copyrighted...

 RE: Reversed logic

"I have never once said that manufacturers likes to give out their libraries with full source and carte blanche licenses. But I have claimed that the main reason for such libraries is to bind you harder to their products."

Now I use my MCU vendors brain:
Creating the libraries often involves many man years of coding, so why giving it away to be used by competitors. Why would you not want to try binding customers to your chips if at all possible. That is viable business practice as long as you help your own customers.

Switching brain to MCU user:
It sucks to be stuck with one vendor, particularly using ARM where it would be rather easy to switch from A to N to S or T. So if I find a real open source I will probably go for that one.

Impair, an attempt:
If you find what you are looking for with one vendor and the chips do what they should and the price is right, don't argue, go for it and get work done.

Cheers, Robert
For the original poster there is a site that gathers articles related to Cortex-M
http://mcu-related.com/architectures/35-cortex-m3

 RE: Reversed logic

"Do read my post again. I warn aganst the use of manufacturer-specific libraries or any other kind of libraries, where you do not have full control. And full control includes access to the source and a license that allows you to use it."

more precisely, where you *MAY* not have full control of the source code. the Luminary library is a good example.

"I have never once said that manufacturers likes to give out their libraries with full source and carte blanche licenses. But I have claimed that the main reason for such libraries is to bind you harder to their products."

nobody said that you said that, so let's move on.

your point about avoiding OEM libraries is a good one, and nobody is arguing against it. because the lack of portability introduced by OEM libraries can be too great: those libraries typically forbid the porting to a competitor's chips.

the reasons given in support of such an argument, needing full source code access on a commercial package, security (?), performance and stability, are bogus at best.

however, I do see advantages of using OEM libraries: the code is generally of higher quality than a novice programmer can generate and it gets one going quickly. so if a corporation has made a commitment to a platform / vendor, it can be advantageous to use oem libraries.

but a thorough analysis needs to be done before committing one to such an approach.

 RE: Reversed logic

About manufacturers giving out full source with nice licenses:
"nobody said that you said that, so let's move on."

Actually, you did with:
"sounds like you are unclaiming what you just claimed. what do you think this guy/gal was claiming when s/he said:

'For commercial use, you should have full access to the source code, and a license that allows you to run the code on _any_ processor, even if different manufacturer or non-ARM architecture.'

no answer is required, :)."

You explicitly wanted me to provide examples of something I did not claim, so yes: You indirectly said that I said that, by implication. Please remember what you write, and please argue based on existing claims instead of sometimes inventing claims from me, or sometimes forgetting your own claims.

"the reasons given in support of such an argument, needing full source code access on a commercial package, security (?), performance and stability, are bogus at best."

You think it is a bogus claim that without the source to a library, you can't fix any bug and have to hope that the library owner will quickly come and help out? What do you do if you have a support contract with the customer to fix bugs within timespan x, while you have a totally unknown timespan for the library owner to _maybe_ help out with library bugs?

What do you call it when the library owner says there isn't anything wrong with the library? What do you do when the library owner _maybe_ 6 months later releases a new - and corrected - library without still admitting to there ever having been anything wrong? A non-issue? You tell your customers that any problems with the product they have seen wasn't your fault and that the 6 month response time wasn't so bad?

Don't know what _you_ mean about security. I am talking about business risks. Should have been cleaar many posts ago.

Don't know what _you_ mean about performance and stability. This is the first post in this thread where _I_ use the words "performance" and "stability" so your argument that my argument is bogus is obviously bogus. It's once more that F in reading.

The issue here is that even for a small product, you can quickly end up having invested $1 million or more. And the value of the investment directly relates to the trust your customers puts in you and into your product. A large number of companies have a very high percentage of the sales to repeat customers, which means that the trust of these customers is everything.

 RE: Reversed logic

the reasons given in support of such an argument, needing full source code access on a commercial package, security (?), performance and stability, are bogus at best.

Ashley, I'm just holding my head in disbelief.
BOGUS?

the code is generally of higher quality than a novice programmer can generate and it gets one going quickly

Oh, yeah? I don't know exactly how long you have been in this business, but I have a wild guess...! No offese, of course.

 RE: Reversed logic

The interesting thing with "the code is generally of higher quality than a novice programmer can generate" is of course that a company that has any form of IT and business strategy should not use novice programmers to develop their products.

And licenses and availability of library sources are normally irrelevant for a student who just has to hand in a solution to an exercise. As long as the teacher allows the use of the library, the student will be home-free.

 RE: Reversed logic

Dear Ashley:
My previous employer was literally braking all records in terms of incompetence, unprofessional attitude and general ignorance. They happen to have a big name AND an ISO 9001 and more. At the same time, these people are making things that can (and do, annually) kill people all over the world...! (no, they don't build weapons)

 RE: Reversed logic

"the code is generally of higher quality than a novice programmer can generate"

I have no idea how much experience you have of such things, but my experience is somewhat different.

Quite often, examples from chip suppliers should barely be described as examples.

For instance ...

I spent over a year on a project with Dallas code for an 80C400 and used their TCP stack.

After numerous problems taht they could not fix, they finally agreed to let me have a copy of the source code (after signing the obligatory NDAs).

My verdict on their code was not positive. Actually, it was so bad that I had to recommend an immediate stop on the products that included the code.

If I had access to that code at the start, our product may well have been considerably more reliable.

 RE: Reversed logic

One product we had used some quite expensive commercial libraries.

The implementation of strncmp() was actually a memcmp(), i.e. if the two input strings were identical, and shorter than the max length to compare, the very expensive commercial library considered it ok to continue comparing the strings after the terminating zero, for a very unexpected and random result...

There is one situation where a chip-unique manufacturer library makes sense, and where it may represent a significant amount of development time. That is if you buy a special processor with special additional hardware.

If you need a software modem, it can make sense to buy a special processor with DSP acceleration, and use it with manufacturer-supplied soft-modem code. Your business decision is to get an almost turn-key hw+sw modem that you complement with your own - as much as possibly generic - main logic. Such a concept could save enough money (compared to using separate modem + duplex chips), that you after one year of delivery has saved enough on component costs that you can afford to buy a full years consumption of processors to put on the shelf as buffer in case the processor gets unexpectedly dropped and you need to redesign with a different processor.

If you do buy a chip with hardware acceleration for MP3 decoding, then you have normally already payed the sw license for using the corresponding MP3 decoder library. And you would expect that playing MP3-encoded voice prompts should be so trivial that you can't really get hurt by late bugs in the library.

But these examples are special cases where you directly when you selected the processor made an explicit choice locking your product to a specific sw+hw bundle. You normally don't take such decisions without having a backup plan. You may look at two different sw-modem solutions. Select to design with one solution after having made sure that there are at least one other solution good enough and possible to switch to within a reasonable time frame. And you make the business decision taking into account the amount of chips you may have to keep in a buffer to keep you going during the redesign. And you upfront estimate the redesign cost, the extra cost of warranties for two different designs and the extra certifications needed in case the backup design has to be implemented.

But a big problem with manufacturer-supplied libraries is that manufacturers do not have the best developers in their staff. It can often be (hopefully) good hw engineers that will have to double as sw engineers. And sometimes, it is one or more application engineers.

 RE: Reversed logic

"My verdict on their code was not positive. "

there are always bad OEM libraries, as there will always be bad programmers, or bad people.

But such facts don't mean all OEM libraries are bad, or all programmers are bad, or all people are bad.

if you don't believe me, take a look at Luminary's Stellaris and let me know if you think you can do better consistently.

 RE: Reversed logic

But such facts don't mean all OEM libraries are bad, or all programmers are bad, or all people are bad.

almost 10 years ago I was working for a startup company on a VOIP phone. we used a commercial TCP/IP stack which was riddled with a huge number of bugs. We could only help the manufacturer by actually having the source code and a lot of willingness to debug and dig up their trash...

 RE: Reversed logic

I don't know why, but whenever someone mentions problems with a TCP/IP stack, I start to think about InterNiche. 10 years should be about the right time frame too ;)

 RE: Reversed logic

"I don't know exactly how long you have been in this business, but I have a wild guess...! No offese, of course."

I think I started with the mcs-48 family in the mid/late 1980s. then 8031/32 after that.

is your wild guess reasonably close?

 A late start

"I think I started with the mcs-48 family in the mid/late 1980s. then 8031/32 after that."

So you were behind the curve, but playing it safe.

 RE: Reversed logic

is your wild guess reasonably close?

No.

 RE: Reversed logic

Tapeer.

you must learn and stop being quick to jump with yo're conclusions.

i think you sometimes rate a book with what is in the next room.

Always yo're freind.

Zeusti.

 RE: Reversed logic

lobotomized.

 RE: Reversed logic

Tapeer.

i am sad to hear of yo're condition.

please ask if yo need more support.

Always yo're freind.

Zeusti

(you can read the abi during yo're recovery)

 RE: Reversed logic

lobotomized.

 RE: Reversed logic

Tapeer.

i am sad for u. do u know u r repeating ur self?

ur recovery has not started yet?

Always yo're freind.

Zeusti.

(knows you do not need to push r0 and r1)

 RE: Reversed logic

lobotomized.

 RE: Reversed logic

Tapeer.

i enjoy so much all the philisofical discusions with u. but i am busy and must work now.

plz. u lie down and relaxxxxx.

Always yo're freind.

Zeusti.

(job one, write good delay rootine)

 RE: Reversed logic

I don't bother to read you messages anymore. I will only stop after you openly admit that you went through the lobotomy procedure, like this: "My name is zupeesti and I am lobotomized. Excuse my bad manners" (you can add typos were you like).

 RE: Reversed logic

tamir, you sound like you have an anger mgmt issue.

calm down, please.

 RE: Reversed logic

tamir, you sound like you have an anger mgmt issue.

NO WAY, YOU @#!$#$%$@^#$%$#%$@%@%$@

:-)

:-)

 RE: Reversed logic

"But such facts don't mean all OEM libraries are bad, or all programmers are bad, or all people are bad."

No one has made such a claim.

The question is just how much you are willing to trust the library supplier if you don't have access to the source code to verify the code quality and to incorporate fixes. Incorporating a bad library in a product can be lethal for a company, so the question is how much trust you have in the library supplier.

 RE: Reversed logic

(knows you do not need to push r0 and r1)

just a little foot note:
you do know that this only applies to THUMB mode, don't you? otherwise, the following would not have appeared in the ATPCS (ARM-Thumb Procedure Call Standard) document, surely you agree?

maybe you have skipped this while browsing your documentation:

http://infocenter.arm.com/help/topic/com.arm.doc.dui0056d/DUI0056.pdf

see page 24, paragraph 2.2.1

quote:

The following register usage applies in all variants of the ATPCS except where otherwise stated. To comply with the ATPCS you must follow these rules:
Use registers r0-r3 to pass parameter values into routines, and to pass result values out. You can refer to r0-r3 as a1-a4 to make this usage apparent. See Parameter passing on page 2-9. Between subroutine calls you can use r0-r3 for any purpose. A called routine does not have to restore r0-r3 before returning. A calling routine must preserve the contents of r0-r3 if it needs them again....

however, if you can find a similar quote for ARM mode, in which I have written my code - you are right (but I doubt you will).

 RE: Reversed logic

I forgot to highlight the following:

"A called routine does not have to restore r0-r3 before returning". but this is only true when complying with ATPCS. it is certainly not true (as far as I know) when running in ARM mode.

 RE: Reversed logic

Tapeer.

i dn'nt have time 2 teech u simple basics. but u need advising.

read

http://en.wikipedia.org/wiki/Calling_convention

look at entry for arm

read

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042c/IHI0042C_aapcs.pdf

look at page 16

if u do not understand now. compile this little function with keil

void SmallDelay(void)
{
  volatile int x;

  for (x=10000;x!=0;--x)
    ;
}

look at the code made by compiler

                  SmallDelay PROC
;;;783
;;;784    void SmallDelay(void)
000ba4  e59f0100          LDR      r0,|L1.3244|
                  |L1.2984|
;;;785    {
;;;786      volatile int x;
;;;787
;;;788      for (x=10000;x!=0;--x)
000ba8  e2500001          SUBS     r0,r0,#1
000bac  1afffffd          BNE      |L1.2984|
;;;789        ;
;;;790    }
000bb0  e12fff1e          BX       lr
;;;791
                          ENDP

see that r0 is not preserved.

or do you think keil have got it wrong?

as i say b4. you should not say book is bad if you have not seen.

Always yo're freind.

Zeusti.

 RE: Reversed logic

not surprisingly you don't answer my question, but let correct you: R0 is not saved because it should not - it is always used as a return value. try to actually understand what you are posting, for a change.

 RE: Reversed logic

look man, I'm serious now. you are a danger to society. do you understand? you are dangerous by writing delay loops like that. confide it: you are indeed dangerous. don't write software for:
planes
missile
space systems
cars
trains
etc.

stick to flashing LEDs and bad English, please...

 RE: Reversed logic

Tapeer.

a nother example to cklarimfy.

void SmallLoop(void)
{
  volatile int a;

  for (a=10000;a!=0;--a)
  {
    volatile int b;

    for (b=10000;b!=0;--b)
    {
      volatile int c;

      for (c=10000;c!=0;--c)
      {
        ;
      }
    }
  }
}

                  SmallLoop PROC
;;;783
;;;784    void SmallLoop(void)
000ba4  e59f211c          LDR      r2,|L1.3272|
;;;785    {
;;;786      volatile int a;
;;;787
;;;788      for (a=10000;a!=0;--a)
000ba8  e1a03002          MOV      r3,r2
                  |L1.2988|
;;;789      {
;;;790        volatile int b;
;;;791
;;;792        for (b=10000;b!=0;--b)
000bac  e1a01003          MOV      r1,r3
                  |L1.2992|
;;;793        {
;;;794          volatile int c;
;;;795
;;;796          for (c=10000;c!=0;--c)
000bb0  e1a00003          MOV      r0,r3
                  |L1.2996|
000bb4  e2500001          SUBS     r0,r0,#1
000bb8  1afffffd          BNE      |L1.2996|
000bbc  e2511001          SUBS     r1,r1,#1              ;792
000bc0  1afffffa          BNE      |L1.2992|
000bc4  e2522001          SUBS     r2,r2,#1              ;788
000bc8  1afffff7          BNE      |L1.2988|
;;;797          {
;;;798            ;
;;;799          }
;;;800        }
;;;801      }
;;;802    }
000bcc  e12fff1e          BX       lr
;;;803
                          ENDP

are r0 r1 r2 r3 all return values? have keil got big code problems? no!

plz wake up and read.

Always yo're freind.

Zeusti.

 RE: Reversed logic

are you sure this code is compiled at ARM mode?

 RE: Reversed logic

Tapeer,.

YES IT IS ARM MODE!

TRY IT UR SELF!

Always yo're freind.

Zeusti.

 RE: Reversed logic

leave the compilers aside. can you provide a quote from the documentation founding your claim? how many times do I need to ask? come on, show us. I'm still waiting. If you can then I am wrong - not the end of the world. but you must show the quote first (I didn't find it).

 RE: Reversed logic

Tapeer.

i told u so many many many times b4 but u seem prejudiced aginst things i say.

look at

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042c/IHI0042C_aapcs.pdf

page 16

A subroutine must preserve the contents of the registers r4-r8, r10, r11 and SP (and r9 in PCS variants that designate r9 as v6).

it does not say must preserve r0-r3. dos it?

why does ity not say r0-r3? bcoz they do not need preserve.

i think i am correct

now plz. u reciover { and maybe apologise }.

Always yo're freind.

Zeusti

(i bare no gruges)

 RE: Reversed logic

I will not provide a quote but in this particular instance you are right - R0-R3 can freely be corrupted at any processor mode (I don't know the M3).

 RE: Reversed logic

Tapeer.

<quote>

I will not provide a quote but in this particular instance you are right - R0-R3 can freely be corrupted at any processor mode (I don't know the M3).

</quote>

u r magnanimous in yo're learning.

Always yo're freind.

Zeusti.

(holding no gruge)

 RE: Reversed logic

I wonder: can you point to anywhere in the document (that you obviously did not read at all!) to prove that I'm wrong? here, I challenge you: take your time, and tell all of us a page number and paragraph number. I'm waiting, "correcting professor".

 RE: Reversed logic

Tamir wrote: "I wonder: can you point to anywhere in the document (that you obviously did not read at all!) to prove that I'm wrong? "

from the point of view of a bystander, I just wanted to point out that you seem to put a lot of emphasis / weight / priority of "proving yourself right". have you ever thought about why that's the case? that sounds like a very insecure person looking for ways to build up self-esteem.

there is nothing wrong with being wrong: it is human to be wrong.

there is everything wrong with refusing to acknowledge and learn from your wrongs: because you stay wrong that way.

if you look at this very thread, there is no shortage of people trying to explain their bogus reasons in order to "prove" their right.

you don't have to be anyone of those people, because you are better, as long as you are comfortable with your wrongs.

 RE: Reversed logic

you see, I have provided a quote which makes you look bad because you made a totally unfounded, repeated and fantastic claim that is (as far as I can tell; if somebody knows better please do correct me and justify the "professor"!) wrong. you showed a piece of assembly that further proves that you don't understand the problem at hand. I am still waiting. show me a quote or a piece of code that proves you point; show me that apart from register R1 to R4 in thumb mode, a program does not need to preserve the processor context (unless the register is shadowed by the mode itself, or course!!!!).
I'm still waiting.

 Cool down the debate please ;)

Based on:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042c/IHI0042C_aapcs.pdf

5.1.1
This paragraph seems to indicate that you need not preserve r0 to r3:

r0 named scratch register 1
...
r3 named scratch register 3

and:
"The first four registers r0-r3 (a1-a4) are used to pass argument values into a subroutine and to return a result value from a function. They may also be used to hold intermediate values within a routine (but, in general, only between subroutine calls)."

the "(but, in general, only between subroutine calls)" seems to indicate that if the called function is visible to the compiler, the compiler can see if any of these registers are unused in the function. For the general case, they are assumed to be destroyed.

This also seems to indicate that r0 .. r3 need not be preserved (still 5.1.1):
"A subroutine must preserve the contents of the registers r4-r8, r10, r11 and SP (and r9 in PCS variants that designate r9 as v6)."

---

Then something about using volatile in loops. We have had a debate about this earlier and not managed to find 100% proof from the C standard what goes.

The AAPCS specifies in 7.1.5 (my emphasis)
"A data type declaration may be qualified with the volatile type qualifier. The compiler may not remove any access to a volatile data type unless it can prove that the code containing the access will never be executed; <v>however, a compiler may ignore a volatile qualification of an automatic variable whose address is never taken unless the function calls setjmp()."

In short, a loop with a volatile local loop variable that doesn't get the address taken may be removed. So volatile doesn't guarantee that a delay loop will survive.

 RE: Cool down the debate please ;)

I know, I just found it myself following the lack of response from our talented peer.

 RE: Cool down the debate please ;)

Tapeer.

'our talented peer.'

respect at last.

ha ha ha ho ho ho

Always yo're freind.

Zeusti.

 RE: Cool down the debate please ;)

I don't know what is worst - making a mistake because I got confused with another process architecture that I used to work with, or writing delay loops that can kill people. I have a guess that you will pick the first option - well, well, well....

 RE: Cool down the debate please ;)

Tapir.

<quote>
I have a guess that you will pick the first option - well, well, well....
</quote>

why do you keep judging the book when you cannot see it?

can u remembar back? when i first sayed you do not need to preserve r0 etc.

i then wrote a delay rootine in ASSEMBELY which you sayed was bad. becoz u sayed i did not preserve registers. { now you learn u do not need to }

today i wrote a loop in c and you compain. but i did it for u for example. bcoz u did not beleive me. i do not normelly write code like it. i did it bcoz i needed to hilite yo're pour understanding of the register useage.

now u know i was right u still try to say i am bad.

u plz read the books. then u 2 can maybe write efficient relieble code.

Always yo're freind.

Zeusti.

 RE: Cool down the debate please ;)

in other words - preserving 2 redundant registers is not going to do any harm to anyone. but writing broken C code like you do - and you brag about it even (making me laugh time after time after time...) is on the verge on criminality in certain circles.

 RE: Cool down the debate please ;)

I have still never seen a compiler remove a loop where the loop variable has been volatile. And I haven't been able to find a sentence in the C standard that clearly indicates if the compiler is allowed to, or isn't allowed to.

But the ARM document seems to say that it is an allowed, but not required optimization.

Another issue here is that you may have delay loops in a program for more than one reason.

One reason may be to make something happen once/second. Such a product isn't likely to get out on the market without you noticing that it runs at 100 times the normal speed because of the lack of delay. Any use of a loop for creating exact delays are a way to sure disaster. Using assembler or __nop() could give a minimum delay, but the loop will not be able to adjust for the interrupt load. Obivously, a timer or similar should be used when actual delay length is important.

The other reason may be to create short micro-delays in the code. You maybe need 30 NOP instructions to let an external signal settle. Using a small loop with a few __nop() consumes less code space than having all the __nop() in a long sequence. For ARM mode, 30 nop instructions would consume 120 bytes. As long as the compiler treats the __nop() as having a side effect it isn't allowed to optimize away, such software loops should be ok, and shouldn't even need any "volatile" on the loop variable. Such a loop will not create a fixed delay, but instead a minimum delay. But that is fine if the requirement is just to get enough settle time on a signal. The extra cycles for the loop instructions or from an interrupt in the middle of the delay can then be ignored.

But the bottom line here is that whenever you design critical hardware - whatever algorithms the program contains - you will have to get the software through a release acceptance test of some form. Such a test is seriously broken if it does not verify all timing means used by the software. It should verify that the real-time clock ticks one second/second with a suitable precision. If changing a couple of source-code lines rsults in a day or a week of testing, a change of compiler, processor frequency or processor model would most definitely not lead to less testing.

The issue with software delays is that the testing may see that the delay is long enough. But it can be hard to get the test to figure out potential problems if the sw delay gets extended to the maximum because of maximum interrupt loads from all possible sources during the delay. Such behaviour will require a lot of theoretical work too since a test rig has limitations.

 RE: Cool down the debate please ;)

Tapir.

<quote>
but writing broken C code like you do
</quote>

books and false judgements agin?

plz read the previes postings

remembar:

u only guess what i do. i know what i do!

Always yo're freind.

Zeusti.