Hey All,
I don't want it to stop all tasks in the debugger.
Instead I'd like ONLY the task that calls it to block.
Any ideas on how to change the behavior of scanf would be greatly
appreciated.
Thanks,
Tom
_____________________________________
Change behavior of scanf in the ccsv5 debugger.
Started by ●April 15, 2012
Reply by ●April 15, 20122012-04-15
Tom-
> I don't want it to stop all tasks in the debugger.
>
> Instead I'd like ONLY the task that calls it to block.
>
> Any ideas on how to change the behavior of scanf would
> be greatly appreciated.
Are you using scanf to read the PC keyboard? If so, then scanf (and other console I/O) is occurring through your JTAG
connection, which can be very slow, and likely to interfere with real-time debug. You might want to implement
something like a user I/O switch on your board that your code reads as a flag to enable/disable scanf() calls... i.e.
a flexible way to disable console I/O during debug.
One reason I suggest this is that if you want to modify behavior of JTAG based scanf() you might not get a lot of
suggestions, either on tech groups such as here or on TI-hosted forums, because it's not something that typically gets
used in production code.
If, on the other hand, you're doing console I/O with a device on your board (not over JTAG), that's a different story.
-Jeff
_____________________________________
> I don't want it to stop all tasks in the debugger.
>
> Instead I'd like ONLY the task that calls it to block.
>
> Any ideas on how to change the behavior of scanf would
> be greatly appreciated.
Are you using scanf to read the PC keyboard? If so, then scanf (and other console I/O) is occurring through your JTAG
connection, which can be very slow, and likely to interfere with real-time debug. You might want to implement
something like a user I/O switch on your board that your code reads as a flag to enable/disable scanf() calls... i.e.
a flexible way to disable console I/O during debug.
One reason I suggest this is that if you want to modify behavior of JTAG based scanf() you might not get a lot of
suggestions, either on tech groups such as here or on TI-hosted forums, because it's not something that typically gets
used in production code.
If, on the other hand, you're doing console I/O with a device on your board (not over JTAG), that's a different story.
-Jeff
_____________________________________
Reply by ●April 15, 20122012-04-15
Tom-
> I appreciate your comments.
>
> Here's what I ended up doing ...
>
> On the DSP, fopen a file on my C drive which is going to contain my CLI input.
> Using a conditional compilation (#ifdef MYSIM" to change my my uart byte read to use a fgetc() to get the next
> character from the file. Test if it is EOF, if not process it the same way I would on the HW.
>
> Also with conditional compilation change my putbyte() to use printf("%c", &c). The output goes to the cCCSV5 console.
>
> Now in a Cygwin window when I wasn't to issue a cli command, I do
>
> Echo help >> cmd.txt
>
> Works just great for debugging various cli commands. Ultimately I'll have to test my load on hardware, but there's
> lots of behavior that can be conveniently tested on the cycle-accurate simulator.
Ok you didn't mention simulator in your OP... I'm not sure what CCS does with console I/O and file I/O when running
simulations. For real-time debug, JTAG is used... and there are lots and lots of posts out there about JTAG related
issues, as real-time debug on actual hardware is the crucial task. One thing I can say for sure is that the CCS
simulator does not attempt to simulate JTAG delays, otherwise people would have an easier time of it when they reach
the hardware stage.
As you reach hardware test, you might want to keep in mind that fgetc will use JTAG. One possible "JTAG-free" method
is to download the CLI text file ahead-of-time, in some unused area of DSP mem, then read that mem area using a
modified function (maybe mgetc, hehe).
-Jeff
> -----Original Message-----
> From: Jeff Brower [mailto:j...@signalogic.com]
> Sent: Sunday, April 15, 2012 2:51 AM
> To: c...
> Cc: Tom Denesyk
> Subject: Re: [c6x] Change behavior of scanf in the ccsv5 debugger.
>
> Tom-
>
>> I don't want it to stop all tasks in the debugger.
>>
>> Instead I'd like ONLY the task that calls it to block.
>>
>> Any ideas on how to change the behavior of scanf would be greatly
>> appreciated.
>
> Are you using scanf to read the PC keyboard? If so, then scanf (and other console I/O) is occurring through your JTAG
> connection, which can be very slow, and likely to interfere with real-time debug. You might want to implement
> something like a user I/O switch on your board that your code reads as a flag to enable/disable scanf() calls... i.e.
> a flexible way to disable console I/O during debug.
>
> One reason I suggest this is that if you want to modify behavior of JTAG based scanf() you might not get a lot of
> suggestions, either on tech groups such as here or on TI-hosted forums, because it's not something that typically gets
> used in production code.
>
> If, on the other hand, you're doing console I/O with a device on your board (not over JTAG), that's a different story.
>
> -Jeff
_____________________________________
> I appreciate your comments.
>
> Here's what I ended up doing ...
>
> On the DSP, fopen a file on my C drive which is going to contain my CLI input.
> Using a conditional compilation (#ifdef MYSIM" to change my my uart byte read to use a fgetc() to get the next
> character from the file. Test if it is EOF, if not process it the same way I would on the HW.
>
> Also with conditional compilation change my putbyte() to use printf("%c", &c). The output goes to the cCCSV5 console.
>
> Now in a Cygwin window when I wasn't to issue a cli command, I do
>
> Echo help >> cmd.txt
>
> Works just great for debugging various cli commands. Ultimately I'll have to test my load on hardware, but there's
> lots of behavior that can be conveniently tested on the cycle-accurate simulator.
Ok you didn't mention simulator in your OP... I'm not sure what CCS does with console I/O and file I/O when running
simulations. For real-time debug, JTAG is used... and there are lots and lots of posts out there about JTAG related
issues, as real-time debug on actual hardware is the crucial task. One thing I can say for sure is that the CCS
simulator does not attempt to simulate JTAG delays, otherwise people would have an easier time of it when they reach
the hardware stage.
As you reach hardware test, you might want to keep in mind that fgetc will use JTAG. One possible "JTAG-free" method
is to download the CLI text file ahead-of-time, in some unused area of DSP mem, then read that mem area using a
modified function (maybe mgetc, hehe).
-Jeff
> -----Original Message-----
> From: Jeff Brower [mailto:j...@signalogic.com]
> Sent: Sunday, April 15, 2012 2:51 AM
> To: c...
> Cc: Tom Denesyk
> Subject: Re: [c6x] Change behavior of scanf in the ccsv5 debugger.
>
> Tom-
>
>> I don't want it to stop all tasks in the debugger.
>>
>> Instead I'd like ONLY the task that calls it to block.
>>
>> Any ideas on how to change the behavior of scanf would be greatly
>> appreciated.
>
> Are you using scanf to read the PC keyboard? If so, then scanf (and other console I/O) is occurring through your JTAG
> connection, which can be very slow, and likely to interfere with real-time debug. You might want to implement
> something like a user I/O switch on your board that your code reads as a flag to enable/disable scanf() calls... i.e.
> a flexible way to disable console I/O during debug.
>
> One reason I suggest this is that if you want to modify behavior of JTAG based scanf() you might not get a lot of
> suggestions, either on tech groups such as here or on TI-hosted forums, because it's not something that typically gets
> used in production code.
>
> If, on the other hand, you're doing console I/O with a device on your board (not over JTAG), that's a different story.
>
> -Jeff
_____________________________________
Reply by ●April 15, 20122012-04-15
Hey Jeff,
I appreciate your comments.
Here's what I ended up doing ...
On the DSP, fopen a file on my C drive which is going to contain my CLI input.
Using a conditional compilation (#ifdef MYSIM" to change my my uart byte read to use a fgetc() to get the next character from the file. Test if it is EOF, if not process it the same way I would on the HW.
Also with conditional compilation change my putbyte() to use printf("%c", &c). The output goes to the cCCSV5 console.
Now in a Cygwin window when I wasn't to issue a cli command, I do
Echo help >> cmd.txt
Works just great for debugging various cli commands. Ultimately I'll have to test my load on hardware, but there's lots of behavior that can be conveniently tested on the cycle-accurate simulator.
Thanks anyway,
Tom
-----Original Message-----
From: Jeff Brower [mailto:j...@signalogic.com]
Sent: Sunday, April 15, 2012 2:51 AM
To: c...
Cc: Tom Denesyk
Subject: Re: [c6x] Change behavior of scanf in the ccsv5 debugger.
Tom-
> I don't want it to stop all tasks in the debugger.
>
> Instead I'd like ONLY the task that calls it to block.
>
> Any ideas on how to change the behavior of scanf would be greatly
> appreciated.
Are you using scanf to read the PC keyboard? If so, then scanf (and other console I/O) is occurring through your JTAG connection, which can be very slow, and likely to interfere with real-time debug. You might want to implement something like a user I/O switch on your board that your code reads as a flag to enable/disable scanf() calls... i.e.
a flexible way to disable console I/O during debug.
One reason I suggest this is that if you want to modify behavior of JTAG based scanf() you might not get a lot of suggestions, either on tech groups such as here or on TI-hosted forums, because it's not something that typically gets used in production code.
If, on the other hand, you're doing console I/O with a device on your board (not over JTAG), that's a different story.
-Jeff
_____________________________________
I appreciate your comments.
Here's what I ended up doing ...
On the DSP, fopen a file on my C drive which is going to contain my CLI input.
Using a conditional compilation (#ifdef MYSIM" to change my my uart byte read to use a fgetc() to get the next character from the file. Test if it is EOF, if not process it the same way I would on the HW.
Also with conditional compilation change my putbyte() to use printf("%c", &c). The output goes to the cCCSV5 console.
Now in a Cygwin window when I wasn't to issue a cli command, I do
Echo help >> cmd.txt
Works just great for debugging various cli commands. Ultimately I'll have to test my load on hardware, but there's lots of behavior that can be conveniently tested on the cycle-accurate simulator.
Thanks anyway,
Tom
-----Original Message-----
From: Jeff Brower [mailto:j...@signalogic.com]
Sent: Sunday, April 15, 2012 2:51 AM
To: c...
Cc: Tom Denesyk
Subject: Re: [c6x] Change behavior of scanf in the ccsv5 debugger.
Tom-
> I don't want it to stop all tasks in the debugger.
>
> Instead I'd like ONLY the task that calls it to block.
>
> Any ideas on how to change the behavior of scanf would be greatly
> appreciated.
Are you using scanf to read the PC keyboard? If so, then scanf (and other console I/O) is occurring through your JTAG connection, which can be very slow, and likely to interfere with real-time debug. You might want to implement something like a user I/O switch on your board that your code reads as a flag to enable/disable scanf() calls... i.e.
a flexible way to disable console I/O during debug.
One reason I suggest this is that if you want to modify behavior of JTAG based scanf() you might not get a lot of suggestions, either on tech groups such as here or on TI-hosted forums, because it's not something that typically gets used in production code.
If, on the other hand, you're doing console I/O with a device on your board (not over JTAG), that's a different story.
-Jeff
_____________________________________
Reply by ●April 16, 20122012-04-16
Tom-
> When I get to HW, the fgetc gets replaced with a UART driver
> getByte() call. In the end game there is no CCS attached and
> all user coms are via UART's.
"In the end" :-) That's why it's called "debug" -- getting to the end!
-Jeff
> -----Original Message-----
> From: Jeff Brower [mailto:j...@signalogic.com]
> Sent: Sunday, April 15, 2012 9:36 PM
> To: c...
> Cc: Tom Denesyk
> Subject: RE: [c6x] Change behavior of scanf in the ccsv5 debugger.
>
> Tom-
>
> > I appreciate your comments.
> >
> > Here's what I ended up doing ...
> >
> > On the DSP, fopen a file on my C drive which is going to contain my CLI input.
> > Using a conditional compilation (#ifdef MYSIM" to change my my uart
> > byte read to use a fgetc() to get the next character from the file. Test if it is EOF, if not process it the same way I would on the HW.
> >
> > Also with conditional compilation change my putbyte() to use printf("%c", &c). The output goes to the cCCSV5 console.
> >
> > Now in a Cygwin window when I wasn't to issue a cli command, I do
> >
> > Echo help >> cmd.txt
> >
> > Works just great for debugging various cli commands. Ultimately I'll
> > have to test my load on hardware, but there's lots of behavior that can be conveniently tested on the cycle-accurate simulator.
>
> Ok you didn't mention simulator in your OP... I'm not sure what CCS does with console I/O and file I/O when running simulations. For real-time debug, JTAG is used... and there are lots and lots of posts out there about JTAG related issues, as real-time debug on actual hardware is the crucial task. One thing I can say for sure is that the CCS simulator does not attempt to simulate JTAG delays, otherwise people would have an easier time of it when they reach the hardware stage.
>
> As you reach hardware test, you might want to keep in mind that fgetc will use JTAG. One possible "JTAG-free" method is to download the CLI text file ahead-of-time, in some unused area of DSP mem, then read that mem area using a modified function (maybe mgetc, hehe).
>
> -Jeff
>
> > -----Original Message-----
> > From: Jeff Brower [mailto:j...@signalogic.com]
> > Sent: Sunday, April 15, 2012 2:51 AM
> > To: c...
> > Cc: Tom Denesyk
> > Subject: Re: [c6x] Change behavior of scanf in the ccsv5 debugger.
> >
> > Tom-
> >
> >> I don't want it to stop all tasks in the debugger.
> >>
> >> Instead I'd like ONLY the task that calls it to block.
> >>
> >> Any ideas on how to change the behavior of scanf would be greatly
> >> appreciated.
> >
> > Are you using scanf to read the PC keyboard? If so, then scanf (and
> > other console I/O) is occurring through your JTAG connection, which
> > can be very slow, and likely to interfere with real-time debug. You might want to implement something like a user I/O switch on your board that your code reads as a flag to enable/disable scanf() calls... i.e.
> > a flexible way to disable console I/O during debug.
> >
> > One reason I suggest this is that if you want to modify behavior of
> > JTAG based scanf() you might not get a lot of suggestions, either on
> > tech groups such as here or on TI-hosted forums, because it's not something that typically gets used in production code.
> >
> > If, on the other hand, you're doing console I/O with a device on your board (not over JTAG), that's a different story.
> >
> > -Jeff
> >
> >
_____________________________________
> When I get to HW, the fgetc gets replaced with a UART driver
> getByte() call. In the end game there is no CCS attached and
> all user coms are via UART's.
"In the end" :-) That's why it's called "debug" -- getting to the end!
-Jeff
> -----Original Message-----
> From: Jeff Brower [mailto:j...@signalogic.com]
> Sent: Sunday, April 15, 2012 9:36 PM
> To: c...
> Cc: Tom Denesyk
> Subject: RE: [c6x] Change behavior of scanf in the ccsv5 debugger.
>
> Tom-
>
> > I appreciate your comments.
> >
> > Here's what I ended up doing ...
> >
> > On the DSP, fopen a file on my C drive which is going to contain my CLI input.
> > Using a conditional compilation (#ifdef MYSIM" to change my my uart
> > byte read to use a fgetc() to get the next character from the file. Test if it is EOF, if not process it the same way I would on the HW.
> >
> > Also with conditional compilation change my putbyte() to use printf("%c", &c). The output goes to the cCCSV5 console.
> >
> > Now in a Cygwin window when I wasn't to issue a cli command, I do
> >
> > Echo help >> cmd.txt
> >
> > Works just great for debugging various cli commands. Ultimately I'll
> > have to test my load on hardware, but there's lots of behavior that can be conveniently tested on the cycle-accurate simulator.
>
> Ok you didn't mention simulator in your OP... I'm not sure what CCS does with console I/O and file I/O when running simulations. For real-time debug, JTAG is used... and there are lots and lots of posts out there about JTAG related issues, as real-time debug on actual hardware is the crucial task. One thing I can say for sure is that the CCS simulator does not attempt to simulate JTAG delays, otherwise people would have an easier time of it when they reach the hardware stage.
>
> As you reach hardware test, you might want to keep in mind that fgetc will use JTAG. One possible "JTAG-free" method is to download the CLI text file ahead-of-time, in some unused area of DSP mem, then read that mem area using a modified function (maybe mgetc, hehe).
>
> -Jeff
>
> > -----Original Message-----
> > From: Jeff Brower [mailto:j...@signalogic.com]
> > Sent: Sunday, April 15, 2012 2:51 AM
> > To: c...
> > Cc: Tom Denesyk
> > Subject: Re: [c6x] Change behavior of scanf in the ccsv5 debugger.
> >
> > Tom-
> >
> >> I don't want it to stop all tasks in the debugger.
> >>
> >> Instead I'd like ONLY the task that calls it to block.
> >>
> >> Any ideas on how to change the behavior of scanf would be greatly
> >> appreciated.
> >
> > Are you using scanf to read the PC keyboard? If so, then scanf (and
> > other console I/O) is occurring through your JTAG connection, which
> > can be very slow, and likely to interfere with real-time debug. You might want to implement something like a user I/O switch on your board that your code reads as a flag to enable/disable scanf() calls... i.e.
> > a flexible way to disable console I/O during debug.
> >
> > One reason I suggest this is that if you want to modify behavior of
> > JTAG based scanf() you might not get a lot of suggestions, either on
> > tech groups such as here or on TI-hosted forums, because it's not something that typically gets used in production code.
> >
> > If, on the other hand, you're doing console I/O with a device on your board (not over JTAG), that's a different story.
> >
> > -Jeff
> >
> >
_____________________________________
