none
How does OuputDebugString get routed to the serial port? RRS feed

  • Question

  • I've noticed that if I use, for example, a RETAILMSG to output to the the serial port for monitoring, it has horrible performance consequences, and I was wondering whether I could intercept these and route them through some buffered, event driven I/O.

    But I cant see where the routing of the OutputDebugString API to the serial port gets done. Does it go out through OEMWriteDebugString (which on my platform is a simple polled loop, which would explain some of what I see!)? Is there any way of changing this to route it to some function of my own so I can do some more sophisticated handling once I've got some COM drivers etc loaded?

    Thanks
    Tony

    Saturday, July 5, 2014 10:14 AM

Answers

  • Hi, May be the following URL gives some inputs for you to start: http://geekswithblogs.net/KMOS/archive/2010/04/11/log-debug-messages-without-debug-serial-on-shipped-device.aspx Regards, GSR
    • Marked as answer by Tony Hedge Monday, July 7, 2014 8:47 AM
    Monday, July 7, 2014 3:59 AM
  • The OutputDebugString call is not going through a driver, but nothing stops you from rewriting the OEMWriteDebugByte and OEMWriteDebugString functions.

    If that code waits until all characters are written that's not such great code... Normally you'd write to the UART FIFO and only poll for space to be available in the FIFO. That way there's usually not much of a performance degradation when not defining WINCESHIP.


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: http://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.

    • Proposed as answer by Vinoth[MCTS] Monday, July 7, 2014 7:11 AM
    • Marked as answer by Tony Hedge Monday, July 7, 2014 8:47 AM
    Monday, July 7, 2014 6:43 AM
    Moderator

All replies

  • Hi, May be the following URL gives some inputs for you to start: http://geekswithblogs.net/KMOS/archive/2010/04/11/log-debug-messages-without-debug-serial-on-shipped-device.aspx Regards, GSR
    • Marked as answer by Tony Hedge Monday, July 7, 2014 8:47 AM
    Monday, July 7, 2014 3:59 AM
  • The OutputDebugString call is not going through a driver, but nothing stops you from rewriting the OEMWriteDebugByte and OEMWriteDebugString functions.

    If that code waits until all characters are written that's not such great code... Normally you'd write to the UART FIFO and only poll for space to be available in the FIFO. That way there's usually not much of a performance degradation when not defining WINCESHIP.


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: http://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.

    • Proposed as answer by Vinoth[MCTS] Monday, July 7, 2014 7:11 AM
    • Marked as answer by Tony Hedge Monday, July 7, 2014 8:47 AM
    Monday, July 7, 2014 6:43 AM
    Moderator
  • Thanks both - that is really helpful and confirms what I was beginning to suspect, ie that it all ends up just being pumped to OEMWriteDebugByte via OEMWriteDebugString. All makes sense now, and yes, as per Michel's suggestion, the simplest solution seems to be to put a circular buffer and ISR in the OAL

    Thanks again to you both.

    Tony

    [On second thoughts, no - that isn't what Michel suggested - he was talking of the UART's own FIFO! And no, implementing an ISR in the OAL doesn't look much fun! I've come up with a workaround of sorts. I "turn off" OEMWriteDebugByte when I leave OEMInit, so that the polled debug port is available during OEMInit. But when my application starts it uses buffered, event driven I/O through the COM driver for serial debug output, and routes it to KITL via a RETAILMSG. A bit of a fudge but hopefully workable.]
    • Edited by Tony Hedge Monday, July 7, 2014 11:10 AM Afterthoughts!
    Monday, July 7, 2014 8:52 AM