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!
mista mikal,
you is being proudly of tamer is you being yes?????
you be started warrring of erac and jak agin!!!!!!
you be hanging marow on his string for the mans to atack the fight yes????
Kalib, The only thing I see is a well-argumented, intelligent discussion, from which there is a lot to learn. War? I don't think so. Disagreement maybe, but that is the foundation for any progress!
Wow, amazing how this thread grew. I shouldn't go away for a "3.5-day" 'weekend' (remind me not to get sick again). I point this out because reading what I missed did expose the need to keep all comments 'at the bottom' since all of these posts were 'new' to me... "Given that new posts are highlighted I don't see how that would offer any real benefit"
Ditto to the posts above. (most of them)
ALL embedded code--and an argument can be made for all code--will have non- Porta-Code constructs. Typically the smaller the processor power, the more the PortaCode suffers. Hence, an over-clocked hyper-extreme Octa-Core ubercomputer ALMOST has the luxury of implementing the purest of standardized language programming compliance, while your C compiler for the 1802 COULD take on some contorted coding.
Much of 'it' depends upon your requirements.
Generally what I mean by smaller processor power includes restricted (under-specified might be a better description) resources like program space, data space, MIPS, FLOPS, core-processor capabilities (e.g. no intrinsic 'divide' instruction), and/or requirements that have grown beyond the original design.
But it still goes beyond that. Just because you think you have an under-powered system doesn't mean that it needs to change. A change could spell the doom of the project, so you shall need to squeeze those CPU cycles (period). So much of the real-world applications pressure the software to make up for the deficiencies in system design, mechanical design, and electrical design. Sometimes it is the correct location to apply that pressure and sometimes its not.
The 'doom' of the project could be a simple parts-cost increase that will force your product to cost more, hence won't sell, hence won't need to be made, hence your company folds, and hence you will get the opportunity to find out how 'generous' your company really is.
Or,it can mean that your product now needs to get re-qualified with the 'new' design and that requires far more than can make the project viable, and hence ... (see the hence list above).
Or, this sudden realization that your processor is under-powered could cause you to lose the window of opportunity to have a product:
You are responsible for the new Indy 500 race-car telemetry system, and the re-spin of the board will cause the contract to loose one week and with the help of the team's over-time, the product will be ready exactly 2 business days after race-day. For some reason, the customer will not pay you. Or that Shuttle Launch, or aunt Sally's annual bridge game and her dazzling LED intermission light-show.
In order to determine if the real problem is an under-powered system or something else, you must look at the bigger picture than just the computing power of the CPU and the efficiency of the compiler, but also the other 'intangibles' from a management perspective: unit cost, project cost, maintenance costs, long and short term IP value, and resource costs. Not to mention the other impacts on a system's performance like how long your LiPo battery powered underwater fish tracker will last using software driven floating point 8051 algorithms or that floating point Ti DSP micro.
This is why "Per Westermark", "erik malund" and "Tamir Michael" are 100% right (in all of their posts). You must design your systems with an eye for expansion in both hardware capability and software capability. The most capable software --for expansion/portability/etc-- complies with a standardized language as both the tool vendors and CPU architects know that their products will be implementing a standard language. Stick to it as best you can, but don't fool yourself, you SHALL be deviating from the purest (most portable?) code.
And when you do, you not only have to be smart enough to know it (e.g. knowing that a count-down is quicker than a count-up), but you must be diligent enough to make note of it for when that 'new-guy' takes over the code.
The compiler [and even chip] vendors know that deviations to a standard shall take place, and they try their best to make as many of the non-standardized (and thus non-portable) implementations as logical a possible, and hopefully with minimal impacts (the origion of #pragma comes to mind).
Yes, these vendors want their competitor's customers to easily switch to their tools/chips, so they'll attempt to make it as painless as possible. Sticking as close to a standard helps force the focus onto quality, features, and price... just like you/we should be doing.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
P.S. erik,
WordStar, to Brief (by Underware), to CodeWrite (using Brief Emulation). I've used 'other' editors, but I'm totally hooked on CodeWrite too (alas, only V6.0c though). Its nice to see I'm not the only CodeWrite addict out there.
WordStar, to Brief (by Underware), to CodeWrite (using Brief Emulation). I do believe you mkean CodeWright
there is, I believe, also an editor named CodeWrite.
Erik
Doh! Yup. I mkeant "CodeWright." Don't you just hate that?
This is why "Per Westermark", "erik malund" and "Tamir Michael" are 100% right (in all of their posts).
In all of their posts?
Wow, how much higher praise could one person give to others?
The three masters are all totally infullable.
Whoops I, of course, mean infallable.
And don't Jack Sprat, Christoph Franck or the numerous other people warrant a mention of some sort?
1) I am sure Vince referred to this thread only. 2) the fact is that much 'discussion' comes from viewpoint differences
Johnathan, Alright, I am prepared to share some of my glory with you :-)
Of course. And they do it because they are on a mission, or they enjoy embedded programming or feel a responsibility toward younger, less experienced developers. Or maybe it is something else. After all, what is point in knowing if you don't share it? I am sure each and everyone here has a good reason to make his own worthy contributions to this forum. Let's keep up the good work!
My apologies.
I wanted to point out how those people, in particular, were addressing the exact issues I was bleating on about, but they were doing it in a different way that I was.
If you look at the quantity of those three versus others you'll find that 'the others' weren't the heavy hitters here (not that those people aren't heavy hitters, just not on this thread). This forum has some very good regular contributors among the fray of 'students' and the general OMG! Class of participant.
And yes, I was talking about this thread and not their life's work on this forum.
Several heated debates, but no real "wrong" opinions.
I think the three (?) debates in this thread can be milled down to something like the following:
Writing portable code costs extra time. Writing non-portable code costs extra time.
Optimizing for a processor you don't have doesn't give anything. Optimizing for your specific processor means that you may be locked into a deficient design.
Selecting too big processor can kill a project. Selecting too small processor can kill a project.
In the end, it is a question of view, and of company policies, and volume of the product etc. The only thing that is known is that portability is not simple.
A small very partial list of stumbling stones, that can make "portable" hard to really manage: - Unix, Win32 or .NET. - 8-bit or 64-bit. - Little-endian or big-endian. - 8-bit or 9-bit characters. - Two-complement integers or sign bit. - von Neumann or Harward architecture. - uA batteries consumption or mains-powered. - Single-instruction or vector-based instructions. ...
The target environments and hardware can vary so much that there can never be "one" solution. It is so easy to think that a program can always be written in a portable way - but how fun is it really to have an algorithm that works with 36 bit integers and 9-bit characters? How many trivial lines of code would break? Anyone done (x & 0xff) and assumed a specific behaviour?
Since we can't really write the ultimate portable program, we can argue, and debate and sometimes fight a bit about what parts of "portable" that are best to think about, and exactly what weight we should give to the problem, compared to all other design decisions we have to make to manage to produce a working and sellable product that people actually want to buy.
With so varying architectures (just compare C51 to an ARM7...) it is hard to discuss specifics. An ARM chip can use a recursive algorithm, and the algorithm can be very easy to read, understand and maintain. And it would be portable to just about any processor in this world. But it would be a lousy solution for a C51 user.
But on the other hand - writing a C51 program without taking advantage of bit operations would be the ultimate stupidity, since it would waste one of the main reasons for a C51 processor.
Since there are no single correct solution, the bottom line is to think and make educated decisions. And to document them - what the decision was, and (quite important!) why it was taken.
And always remember that the price of a chip is not proportional to speed or number of supported peripherial devices. Fighting to fit everything into a tiny processor should be done because you can make 10 cent extra times 100k units, not because someone made an oops when selecting the processor.
Alas, too many products are victims of the oops design methodology...
Anyone read any threads where the OP is doing a "real" commercial job, but don't know how to read the processor documentation? Anyone think they selected the correct processor if they didn't read the documentation before selecting it?
Per, You wrote: Anyone think they selected the correct processor if they didn't read the documentation before selecting it?
these thing do occur, alas, as we all know. A couple of overseas managers are now considering switching to Linux because it seems to support some powerful processors that Windows CE does not support (yet). The problem is the performance of a system that sports a powerful MX processor. They don't even consider revising the software, which needs a) rewritng by people who know what they are doing b) careful, controlled maintenance
but instead they plan to replace the RTOS and change the prcorssor, without fully understanding the costs in terms of compatibility and maintenance. Again - shocking.
Tamir Michael wrote: "They don't even consider revising the software [...]"
I feel for you. Political decisions can be even worse tha uninformed decisions made by developers.
When "management" makes a political decisions, a number of people who know the problems will then have to "make do" and try to make the best of the situation. Foolish developers who make bad decisions because they don't read documentation or plan their design in advance will at least have to suffer the consequences themselves.
...
Per, You nailed it. (...and so did erik, Jack, Tamir, Johnathan, kalib, Dan, David, Paul, Christoph, and that other guy who started to click 'reply' but didn't).
When "management" makes a political decisions, a number of people who know the problems will then have to "make do" and try to make the best of the situation.
Wow, that reminds me of a horror story...
[WARNING: OFF-TOPIC RAMBLING]
Years ago, I worked on an electro-mechanical project which was bid on by a manager who was NOT a systems, mechanical, electrical, or software engineer. He once programmed a PIC to read an ADC and UART it out. I think he once slept at a Holiday Inn Express too. Which obviously made him qualified to be the engineering manager.
Unlike all other managers at the company, he didn't consult any of his staff of highly qualified expert engineers, and submitted this bid solo. The multi-million dollar bid was accepted, and contracts signed.
Due to his total incompetence, he under-bid the contract by half. AND THEN he realized that software would ALSO be required to control the system... the project was based upon the fact that it was The First Computer Controlled System of Its Kind... so it's no wonder he forgot to bid the software.
It was then up to 'us' to make it happen. I was responsible for the control electronics and the system's software. I quoted 12 months for the software alone. He freaked out: "it had to be more like 3 or 4 months!" (to coincide with the completion of the control electronics: see a conflict? Sherlock didn't)
After I got the control electronics up and limping, the first software task was the Serial Communications link. I quoted one month to complete it; with 11 more to go. Being the genius he was, he just changed the Gantt chart duration from 20 [work] days to 5 and thought that would fix his schedule problem. Looked good on paper! AND the logic cuts a 12-month schedule by 4 to bring it in line his 3 month development schedule. It's elementary my dear Watson.
On day six, he yelled at me for it not being completed. He continued to do that until I got the comm finished. It took me four weeks. And only one day longer than the 20 days I estimated.
My clear failure to meet his schedule infuriated him, so he took me off the project and handed the job to another engineer. This action was done in retribution to me because it was supposed to be embarrassing to be kicked off a project. <sarcasm>I was SO embarrassed</sarcasm>.
The 'other' guy was more experienced in the contract-required language than I was. (If I was the project manager, this other guy would have been my first choice, and not me).
That 'other' engineer then had to provide a quote on how long it would take. After a week of analysis, the new and improved schedule estimated by the 'other' engineer took "Eleven Months." Curiously, it was just one month short of my quote, now that Serial Communications link was completed.
After that Mr. Genius did a couple things: 1) he de-scoped the functionality of the system, and 2) during telecons, he made us lie to the customer on schedule status items. "We didn't lie," we 'just' evaded the truth.
Q: "So where are you on the schedule?" A: "I don't have the schedule with me now, you'll have to contact Mr. Genius to get an accurate fix on that."
The customer started to figure out that our answers were being evasive, and they happened to be smart enough to know that we were being forced to be that way.
Note: A funny thing was that this project was recently on a TV program on -uh- 'cool stuff' and they touted "This is the only one in the world" as if that fact was something special. It was the only one because of Mr. Genius. I guess the customer was still re-evaluating the follow-on production units.
The Lesson: When managers don't take the advice of an engineer on an engineering project, everybody suffers. My advice is to let the powers-that-be know that you have "serious concerns with the errant manager decision(s). That idiot manager will eventually be looking for a scape-goat, so get it on record before he looks around at his herd of potentials. (no, I wasn't the scape-goat on that project, but I had to live with the wrath of the idiot).
Give those concerns in writing, and keep a copy. When the superiors ask about "anomalies," make a harmless reference to your initial concerns like, "at first I didn't think it was possible, then I had a brief glimmer of hope, and now I'm back where I thought it was... nothing has changed since I gave you that list of concerns I have."
This should remind them that you were on the Correct Side of the problem as it compounds itself... but don't hammer the "I told you so" too much. You'll look like The Grumpy One; ripe for a scape-goat slaughtering.
By the way, that "just lie to the customer" edict wasn't phrased that way. It was stealthy and he just required that we "didn't reveal the actual status of the schedule." This way he didn't have to tell us "You guys need to lie about the schedule." (We had weekly telecons on status an issues).
When I confronted him with the "But what if they ask about it directly?" He responded with "change the topic or tell them you don't have all the information yet, or that you'll follow up with that later."
If this happens to you, keep challenging the edict until it is forced into the light: "So, you need us to lie to the customer?"
This guy was directly opposite to what our company's reputation and what we stood for.. His shenanigans were not in view of his bosses and peers. Mr. Genius was not typical. He was eventually "removed from the position he held" when one of his peers witnessed him 'in action.' That brief period of 'evasiveness' caused much fall-out and consternation within the company. Don't ever let one of those deviants alter your code of ethics. Ever.
Per Westermark wrote: Foolish developers who make bad decisions because they don't read documentation or plan their design in advance will at least have to suffer the consequences themselves.
It is a totally different feeling when you do it to yourself versus when somebody else does it to you. (oops, off topic again).
My advice is to let the powers-that-be know .... That idiot manager will eventually be looking for a scape-goat, so get it on record before he looks around at his herd of potentials. I once made a machine control system that was to be bilingual. I documented that I did not speak spanish and had inserted other messages to test the code. A salesman requested the prototype for a demo and again I documented that it was not ready and he could not have it.
Of course, being a marketeer, he went in one night and took the unit and went to the customer with it.
Imagine his furor when he found out that 'exit' in "Spanish" was "F... Off".
Having everything documented, I could not be made the scapegoat.