| ??? 10/16/09 16:45 Read: times |
#169799 - That's not what I meant ... Responding to: ???'s previous message |
Andy Neil said:
Andy Neil said: Real life just doesn't divide cleanly like that - with clear, black-and-white dividing lines between "hardware" and "firmware" and "software" (however you define those terms).
Richard Erlacher said: It's no problem differentiating between problems with the development tools and the other two categories. That may be true in many cases. However, the problem itself may not be with the development tools - but the application of some specific feature(s) of the development tools may provide a solution to the hard/firm-ware problem. That's quite true, but it's not what I meant. There are frequently development software "issues" that come up, for example, "How can I make <THIS (commented and properly formatted code listing goes here)> code, that seems to work under SDCC, work under KEIL ..." or some such, or "How can I exercise <THIS> code with <THAT> tool? Then too, there's the ever-popular, "How can I write precise timing loops in <insert 'C' compiler name here>? I think there would be just too many "overlap" cases where it wouldn't so clear whether it's "hardware" or "firmware" - the very nature of "firmware" is, after all, that it's close to the hardware. There will be cases where there's overlap. However, the person posting the query will generally have a good sense of where the problem lies. With beginners, students, fools-of-all-sorts, etc, all bets are off, of course, but the main thing is to force them to assign a category, and then WE (I'm not sure what WE means at this point) parse their assigned post for the telltale evidence, namely code listing, schematic, or reference to a named development tool. If it's listed as a firmware problem, it should included a code listing. Sure - but the listing may be meaningless without the schematic! e.g, a lot of new posters think they have a firmware problem because their LED won't blink - when it's really a hardware problem because they've connected the LED wrong! I know that's a trivial example, but I've had cases where I've been convinced it was one, and it turned out to be the other! From what I've observed, the question is normally the other way around ... i.e. they think there's a hardware problem when, in reality, they've not driven the thing correctly with their firmware, either in timing or in port pin selection ... or some-such. When they say things such as, "I've used an oscilloscope, but there appears to be no action on the port pin," or the port pin <Pn.m> is always at a <high/low> level ... " You know it's probably a firmware issue. After all, they know enough and have worked enough to use an instrument. If they provide a listing that looks correct, then, even today, they are prompted to include a schematic. If the schematic looks correct, then they can be prompted to provide a complete commented code listing. That's done today, too, yet, oddly enough, it takes five or six recommendations that they comment and format their listing just to get many of them to do that. Posting schematics is a problem because there's no "standard" format for schematics on 8052.COM. Often, of course, they've not yet written any code, nor have they even thought about selecting an indicator and driver circuit. They want a packaged solution from 8052.COM's "experts." RE |
