4 ms·

Now that I re-read it, it is harsh. I meant no personal attacks. Sorry. But it's what I would feel if I see a colleague (C) programmer doing that.

by scoutt 5y ago

AnimalMuppet 5y ago
As I said elsewhere in this thread, in embedded C you can't always set a breakpoint. If there are real time things going on, you won't meet the timing as soon as you hit the breakpoint. If there are multiple threads, stopping one of the threads can change everything, making other threads take a completely different path than they would have without the breakpoint. All you can get from it is, yes, this thread hit this breakpoint, and the local variables have these values. But (at least in many embedded situations) you can't continue from there to learn anything more from the next breakpoint. You have to start over.
- scoutt 5y ago
  I don’t follow you. Usually breakpoints are hardware (not conditional breakpoints), and the core halts completely. You can continue execution as if nothing happened. Often watchdogs and timers are aware of breakpoints and core halting. What would be the alternative? Semihosting? Using an uart? That screws the timing even more.
  - AnimalMuppet 5y ago
    Ah, I was thinking of a soft breakpoint, not a hard one. A hardware breakpoint solves the threading problem, but it doesn't stop the external world. If there are external events that your system responds to (and what embedded system doesn't?) then those events will either be missed, or else all queued up, when you resume. Shoving chars out a uart, in contrast, takes time, but considerably less time than a human hitting continue after a breakpoint. That can still mess up the timing. But a breakpoint absolutely blows up the timing - seconds worth of external events have happened. If your external events are coming from a test rig, and the test rig is aware of you hitting a breakpoint, then that problem goes away.
    - jpindar 5y ago
      >Shoving chars out a uart, in contrast, takes time, but considerably less time than a human hitting continue after a breakpoint. Toggling an i/o line (which you can monitor on a scope) takes even less. BTDT.
      - AnimalMuppet 5y ago
        Yup. Or use to trigger a logic analyzer.
        jpindar 5y ago
        With modern mixed signal scopes, there's becoming less and less difference between the two.
        AnimalMuppet 5y ago
        Scopes don't handle 20 data lines at once.
    - scoutt 5y ago
      > it doesn't stop the external world Sure, but it can also happen when debugging desktop applications too. It's not just an embedded problem. Even if all events are queued up, you still can (for example) interrupt a handshake that goes into timeout by the remote side. > those events will either be missed It happens but is not inherently a bad thing. Sometimes this can be used on purpose. > considerably less time than a human hitting continue after a breakpoint I am well aware that there are situations in which serial debugging is not possible, and situations in which breakpoint debugging is not practical. I am not saying that printf (or whatever) debugging is useless or bad, or that breakpoints are better. I am saying that placing random printf's to determine the program flow and guessing where the problem could be is a desperate solution.
gus_massa 5y ago
Don't worry. No hard feelings. I agree that if there is a debugger available it's much better to use the debugger. [1] When I'm improving the optimization pass in the compiler of Racket, one of the problem is that enabling debugging kills many of the optimizations. So when debugging is enabled the problem disappears. Another problem is that it has a lot of expansion and passes, and some of the code is in Chez Scheme. So when modifying the code in Chez Scheme that is used to compile itself and later to compile the code in Racket, it is difficult to run all of these in a debugger. And when an optimization is wrong, it's like if the compiler sees a code that is not what you are seeing, so the error may appear in a weird place and perhaps far away from the wrong code. [1] I still miss stop-edit-and-continue that was available in Classic Visual Basic 6. And IIRC QuickBasic has an option to see a few of the previous instructions before the breakpoint...

Now that I re-read it, it is harsh. I meant no personal attacks. Sorry. But it's what I would feel if I see a colleague (C) programmer doing that.

by scoutt 5y ago

Now that I re-read it, it is harsh. I meant no personal attacks. Sorry. But it's what I would feel if I see a colleague (C) programmer doing that.

AnimalMuppet 5y ago

As I said elsewhere in this thread, in embedded C you can't always set a breakpoint. If there are real time things going on, you won't meet the timing as soon as you hit the breakpoint. If there are multiple threads, stopping one of the threads can change everything, making other threads take a completely different path than they would have without the breakpoint. All you can get from it is, yes, this thread hit this breakpoint, and the local variables have these values. But (at least in many embedded situations) you can't continue from there to learn anything more from the next breakpoint. You have to start over.

scoutt 5y ago
I don’t follow you. Usually breakpoints are hardware (not conditional breakpoints), and the core halts completely. You can continue execution as if nothing happened. Often watchdogs and timers are aware of breakpoints and core halting. What would be the alternative? Semihosting? Using an uart? That screws the timing even more.
- AnimalMuppet 5y ago
  Ah, I was thinking of a soft breakpoint, not a hard one. A hardware breakpoint solves the threading problem, but it doesn't stop the external world. If there are external events that your system responds to (and what embedded system doesn't?) then those events will either be missed, or else all queued up, when you resume. Shoving chars out a uart, in contrast, takes time, but considerably less time than a human hitting continue after a breakpoint. That can still mess up the timing. But a breakpoint absolutely blows up the timing - seconds worth of external events have happened. If your external events are coming from a test rig, and the test rig is aware of you hitting a breakpoint, then that problem goes away.
  - jpindar 5y ago
    >Shoving chars out a uart, in contrast, takes time, but considerably less time than a human hitting continue after a breakpoint. Toggling an i/o line (which you can monitor on a scope) takes even less. BTDT.
    - AnimalMuppet 5y ago
      Yup. Or use to trigger a logic analyzer.
      - jpindar 5y ago
        With modern mixed signal scopes, there's becoming less and less difference between the two.
        AnimalMuppet 5y ago
        Scopes don't handle 20 data lines at once.
  - scoutt 5y ago
    > it doesn't stop the external world Sure, but it can also happen when debugging desktop applications too. It's not just an embedded problem. Even if all events are queued up, you still can (for example) interrupt a handshake that goes into timeout by the remote side. > those events will either be missed It happens but is not inherently a bad thing. Sometimes this can be used on purpose. > considerably less time than a human hitting continue after a breakpoint I am well aware that there are situations in which serial debugging is not possible, and situations in which breakpoint debugging is not practical. I am not saying that printf (or whatever) debugging is useless or bad, or that breakpoints are better. I am saying that placing random printf's to determine the program flow and guessing where the problem could be is a desperate solution.

gus_massa 5y ago

Don't worry. No hard feelings. I agree that if there is a debugger available it's much better to use the debugger. [1] When I'm improving the optimization pass in the compiler of Racket, one of the problem is that enabling debugging kills many of the optimizations. So when debugging is enabled the problem disappears. Another problem is that it has a lot of expansion and passes, and some of the code is in Chez Scheme. So when modifying the code in Chez Scheme that is used to compile itself and later to compile the code in Racket, it is difficult to run all of these in a debugger. And when an optimization is wrong, it's like if the compiler sees a code that is not what you are seeing, so the error may appear in a weird place and perhaps far away from the wrong code. [1] I still miss stop-edit-and-continue that was available in Classic Visual Basic 6. And IIRC QuickBasic has an option to see a few of the previous instructions before the breakpoint...