views:

1787

answers:

4

I've been working on an embedded C/C++ project recently using the shell in Tornado 2 as a way of debugging what's going on in our kit. The only problem with this approach is that it's a complicated system and as a result, has a fair bit of output. Tornado 'helpfully' scrolls the window every time some new information arrives which means that if you spot an error, it disappears out of site too quickly to see. Each time you scroll up to look, the system adds more information, so the only way to view it is to disconnect the hardware.

I'd love to know if anyone has a way of redirecting the output from Tornado?

I was hoping there might be a way to log it all from a small python app so that I can apply filters to the incoming information. I've tried connecting into the Tornado process, but the window with the information isn't a standard CEditCtrl so extracting the text that way was a dead end.

Any ideas anyone?

[Edit] I should have mentioned that we're only running Tornado 2.1.0 and upgrading to a more recent version is beyond my control.

[Edit2] The window in question in Tornado is an 'AfxFrameOrView42' according to WinID.

+1  A: 

I am making the assumption that you are using the host shell to perform this.

If you are running a test by launching it from the shell like "runTest()", you can use the redirection operator (>) to send the output of that function to a text file on your host machine.

 > runTest() > mytestResults.txt

This will save any output that runTest generates to the file mytestResults.txt

If you would like to capture everything on the screen all the time, I will have to dig more into this.

Benoit
I gave this a try, but the command we use to launch our system launches a new task and as a result, we don't see any of the output we're interested in.I think we need to capture everything for the solution to really work..
Jon Cage
Is the missing output showing up in the host shell at all? or is it showing up on the serial port (i.e. kernel shell)?
Benoit
I'm connected in remotely with a shell from Tornado on my local machine and I can see all the output on that shell. If I check the log file though it only contains data from the function I started from (and not the spawned task).
Jon Cage
Dunno...tried the ?shConfig RECORD on ??
Benoit
Yes, I tried that, but because I'm using Tornado 2.1.0 the options have no effect. I think they were introduced in a later version(?).
Jon Cage
+2  A: 

The host shell has a recording capability built in. There are 3 environment variables available (in 6.x, I also assume in 5.x):

RECORD (on/off) : Controls recording of the shell
RECORD_TYPE (input/output/all): Determines what you will be recording
RECORD_FILE : Filename to save things to.

you use the ?shConfig command to configure the shell environment variable. ?shConfig by itself displays the variables. Here is how I set mine up:


-> ?shConfig
...
RECORD = off
RECORD_FILE = C:/test.txt
RECORD_TYPE = output
...

-> ?shConfig RECORD_TYPE all
-> ?shConfig RECORD_FILE myData.txt
-> ?shConfig RECORD on
Started recording commands in 'myData.txt'.
Benoit
I don't think these are part of 5.x.
Chris Cleeland
A: 

rlogin vxWorks-target | tee redirected-output.txt

Ben Collins
Could you elaborate where the rlogin command is entered?
Jon Cage
I believe the assumption here is that vxWorks itself has the rsh component enabled. This wouldn't work in the host shell.
Benoit
That won't work for our setup then unfortunately.
Jon Cage
+2  A: 

here is another potential way:

-> saveFd = open("myfile.txt",0x102, 0777 )
-> oldFd = ioGlobalStdGet(1)
-> ioGlobalStdSet(1, saveFd)
-> runmytest()
...
-> ioGlobalStdSet(1, oldFd)

this will redirect all stdout activity to the file you opened. You might have to play around with the file name of the open to make it write on the host (e.g. use "host:/myfile.txt" or something like this)

Benoit
While not as neat a solution as I'd have liked, this seems to be the best option right now. Thanks for all your suggestions Benoit :-)
Jon Cage
this may not be the "neatest" solution, but it's the one I've used in years past and I know it works.The newer workbench (3.x) supports this kind of stuff better, but that probably won't help you.
Chris Cleeland