• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 32 subscribers
  • Views 878 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Printf is too slow and skips interrupt

Pablo Cottens
Genius 3020 points

Hello,

I have a question. Is there any way to make printf run faster on RM48 devices? i tried all types of printf support (full, minimal nofloat), but it doesn't seem to affect printf's output speed. It even seems that it is skipping RTI interrupts, just because I put a printf in the main loop.

For example, I am also using a simple cortex-M3 device (STM32 family of microcontrollers) running @64MHz with keil and I see that the throughput in keil is incredibly fast, while in CCS I see a CIO update every second (both uCs running the same main loop).

Could there be something wrong with my configuration or is it supposed to be this way?

  • 0
    TI__Guru 59540 points

    Hi Pablo,

    I have forwarded your question to one of our engineers that has more background with using printf within the debug environment. He should respond shortly.

  • 0 in reply to Chuck Davenport
    TI__Guru 69070 points

    Pablo,

    CCS uses a breakpoint driven mechanism to implement printf and other io functions.  So yes they are not realtime and of course interrupts are not taken while the device is halted at a breakpoint.

    If you want to use some other mechanism the compiler manual has instructions for what you need to do to implement a different low level device model that IO can stack on top of.  I think Jean-Marc may even have posted an example of this where he used the UART for IO.

    Getting away from the breakpoint model would solve your interrupt issue but you'll still have bandwidth issues.  I suppose you could try taking the UART method and moving to ethernet but another option might be to look at what various RTOS's offer.  For example there is a FreeRTOS+Trace tool for logging events etc.. Not exactly 'printf' because you're logging very short codes that can be implemented by moving a byte or two into a buffer inside critical areas like interrupt handlers - rather than trying to 'print' intelligible strings.  Then there issually some sort of viewer that pulls these codes out int he background and decodes them for you.

    Alternatively you can look at using a hardware port like ETM to get information on data non-intrusively.  

    The right balance depends on how much you can spend and how high a bandwidth pipe you need.

  • 0 in reply to Anthony F. Seely
    Genius 3020 points

    Thank you very much for your reply.