4 ms·

I don’t follow you. Usually breakpoints are hardware (not conditional breakpoints), and the core halts completely. You can continue execution as if nothing happ

by 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.

by scoutt 5y ago

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.