none
deferred logging facility RRS feed

  • Question

  • Hi,

    I am coming from the other RTOS background, vxWorks from WindRiver.

    In vxWorks, it provides a deferred logging facility for debugging purpose.

    It is used instead of printf. The advantage over printf is that the message is not output dircetly in the context of the calling task, thus it won't slow down the calling task. With the same reason, it can be called from an ISR.

    There is a low priority task that will receive the message from the other task or ISR and do the ouputting.

    Does WINCE 7 has similar tool provided for developer ?

    rgds,

    kc Wong


    Thursday, January 28, 2016 1:56 AM

Answers

  • I was confused previously because the printf output is to debug serial port on vxWorks system. Thus we are told to use printf carefully as it will affect the performance and slow down the calling task.

    On WINCE system, I believe this should apply to RETAILMSG/DEBUGMSG because they are output to the debug serial port.

    As for printf on WINCE system, as its output is on the application console, so I believe it is going to the display driver. Thus, it should be more lightweight than RETAILMSG/DEBUGMSG ?

    rgds,

    kc Wong

    First, this isn't VxWorks, so it would help if you didn't assume anything based on your VxWorks experience.  I'm not even sure that you could make the same assumptions that you have been making about WindRiver Linux.  Same vendor, not the same OS at all.

    Second, read my blog.

    Third, as I stated and IoTGirl reiterated, the code is in YOUR BSP, so if you want to change how the output is handled, you and only you can do that.

    Forth, drawing to the display is not free.  It very well could take significantly more time to do than dropping bytes in UART FIFO.  But that depends on the length of the strings (which I keep short to avoid lengthy delays).

    You may want to pick up one of the Sam's Windows Compact 7 book.

    http://www.amazon.com/Professional-Windows-Embedded-Compact-7-ebook/dp/B005J56B9A/ref=sr_1_1?ie=UTF8&qid=1456408024&sr=8-1&keywords=samuel+phung



    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman
    I work for Eurotech

    Thursday, February 25, 2016 1:55 PM
    Moderator

All replies

  • Hi KC Wong,

    With respect to using Printf I recommend you take a Retail and Debug messages for Compact. Bruce has a great blog discussing them at http://geekswithblogs.net/BruceEitman/archive/2008/07/23/platform-builder-retailmsg-vs.-debugmsg.aspx.

    There are other options such as celog but I think the messaging routines above are what you are looking for.

    Sincerely,

    IoTGirl

    Thursday, January 28, 2016 6:18 PM
    Moderator
  • KC Wong:

    The typical problem with RETAILMSG and DEBUGMSG is that they do wait until at least all of the messages has been put in the serial port FIFO.

    The actual implementation of RETAILMSG and DEBUGMSG are in your BSP.  So you can modify them to use a buffer and a thread.  Might not be so easy though.   One of the things that we have done is modified them to put the messages in a RAM buffer that we then have a driver log in the background.  This further allows us to disable the logging at run time (or actually enable it if a customer reports a problem).

    I have never looked to see how celog is implemented, so I don't know if it would help.



    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman
    I work for Eurotech

    Thursday, January 28, 2016 6:39 PM
    Moderator
  • Hi IoTGirl,

    Thanks for your reply.

    rgds,

    kc Wong

    Wednesday, February 24, 2016 5:53 AM
  • Hi Bruce,

    Thanks for your reply.

    When printf is used, the output is at the application console.

    But, when RETAILMSG or DEBUGMSG is used, the output is at the Output window at VS2008. Thus, they are only meant to be seen when debugging through VS2008 ?

    rgds,

    kc Wong

    Thursday, February 25, 2016 12:57 AM
  • Hi KC,

    Maybe this thread will help you understand the answer https://social.msdn.microsoft.com/Forums/en-US/c05bf572-7b45-4549-96f1-5b632acd4f29/how-does-ouputdebugstring-get-routed-to-the-serial-port?forum=winembplatdev... you will need to do some work to re-route the output to meet your need.

    Sincerely,

    IoTGirl

    Thursday, February 25, 2016 1:09 AM
    Moderator
  • Hi IoTGirl,

    Thanks for your reply.

    I just connected the debug serial port and I can see the output for RETAILMSG/DEBUGMSG on the Tera Term.

    So, from what I see, the output for RETAILMSG/DEBUGMSG is going to few places:-

    (a)  debug serial port

    (b) the Output window at VS2008 (I believe this is through KITL)

    (c) CELOG (from the link you shared, it should end up a copy in CELOG as well)

    I was confused previously because the printf output is to debug serial port on vxWorks system. Thus we are told to use printf carefully as it will affect the performance and slow down the calling task.

    On WINCE system, I believe this should apply to RETAILMSG/DEBUGMSG because they are output to the debug serial port.

    As for printf on WINCE system, as its output is on the application console, so I believe it is going to the display driver. Thus, it should be more lightweight than RETAILMSG/DEBUGMSG ?

    rgds,

    kc Wong

    Thursday, February 25, 2016 2:15 AM
  • Hi KC,

    Your response tells me you did not read Bruce's blog that I pointed you to in the original response.  The key here is that OEM messages are in the HAL.

    Sincerely,

    IoTGirl.

    Thursday, February 25, 2016 2:23 AM
    Moderator
  • I was confused previously because the printf output is to debug serial port on vxWorks system. Thus we are told to use printf carefully as it will affect the performance and slow down the calling task.

    On WINCE system, I believe this should apply to RETAILMSG/DEBUGMSG because they are output to the debug serial port.

    As for printf on WINCE system, as its output is on the application console, so I believe it is going to the display driver. Thus, it should be more lightweight than RETAILMSG/DEBUGMSG ?

    rgds,

    kc Wong

    First, this isn't VxWorks, so it would help if you didn't assume anything based on your VxWorks experience.  I'm not even sure that you could make the same assumptions that you have been making about WindRiver Linux.  Same vendor, not the same OS at all.

    Second, read my blog.

    Third, as I stated and IoTGirl reiterated, the code is in YOUR BSP, so if you want to change how the output is handled, you and only you can do that.

    Forth, drawing to the display is not free.  It very well could take significantly more time to do than dropping bytes in UART FIFO.  But that depends on the length of the strings (which I keep short to avoid lengthy delays).

    You may want to pick up one of the Sam's Windows Compact 7 book.

    http://www.amazon.com/Professional-Windows-Embedded-Compact-7-ebook/dp/B005J56B9A/ref=sr_1_1?ie=UTF8&qid=1456408024&sr=8-1&keywords=samuel+phung



    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman
    I work for Eurotech

    Thursday, February 25, 2016 1:55 PM
    Moderator
  • OK, noted.

    Sure I have read the blog, and have found the code for OEMWriteDebugByte in the BSP. Will consider your suggestion of using a buffer and a thread.

    Thanks again.

    Friday, February 26, 2016 12:40 AM