Wanted more details on debug_* implementation

Follow

Harjit Singh

• March 17, 2010 22:36

In my application, I have an interrupt driven motor control loop and I'm using debug_printf and other debug_* functions.

I wanted to get more info. on how the debug_* facilities are implemented so that I can figure out if using these functions can block any interrupts and thus cause my motors to "take off".

I haven't found anything on the specifics in the docs. or on this site.

Thanks in advance.

Harjit

0

• 

  Shannon Lgrizzly

  • March 23, 2010 14:30

  I haven't used the debug__ stuff myself but I guess the first thing I would wonder is are the routines using any interrupts to implement the output of long strings? (for example in debug__printf).   If they are not then they would have to be polling to find out when it's ready to send the next character.  My bet would be there would be at least one blocking statement in there.  That said, it would be pretty rude to disable interrupts around a blocking statement!  Normally you would only disable interrupts for a short atomic read or write where you can't afford to be interrupted.

  Have you checked out your priorities and made sure they are as high as they can be?

  Guess you could put yourself in a tight loop around a debug__ statement and see if your systick timer changes frequency or jitters?

  Are your motors taking off because some variable gets corrupted?  I can't see getting interrupted for a moment would cause anything more than a single missed pid calculation.  The loop should restore itself pretty quickly.  (especially in a speedy micromouse! haha)

  0

  Comment actions Permalink
• 

  Michael Johnson

  • March 23, 2010 17:40

  On ARM debugIO is implemented using the DCC - interrupts aren't disabled during debugIO. However if a debug_handler is used (for monitor mode debug or to avoid cache/MMU issues) then a breakpoint is used.

  On CM3/MSP430/AVR/MAXQ a breakpoint is used.

  Regards

  Michael

  0

  Comment actions Permalink
• 

  Harjit Singh

  • September 24, 2010 22:54

  I'm shipping 4MB of data from my embedded system to the host PC using debug_fwrite - it works but is slow - surprisingly it is much slower than the program download.

  Currently, I'm doing:
        debug_fwrite(&ulBufLog[0], sizeof(ULong), ulHeadLog, pdfFile);

  I haven't looked at the assembly code for debug_fwrite but am wondering if the following would be the slower, the same or faster:
        debug_fwrite(&ulBufLog[0], sizeof(ULong) * ulHeadLog, 1, pdfFile);
  
  

  0

  Comment actions Permalink
• 

  Michael Johnson

  • September 27, 2010 08:40

  Are you using an FTDI2232 based jtag cable (amontec, olimex)? If so then upload is considerably slower than download. A parallel port wiggler, Segger JLink (if you are using windows) or a CrossConnect will be much quicker at upload than an FTDI2232 based device.

  0

  Comment actions Permalink
• 

  Harjit Singh

  • September 27, 2010 18:30

  I am using an FTDI4232 - essentially the same as the FTDI2232 - soln.

  Thank you for all the info. and support.

  0

  Comment actions Permalink

Please sign in to leave a comment.