Wanted more details on debug_* implementation

Comments

5 comments

  • Avatar
    Shannon Lgrizzly

    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
  • Avatar
    Michael Johnson

    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
  • Avatar
    Harjit Singh

    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
  • Avatar
    Michael Johnson

    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
  • Avatar
    Harjit Singh

    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.