Fix: Increase SysTick frequency to 1kHz

[ALTracer]

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.

[dragonmux]

LGTM, thank you for this and for sharing in Discord the testing results of making sure this doesn't mess anything up that is easily tested. Merging.

[koendv]

On Wed, 12 Jul 2023 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]

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.