??? 06/18/09 13:11 Read: times |
#166221 - Andy's right! Responding to: ???'s previous message |
Andy Neil said:
Andy Neil said:
... it would certainly be sufficient to prevent most of the problems that people bring to this and other forums... Jez Smith said:
Being able to list every nemonic and its equivelent hex code doesn't stop people from asking for code. True, but that's not what I was thinking of. I was thinking more generally of people who post problems, and their problem is due to the fact that they've assumed that they can just write 'C' like they do on a PC - whereas, if they had even the faintest understanding of the underlying 8051 architecture, it'd be obvious why their code didn't work. Yes, that is a digression from the topic of this thread. Of course, someone with sufficient commitment to learn every nemonic (sic) and its equivelent hex code is also likely to be able to do their own googling and not need to just ask for code... It wasn't my intent to suggest that nobody who couldn't remember the mnemonics and their hex equivalents for every MCU he used was incompetent, or otherwise unable to generate embedded code. I did, however suggest, in agreement with Andy, that one who could do that certainly wouldn't generate the sorts of questions that often come up among the many "gimme code" discussions. If a fellow can do the job in ASM and it's foreseen that there will be extensive ongoing product code maintenance, as opposed to complete redesign in later revisions, then it is probably a good choice to use HLL. Most of the "gimme-code" questions are really "do my work and my thinking for me" questions. Some are not. I won't deny that some are legitimate questions from people simply wanting to look at functional examples of solutions to a specific problem. The easiest way to filter those out of the global rejection of "do my work" queries is to ask, "What have you done so far, and what's the problem? There have been many threads, some quite long, (remember that scrolling LED matrix thing from the fellow in Egypt?) at the end of which it was clear the O/P had done nothing, or very little of his own work, was able only to quote the work of others, which he failed to understand in even the most basic way, and kept returning to the demand for "something that works." OTOH, there are occasional threads started by one fellow in Brazil, who's clearly an active hobbyist, who wants to do something and has some background experience, and has a history of doing things, AND asks questions in a way that makes it apparent he's done something already. Oddly enough, the latter is a case where the O/P actually seems to understand and benefit from the wide range of suggestions that are presented, and seldom makes demands/requests for "something that works," choosing instead to ask "what should I be looking at/for in this case?" Surely one can appreciate the difference! Now, Andy has also pointed out my principal objection to the use of 'C' on MCU's by people not experienced in programming those same MCU's in ASM. Doing the job in ASM requires an understanding of the architecture and the specifics of the hardware environment, including the oscillator frequency and the way in which that specific MCU handles it. A recent thread regarding delay loops and 'C' demonstrates what I mean. My position remains that, if a programmer can write code that successfully accomplishes a task in ASM, then he can do it. Whether he does it in 'C' or Pascal, or even BASIC, doesn't matter, because he knows how to do it. Most of the queries we see here are presented by people who don't know how to do it, yet expect that the compiler will know. The compiler neither knows, nor cares! If one can "get the job done" in HLL without requiring a larger code memory or faster MCU than would be demanded by ASM, then HLL is fine. If one needs to double the clock speed, thereby requiring a more costly MCU, or if one needs the next-larger size of internal code space in his MCU, then it becomes a business decision, which engineers aren't supposed to be making. HLL will make ongoing support easier, hence, and probably less costly. Again, however, that's a business decision, and not an engineering choice. RE |