FYI:
Doing a search at AltaVista on "vxworks" provides many
links (over 16,000) and information about the realtime
embedded software marketplace in which WindRiver competes.
In my last post I said there were Newsgroups for realtime
programmers. It turns out that there is one Newsgroup devoted
to WindRiver/Tornado users. It is comp.os.vxworks.
One recent post to this newsgroup points out some limitations
of the WindRiver Tornado Debugger in comparison with the XRay
debugger.
Dave
-------------------------------------------------------
From: Christopher Pinkard
Newsgroups: comp.os.vxworks
Subject: debugging multiple tasks
Date: Mon, 16 December 1996
Organization: Lawrence Berkeley Laboratory, Berkeley, CA
Fellow Travelers,
It's been 6 years since I worked with VxWorks at the MR
group of GE Medical Systems. Debugging used to be easier,
but I don't remember what tools we were using. The last
three years I've been working in PSOS on Moto MVME boards
and using Microtec Research compilers and their XRay
debugger.
Now, I'm back in VxWorks with Moto MVME boards using the
"highly acclaimed" (by whom I don't know) Tornado develop-
ment environment. This is so far this biggest single hit
to my productivity I have ever encountered. My colleagues
and I have a list of a dozen grievances about using Tornado
ranging from very irritating to user vicious, for example
the editor, which only emulates Notepad (with colors).
The overriding problem that is not even on the list because
it is so fundamental is the ability to easily debug several
concurrent tasks. This was so easy using XRay, I had
forgotten it was an issue. Tornado does not appear to be
a giant leap forward in this most basic need for a real-
time multitasking development tool.
The first line of support at WRS (as far as I have been
able to penetrate) has not given any satisfactory answers.
I want to do something simple, like put a breakpoint in a
background task, after it wakes up from pending on a message
queue. Then I want to step through the task that sends the
message, and have the background task break when it receives
the message.
WRS suggests that I detach from the first task and attach
to the second task to set the breakpoint. Then detach from
the second one and attach back to the first one. However
detaching seems to wipe out all breakpoints, and it will
put the task on the ready list, so it takes off. Their
next suggestion was to put some debugging semaphor in the
first task, and have it pend just before it sent the message.
Then detach from it and attach to the background task.
Put a breakpoint where the message will be caught, then
send the semaphore from the shell command line. Not what
I would call a "productivity enhancing" solution for the
general case.
Our program manager was persuaded to go with Tornado, and
we have NT development systems with VxWorks Motorolo VME
targets. This may limit the tools available. If anyone
can help with the names of some better debugging tools for
this setup, we would greatly appreciate it. If anyone knows
how it can be done using Tornado, even better.
many thanks,
CP |
