Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
21 years ago

Speeding up/increasing priority of printf

Hi,

Does anyone know of any way of speeding or increasing the priority of the printf statement to the console window of the IDE. I have been relying heavily on prinft to debug issues in a multiple task application and have found problems in my code for example at a location e.g. *bug* below (cause system hang), case A printf reaches the console window but case B never arrives. This is very misleading during debug, it suggests the problem occurred between case A and case B when in really the issue occurred at *bug*. I have seen this problem many times. It makes debugging a multitask application with intermittant bugs very difficult.

function

{

printf (case A)

code...

printf (caseB)

code...

*bug*

}

Any ideas would be appreciated!

Aiden

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    If you want to insure that you print statements complete before you get to the next code, you can change the way printf works such that it does not use the an interrupt and therefore blocks further execution of the thread until all characters are sent. This is very inefficient. (To do this you likely need to change the run time library function call _write.) You could also implement your own uart output function that doesn't use interrupts.

    For this type of environment, debugging with printf's is not the best mechanism. Also, the printf takes significant CPU resources if you are using them as frequently as you imply. Which means that when you remove them or add more, your code is likely to act differently. That is the joy of a multitasking environment. There are some very powerful debugging tools for Nios including trace. Using the trace window will tell you the last X number of instructions so you can investigate what went wrong.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    I second that reccomendation. We've all debugged with printf. It has its place. So does blinking an LED (which may be fine in your case).... but having HW breakpoints & trace dumps is a great thing and is part of the debug tools included with Nios II; it does take a bit of time to get up to speed with these but that is the trade-off.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    Thanks Guys,

    For HW breakpoints & trace dumps is the recommended tool FS2 with the Nios IDE? I haven't used a tool like this before. Any recommendations on the best way to get started? Can I get a trace similar to what the software call stack looks like at the exact point where my systems/software hangs with this tool?

    Cheers,

    Aiden
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    Hi,

    If you disable interrupts somewhere and it can not get out that piece of code --> the printing stops becuase the interrupt that drives the sending process is not coming through anymore.

    Maybe to indicate the program flow, a simple putchar can do. It doesn't need the processing time of the printf and needs (worst case) only the time for sending one character. However, be sure that it is not sending to the same buffer system as the printf. Maybe you can use a seperate uart and custom putchar like function for this special debug case. So the debug output will not be intermixed with other messages from your software.

    Stefaan