Fix: Increase SysTick frequency to 1kHz #1536

ALTracer commented 2023年07月12日 15:24:22 +02:00 (Migrated from github.com)

Detailed description

• No new features.
• The pull request solves the problem of relatively slow RTT streaming speed of BMF.
• The pull request solves the problem by making it possible to poll faster than every 10ms. This requires raising the SysTick interrupt frequency from historically 100Hz to 1000Hz.

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (make PROBE_HOST=native)
• It builds as BMDA (make PROBE_HOST=hosted)
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues

No known to me issues solved by this PR.

Testing

I conducted tests of RTT streaming from @koendv 's Arduino sketch running on NUCLEO-G071RB (and some tests were repeated on a WeAct Studio BluePIll-Plus with genuine stm32f103cbt6). Here are the results in chars/s as reported by DUT measuring a hardware timer prescaled to 1ms ticks:

• blackpill-f411ce before: 34000..51000, after: 87000..102400;
• swlink before: 32000..34000, after: 78000;
• f072rb before: untested, after: 42000. This is on a 32F072B-DISCO just to check on the slowest (48MHz) supported platform.

If dropping the PC_HOSTED separation is wrong, I will rebase it out. For reference hosted uses usleep(ms * 1000U) or Sleep(ms) for delays but gettimeofday() for timestamping.

## Detailed description * No new features. * The pull request solves the problem of relatively slow RTT streaming speed of BMF. * The pull request solves the problem by making it possible to poll faster than every 10ms. This requires raising the SysTick interrupt frequency from historically 100Hz to 1000Hz. ## Your checklist for this pull request * [x] I've read the [Code of Conduct](https://github.com/blackmagic-debug/blackmagic/blob/main/CODE_OF_CONDUCT.md) * [x] I've read the [guidelines for contributing](https://github.com/blackmagic-debug/blackmagic/blob/main/CONTRIBUTING.md) to this repository * [x] It builds for hardware native (`make PROBE_HOST=native`) * [x] It builds as BMDA (`make PROBE_HOST=hosted`) * [x] I've tested it to the best of my ability * [x] My commit messages provide a useful short description of what the commits do ## Closing issues No known to me issues solved by this PR. ## Testing I conducted tests of RTT streaming from @koendv 's Arduino sketch running on NUCLEO-G071RB (and some tests were repeated on a WeAct Studio BluePIll-Plus with genuine stm32f103cbt6). Here are the results in chars/s as reported by DUT measuring a hardware timer prescaled to 1ms ticks: * `blackpill-f411ce` before: 34000..51000, after: 87000..102400; * `swlink` before: 32000..34000, after: 78000; * `f072rb` before: untested, after: 42000. This is on a 32F072B-DISCO just to check on the slowest (48MHz) supported platform. If dropping the PC_HOSTED separation is wrong, I will rebase it out. For reference `hosted` uses `usleep(ms * 1000U)` or `Sleep(ms)` for delays but `gettimeofday()` for timestamping.

koendv commented 2023年07月13日 11:16:33 +02:00 (Migrated from github.com)

On 2023年7月12日 06:24:33 -0700
Denis Tolstov @.***> wrote:

Here are the results in chars/s as reported by DUT measuring a
hardware timer prescaled to 1ms ticks:

• blackpill-f411ce before: 34000..51000, after: 87000..102400;
• swlink before: 32000..34000, after: 78000;

This surprises me. I could be wrong, and it may be interesting to ask an usb expert, but might full-speed usb serial be limited to one 64-byte packet every millisecond, or 64000 characters per second?

On 2023年7月12日 06:24:33 -0700 Denis Tolstov ***@***.***> wrote: > Here are the results in chars/s as reported by DUT measuring a > hardware timer prescaled to 1ms ticks: > * `blackpill-f411ce` before: 34000..51000, after: 87000..102400; > * `swlink` before: 32000..34000, after: 78000; This surprises me. I could be wrong, and it may be interesting to ask an usb expert, but might full-speed usb serial be limited to one 64-byte packet every millisecond, or 64000 characters per second?

ALTracer commented 2023年07月13日 11:22:09 +02:00 (Migrated from github.com)

This surprises me. I could be wrong, and it may be interesting to ask an usb expert, but might full-speed usb serial be limited to one 64-byte packet every millisecond, or 64000 characters per second?

Well, I had a similar assumption at first, too. However, BMF (and libopencm3 usb stack) seem to implement sending multiple (I measured 8) 64-byte BULK packets in a single 1ms full-speed frame. For more details, please check out the oscilloscope pics I took and posted on the Discord channel, or I could send them to you, or you can measure this yourself. I'm no USB expert either.

> This surprises me. I could be wrong, and it may be interesting to ask an usb expert, but might full-speed usb serial be limited to one 64-byte packet every millisecond, or 64000 characters per second? Well, I had a similar assumption at first, too. However, BMF (and libopencm3 usb stack) seem to implement sending multiple (I measured 8) 64-byte BULK packets in a single 1ms full-speed frame. For more details, please check out the oscilloscope pics I took and posted on the Discord channel, or I could send them to you, or you can measure this yourself. I'm no USB expert either.