>>One recent post to this newsgroup points out some limitations
of the WindRiver Tornado Debugger in comparison with the XRay
debugger.
Chris Pinkard posted negative comments about Tornado in the NT environment, and lamented the loss of familiar haunts consisting of pSOS and Microtec Research compilers and debugger. He seemed disappointed that his program manager was persuaded to go with Tornado, and is looking for better debugging tools.
Another fellow confirmed what Chris was saying and, after deriding the Tornado GUI, added, "I never personally found any need for a buggy source level debugger that doesn't let you set breakpoints applicable to multiple tasks, so instead I just use the assembly level debugger built into the target resident shell, which works always." However, he did comment at one point, "I think that if all the bugs are worked out, Tornado is a very useful package."
Finally, a third fellow from Israel explained: "This is correct, and I would like to explain the reason. ."If you have two instances of GDB in the same IDE,
the IDE would be confused as to which GDB exactly should receive the
commands when YOU click on the e.g. "Step" button. Besides, I think that
the Win32 API which was used extensively to provide this IDE functionality has some limitation in this respect .The UNIX version does not use an IDE, there each GDB has its own GUI and all tools are independent of one-another."
*******************************************************************************
Unfortunately for Chris, Microtec Research's compilers and debugger are no longer recommended for pSOS - ever since Microtec Research sued INTS for underpayment of VAR license fees, and won a large settlement in arbitration. This, and Microtec's acquisition of Ready Systems were the seminal events probably that forced INTS to attempt to flesh out their tool set through numerous acquisitions. Chris' clear distaste shows for having to adapt to a new environment - that his (incompetent) project leader selected.
Since Chris, as most technicians, is religious about his beliefs, this makes it difficult for us to put his problems into proper perspective, especially if you are not personally experienced with his situation. As an investor, or a manager, you have to weigh this kind of criticism carefully, and take into account the background of the complaining person.
Likewise the next fellow is the kind of experienced embedded systems developer I referred in a recent post - he not only hates GUIs; he despises high-level languages, and jumps comfortably into assembly language at the first opportunity.
The Israeli seems to be positive, willing to work with high-productivity tools, and share his belief that the problem is with the host computer, not Tornado.
As investors, what does all this mean? Is there a problem with GUI's in general, or the Tornado GUI in particular? Is Chris right or wrong? What about the Israeli's explanation. Should we all go back to assembly language? (And everyone keeps talking about introducing objects into embedded systems!)
The answer probably is that everybody is right and wrong, so what's new? Does it surprise me that the Tornado GUI might have some bugs - in its first year out of the box. Not particularly. Does it surprise me that at least on some hosts, the GUI might not incorporate all possible functionality? No, GUI's never do.
A number of years ago a college drop-out insisted that a buggy, graphics interface was so important, even on under-powered computers that command line interfaces had to be abolished. Everyone complained endlessly. I remember at least one serious attempt to peddle an alternative windows system that was graphical looking, but based strictly on characters, so it could run efficiently and much less buggy on all the under-powered computers of the day (I think it was GEOS). But Bill Gates, virtually alone, insisted, and now we have the third, or fourth, generation, Windows 95, and we have all adapted and appreciate his vision of the value of a bit-mapped interface. Notice that it didn't matter one whit that initial versions of Windows was buggy to a fault, followed by merely buggy Windows 3x, followed by a not quite robust Windows 95. It didn't matter because Bill was mostly right, and all the bugs and inefficiencies were just nuisances. It was enough to define an environment that everyone could either contribute to or use, and which had ADEQUATE capability for most things. Frankly, the character-based alternative sacrificed efficiency and simplicity for graphical capabilities that soon proved essential.
Tornado is conceptually powerful. Through its open API, a plethora of tools from third party vendors can be plugged in with little effort. By an ingenious trick, a production-sized target can be accessed by virtually any debugging tool. The Tornado GUI pulls it all together, making project development quicker and easier using the high-level tools.
Sorry about the bugs. I guess this is the necessary price of progress. Let's hope WIND gets most of them fixed faster than the decade Microsoft spent mucking around with Windows. In the meantime, I would hope the high-level development environment would enable rapid development and initial testing of application code - let's say 90% of the project. The remaining 10% may require work-arounds, requiring the penetrating analysis of the assembly language and command-line interface types, such as the two fellows discussed above. This is still better than having to do the project that way from scratch.
Is this the end of it? Can we investors simply ignore the fact that bugs have been noted. No, this is why we pay so much attention to endorsements by credible organizations. This is why Intel's selection of Tornado for IxWorks is important to us, not just the anticipated royalties from the I2O chip. This is why we appreciate the Oracle NC design win, and all the telecom wins, etc. This is why we observe comp.os.vxworks - and note that comp.os.psos currently is missing. This is why we note the number and substance of the Tornado partners, and growing number of Tornado users.
We know that professional preferences and opinions almost always reflect the persons experiences with particular hardware and software. We listen, but we have to always look deeply and weigh carefully both negative and positive comments that affect our investments. We then make a judgment, and revisit that judgment with each piece of new information.
For these many reasons, I think we need to limit anecdotal evidence of the kind taken from comp.os.vxworks. We simply are not equipped to properly interpret this level of opinion, nor should we even try in this context. I have heard negative comments about every leading RTOS vendor's products, which I think about a lot, but never repeat. I rarely doubt the integrity of the person making the comment, but I always consider that person's allegiances.
Incidentally, throughout this and the reference post, we are discussing bugs in the development, host environment, not VxWorks. One trusts that Pathfinder on its way to Mars is not laden with bugs. VxWorks in Orbital Sciences satellites should be virtually bug-free. And I don't think GM expects to deploy buggy fuel-injectors in diesels vehicles a year from now. Personally, I am pleased with the robust performance of HP's Deskjet printers.
Allen |
