> 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
> >
> >
_____________________________________
Reply by Tom Denesyk●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
_____________________________________
Reply by Jeff Brower●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
_____________________________________
Reply by Jeff Brower●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
_____________________________________
Reply by Tom●April 15, 20122012-04-15
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.