----- Paul Curtis wrote ----- 
>
> The trick is not to impose a burden on the micro by starting/stopping it
> all the time (intrusion).  Some vendors do this with a breakpoint and
> stealing a breakpoint from a processor with only two breakpoints nukes
> the usefulness somewhat.  CrossWorks doesn't require a breakpoint and
> nor is it intrusive.  We don't publish how we achieve this; perhaps
> somebody can actually work it out.
>
Isn't this the main cause of problems with singlestepping and
programming
small MSP's with CrossWorks & CrossConnect Lite?

Jarda

I'd like to use printf as debug tool (using IAR EW), but it seems 
like it's slowing down my application tremendously. To the degree 
that not even interrupts are executing for several seconds after 
just a few consecutive printf's. 

A few questions:

1. Is it conceivable that the JTAG interface just halts the CPU for 
this long? Have you had similar experience with printf behaviour? 

2. How is character I/O implemented on the JTAG level? Does anybody 
know? I couldn't find anything that low-level in the documentation 
that comes with EW? A pointer in the right direction where to find 
this info would be great!

3. Has anybody found a way around this?

Thanks!!!

Silke

I've had the same experience. For one, printf is a bloated function, so
it's 
doing a lot more than you really need it to in most cases, and therefore is 
slow. I think there's a puts() function that might be better suited to just

getting the job done. 

I do run into debugging time critical functions where I just give up on the 
debugger, and just send data out one of the io pins. (high means this, low 
means this, etc.. ) 

That assumes of course you have a spare.. 

-Micah 


On Thursday 17 February 2005 05:46 pm, spruessner
wrote:
>  I'd like to use printf as debug tool (using IAR EW), but it seems
>  like it's slowing down my application tremendously. To the degree
>  that not even interrupts are executing for several seconds after
>  just a few consecutive printf's.
>
>  A few questions:
>
>  1. Is it conceivable that the JTAG interface just halts the CPU for
>  this long? Have you had similar experience with printf behaviour?
>
>  2. How is character I/O implemented on the JTAG level? Does anybody
>  know? I couldn't find anything that low-level in the documentation
>  that comes with EW? A pointer in the right direction where to find
>  this info would be great!
>
>  3. Has anybody found a way around this?
>
>  Thanks!!!
>
>  Silke
>
>
>
>
>
>  .
>
>
>
>
>
>  .

Oh the joys of occluding the hardware level. ;@}

 From my undertsnding of it. The JTAG interface is effectively dormant, 
unless you are in single step mode, until a breakpoint is reached. I/O 
should run normally, assuming that you are correctly setting clocks etc, 
and not relying simply on their default state at power on. Unless the 
compiler strips all the unnecessary garbage out of printf, and reduces 
the code to just the bare necessities, it will be very slow, but 
shouldn't affect interrupts. These are a hardware function unless 
printf, or some other code is disabling them. Character I/O from the 
normal pins is NOt implemented at the JTAG level. You could probably 
write your own JTAG routines to stream other data over the port, but I 
believe that IAR only does this when stopped. This is NOT a full JTAG 
implentation. I believe that Paul has posted to this effect in the past. 
IIRC there is a way of getting some real time data across the JTAG, but 
I don't rcall the mechanism. I believe the answer to your questions with 
C-Spy are:_

1. No
2. It isn't
3. yes, but not with C-Spy

Al

spruessner wrote:

>I'd like to use printf as debug tool (using
IAR EW), but it seems 
>like it's slowing down my application tremendously. To the degree 
>that not even interrupts are executing for several seconds after 
>just a few consecutive printf's. 
>
>A few questions:
>
>1. Is it conceivable that the JTAG interface just halts the CPU for 
>this long? Have you had similar experience with printf behaviour? 
>
>2. How is character I/O implemented on the JTAG level? Does anybody 
>know? I couldn't find anything that low-level in the documentation 
>that comes with EW? A pointer in the right direction where to find 
>this info would be great!
>
>3. Has anybody found a way around this?
>
>Thanks!!!
>
>Silke
>
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>

All these high level languages and debug devolves to blinky LEDs. ;@} Oh 
the joys of asm.

Al

Micah Stevens wrote:

>I've had the same experience. For one, printf
is a bloated function, so it's 
>doing a lot more than you really need it to in most cases, and therefore is 
>slow. I think there's a puts() function that might be better suited to
just 
>getting the job done. 
>
>I do run into debugging time critical functions where I just give up on the 
>debugger, and just send data out one of the io pins. (high means this, low 
>means this, etc.. ) 
>
>That assumes of course you have a spare.. 
>
>-Micah 
>
>
>On Thursday 17 February 2005 05:46 pm, spruessner wrote:
>  
>
>> I'd like to use printf as debug tool (using IAR EW), but it seems
>> like it's slowing down my application tremendously. To the degree
>> that not even interrupts are executing for several seconds after
>> just a few consecutive printf's.
>>
>> A few questions:
>>
>> 1. Is it conceivable that the JTAG interface just halts the CPU for
>> this long? Have you had similar experience with printf behaviour?
>>
>> 2. How is character I/O implemented on the JTAG level? Does anybody
>> know? I couldn't find anything that low-level in the documentation
>> that comes with EW? A pointer in the right direction where to find
>> this info would be great!
>>
>> 3. Has anybody found a way around this?
>>
>> Thanks!!!
>>
>> Silke
>>
>>
>>
>>
>>
>> .
>>
>>
>>
>>
>>
>> .
>>    
>>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>

Al, 

> You could probably write your 
> own JTAG routines to stream other data over the port

This requires an understanding of how MSP430 JTAG works--not that
difficult, TI publish an app note on it.

> but I 
> believe that IAR only does this when stopped. This is NOT a 
> full JTAG implentation.

True.

> I believe that Paul has posted to 
> this effect in the past. 

The trick is not to impose a burden on the micro by starting/stopping it
all the time (intrusion).  Some vendors do this with a breakpoint and
stealing a breakpoint from a processor with only two breakpoints nukes
the usefulness somewhat.  CrossWorks doesn't require a breakpoint and
nor is it intrusive.  We don't publish how we achieve this; perhaps
somebody can actually work it out.

(Has anynody noticed that posts from JK are rather rare to non-existent
these days?  Has our knowledgeable poster jumped ship to another
processor?)

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and (soon) MAXQ processors

Hi Al, 

> All these high level languages and debug devolves
to blinky 
> LEDs. ;@} Oh the joys of asm.

Man, have you got yourself into MAXQ yet?  Learning how to get the best
out of that puppy is a real experience!

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and (soon) MAXQ processors

Paul Curtis wrote:

>Al, 
>
>  
>
>>You could probably write your 
>>own JTAG routines to stream other data over the port
>>    
>>
>
>  
>
>>I believe that Paul has posted to 
>>this effect in the past. 
>>    
>>
>
>The trick is not to impose a burden on the micro by starting/stopping it
>all the time (intrusion).  Some vendors do this with a breakpoint and
>stealing a breakpoint from a processor with only two breakpoints nukes
>the usefulness somewhat.  CrossWorks doesn't require a breakpoint and
>nor is it intrusive.  We don't publish how we achieve this; perhaps
>somebody can actually work it out.
>
>(Has anynody noticed that posts from JK are rather rare to non-existent
>these days?  Has our knowledgeable poster jumped ship to another
>processor?)
>  
>

Us Nody's are not too busy to notice that the venerable Jon has left 
this space. Actually about the Time Joerg arrived. i wonder...

Nodys friend Big Ears

I 'm oscillating between MAXQ and ADuC at the moment. 32 bit ARM ASM
is 
NICE! YUM! and I've only just started playing with it. I did finally 
find MAXQ-IDE, but by then was engrossed in arming myself. I have some 
didly bits, but it is obvious that you can make this thing do circus 
tricks with a bit of friendly persuasion. Spoiled for choice right now ;@}

Al

Paul Curtis wrote:

>Hi Al, 
>
>  
>
>>All these high level languages and debug devolves to blinky 
>>LEDs. ;@} Oh the joys of asm.
>>    
>>
>
>Man, have you got yourself into MAXQ yet?  Learning how to get the best
>out of that puppy is a real experience!
>
>--
>Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
>CrossWorks for MSP430, ARM, AVR and (soon) MAXQ processors
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>

Sounds like you didn't allow enough stack for printf.
Especially if you use float formatting, you'll want to have 150-200 bytes
spare
on your stack.
Printf () formatting is not _that_ slow !
Check yoiur linker file and see how much stack you have allowed for.

-- Kris


On Thursday 17 February 2005 05:46 pm, spruessner
wrote:
>  I'd like to use printf as debug tool (using IAR EW), but it seems
>  like it's slowing down my application tremendously. To the degree
>  that not even interrupts are executing for several seconds after
>  just a few consecutive printf's.
>
>  A few questions:
>
>  1. Is it conceivable that the JTAG interface just halts the CPU for
>  this long? Have you had similar experience with printf behaviour?
>
>  2. How is character I/O implemented on the JTAG level? Does anybody
>  know? I couldn't find anything that low-level in the documentation
>  that comes with EW? A pointer in the right direction where to find
>  this info would be great!
>
>  3. Has anybody found a way around this?
>
>  Thanks!!!
>
>  Silke