Hello, I was browsing through older posts that deal with the painful issue of portability (http://www.keil.com/forum/docs/thread8109.asp). I was (and still am) a big advocate of programming as much as possible conforming to the C standard, and having a layered structure that allowed "plugging-in" other hardware. But I have come to change my mind recently. I am reading the "ARM system developer's guide" (excellent book by the way. I'm reading it because I want to port some C167 code to an ARM9 environment) in which chapter 5 discusses writing efficient C code for an ARM. The point is, and it is fairly demonstrated, that even common, innocent looking C code can either be efficient of very inefficient on an ARM depending on specific choices made, let alone another processor used! So, if we are talking about squeezing every clock cycle out of a microcontroller - I do not believe that portability without ultimately littering the code is possible!
The only reason I can see for "changing tool vendors" would be that you made a mistake initially and bought bug-ridden tools.
For the 8051 I've used Intel, Archmedes, Avocet, IAR, Whitesmith, BSO-Tasking, etc, etc, and Keil assemblers/linkers/compilers. (Yes, I know they're all practically derivative works from each other). So I'm familiar with variations in implementations of the "C" standard (and even then, "C" was evolving). So yes, they were all bug-ridden tools and we [the industry] corrected that mistake as the tools got better, companies changed ownership, and technology improved. (Just a guess, but I'll bet that pattern will continue in the future).
Other reasons include:
Your company might decide to change tool suites for bizzare reasons like the new tool set comes with a neat-o key-fob the boss wants so he mandates that the new tool IDE will now be Crapoli Version 1.03 by Off-Brand Corp.
Or, you don't want to be forced to find that old Keil uVision 1.03 compiler in order to add a small feature to an old product.
Or, your company gets bought-out by Big-Fish Incorporated, and they have the new wiz-bang mega-buck tool set. Your code now needs to comply.
Or, you are doing work for the government and they want to make sure that it can be re-created ten or twenty years from now. And they don't want to resurrect Archimedes Inc just to recompile the code.
Or your product, and the associated code, might be sold to a company that uses XYZ and not your company's ABC.
Or, if you do contract work, company X might expect your source code to work on their XYZ compiler... but you use the ABC's compiler at home.
Or, you are a veteran engineer who has a library of tried-n-true code snippets that are qualified to the nth degree, and you want to be able to use them even though ARM was bought-out by Altium and Keil was summarily killed because it conflicted with their IAR products. Altium then gets purchased by the newest CAD mega-giant CEIBO, but CEIBO becomes merely a pawn in the Microsoft vs Apple war of 2012. The US government wins that war by seizing all the assets of both companies and now, by law, you are compiling your code using Oracle Corporation's UberBloat "C" IDE. You never know what is going to happen... code defensively.
If you have project 'x' running with tools 'a' and switch to tools 'b' what is hindering that you maintain 'x' with a'
If you ensure that the development tools are also archived with each revision of code, then you shouldn't have a problem with 'x' and 'a' but since that is not always the case, nor is it always do-able because of licensing problems, I would say that time hinders it.
erik, I do agree with you on the "udder stupidity" of the 'help-desk'!
They don't get the engineering environment like we do. The word processor's upgrade will still read those old documents just dandily, why won't the IDE also be able to read the ".C" files? Remember, they're not engineers for a reason.
LOL-- the mechanic finds the culprit: root cause fixed and documented with a chalk outline.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA