??? 05/26/06 19:01 Read: times |
#117161 - you worry too much about piracy Responding to: ???'s previous message |
in this domain, most of the tools are so bad that nobody would use them unless they had to. Remember, we're discussing Windwos-based tools, for the most part.
If there were any effort made to document precisely what the tools are supposed to do BEFORE they're generated, then it would be easy for the author to produce a consistently upgraded set as the software expands in scope. Unfortunately, at least at KEIL, for example, their marketing/advertising grew faster than their software capabilities. These limitations show up in their simulator and, frequently, in the comments their representatives make, regarding the capabilities of their software. I'm sure the KEIL is an adequate tool for most of its users, but I'm just as sure that there are many people not using it simply because they're disappointed with the difference between the fiction spun by their sales/marketing folks and the realities imposed by their software's limitations. Some years back, I inquired about the capabilities of the KEIL software, particularly its simulator, in terms of computing timing of their work product. This was in the context of the DS89C420, at that time, and their representative told me that they had full support for that chip. This turned out to be a complete falsehood, though I imagine it's been rectified by now. They didn't know, at the time, that there were significant differences between the 80C320 and the 89C420. That's a simple enough thing, but, they clearly operated on unsupportable assumptions. Later I was told that it was IMPOSSIBLE to compute the timing of a set of code in a simulator. This is clearly false, since the simulator "knows" WHERE the code is located, and what the timing at that location is, and it "knows" the operating mode of the MCU. I have simulators that readily do that and which easily simulate timer/counter operation as well as other artifacts of the core. They simply didn't want to admit that they had omitted an important and useful feature of the simulator. One has to praise them, as, at least, they let that bit of information escape BEFORE I had my client buy their software. If they thoroughly/exhaustively test their software, I agree it would be an added cost for them. They'd pass that along, but they probably don't really care whether their work product really works reliably, so long as it appears so. Microsoft doesn't do any better, and, since that's the platform, why should KEIL go to all that trouble and expense? To be declared "reliable," the system has to be tested with every possible combination of bits in memory, on the hard disk, and every possible combination of inputs, to whatever limits are specified. That's how they're tested, with the caveat that, presently, the verified depth of memory is 0, the verified capacity of hard disk is 0, and the depth of the i/o stream is 0. Conclusion, the reliability is 0. It still "works" to some extent, even enough to be useful, but it's really not specified, except in those glittering salesman's declarations that are hard to dispute. RE |