Deploying to gh-pages from @ Klipper3d/klipper@9323a5dfe2 🚀

it/Benchmarks.html

@@ -1174,6 +1174,13 @@
     Benchmark step rate STM32G0B1
   </a>
   
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#stm32g4-step-rate-benchmark" class="md-nav__link">
+    STM32G4 step rate benchmark
+  </a>
+  
 </li>
         
           <li class="md-nav__item">
@@ -1613,6 +1620,13 @@
     Benchmark step rate STM32G0B1
   </a>
   
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#stm32g4-step-rate-benchmark" class="md-nav__link">
+    STM32G4 step rate benchmark
+  </a>
+  
 </li>
         
           <li class="md-nav__item">
@@ -2040,6 +2054,34 @@ finalize_config crc=0
 </tr>
 </tbody>
 </table>
+<h3 id="stm32g4-step-rate-benchmark">STM32G4 step rate benchmark<a class="headerlink" href="#stm32g4-step-rate-benchmark" title="Permanent link">&para;</a></h3>
+<p>The following configuration sequence is used on the STM32G431:</p>
+<div class="highlight"><pre><span></span><code>allocate_oids count=3
+config_stepper oid=0 step_pin=PA0 dir_pin=PB5 invert_step=-1 step_pulse_ticks=17
+config_stepper oid=1 step_pin=PB2 dir_pin=PB6 invert_step=-1 step_pulse_ticks=17
+config_stepper oid=2 step_pin=PB3 dir_pin=PB7 invert_step=-1 step_pulse_ticks=17
+finalize_config crc=0
+</code></pre></div>
+
+<p>The test was last run on commit <code>cfa48fe3</code> with gcc version <code>arm-none-eabi-gcc (Fedora 14.1.0-1.fc40) 14.1.0</code>.</p>
+<table>
+<thead>
+<tr>
+<th>stm32g431</th>
+<th>ticks</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>1 stepper</td>
+<td>47</td>
+</tr>
+<tr>
+<td>3 stepper</td>
+<td>208</td>
+</tr>
+</tbody>
+</table>
 <h3 id="benchmark-step-rate-lpc176x">Benchmark step rate LPC176x<a class="headerlink" href="#benchmark-step-rate-lpc176x" title="Permanent link">&para;</a></h3>
 <p>La seguente sequenza di configurazione viene utilizzata sull'LPC176x:</p>
 <div class="highlight"><pre><span></span><code>allocate_oids count=3
@@ -2252,7 +2294,7 @@ finalize_config crc=0
 </tr>
 </tbody>
 </table>
-<p>(*) Note that the reported rp2040 ticks are relative to a 12Mhz scheduling timer and do not correspond to its 200Mhz internal ARM processing rate. It is expected that 5 scheduling ticks corresponds to ~42 ARM core cycles and 14 scheduling ticks corresponds to ~225 ARM core cycles.</p>
+<p>(*) Note that the reported rp2040 ticks are relative to a 12Mhz scheduling timer and do not correspond to its 200Mhz internal ARM processing rate. It is expected that 3 scheduling ticks corresponds to ~42 ARM core cycles and 14 scheduling ticks corresponds to ~225 ARM core cycles.</p>
 <h3 id="benchmark-step-rate-mcu-linux">Benchmark step rate MCU Linux<a class="headerlink" href="#benchmark-step-rate-mcu-linux" title="Permanent link">&para;</a></h3>
 <p>La seguente sequenza di configurazione viene utilizzata su un Raspberry Pi:</p>
 <div class="highlight"><pre><span></span><code>allocate_oids count=3
@@ -2289,7 +2331,8 @@ get_uptime
 </code></pre></div>
 
 <p>Al termine del test, determinare la differenza tra gli orologi riportati nei due messaggi di risposta "uptime". Il numero totale di comandi al secondo è quindi <code>100000 * mcu_frequency / clock_diff</code>.</p>
-<p>Nota che questo test potrebbe saturare la capacità USB/CPU di un Raspberry Pi. Se è in esecuzione su un computer host Raspberry Pi, Beaglebone o simile, aumenta il ritardo (ad esempio, <code>DELAY {clock + 20*freq} get_uptime</code>). Ove applicabile, i benchmark seguenti riguardano console.py in esecuzione su una macchina di classe desktop con il dispositivo connesso tramite un hub ad alta velocità.</p>
+<p>The USB tests may exceed the CPU capacity of a Raspberry Pi. If running on a Raspberry Pi, Beaglebone, or similar host computer then increase the delay (eg, <code>DELAY {clock + 20*freq} get_uptime</code>). Where applicable, the benchmarks below are with console.py running on a desktop class machine with the device connected via a super-speed hub.</p>
+<p>The CAN bus tests may saturate the USB host controller of a Raspberry Pi (when testing via a standard gs_usb USB to CAN bus adapter). Where applicable, the CAN bus benchmarks below are with console.py running on a desktop class machine with a USB to CAN bus adapter connected via a super-speed USB hub.</p>
 <table>
 <thead>
 <tr>
@@ -2301,12 +2344,6 @@ get_uptime
 </thead>
 <tbody>
 <tr>
-<td>stm32f042 (CAN)</td>
-<td>18K</td>
-<td>c105adc8</td>
-<td>arm-none-eabi-gcc (GNU Tools 7-2018-q3-update) 7.3.1</td>
-</tr>
-<tr>
 <td>atmega2560 (serial)</td>
 <td>23K</td>
 <td>b161a69e</td>
@@ -2319,6 +2356,12 @@ get_uptime
 <td>arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0</td>
 </tr>
 <tr>
+<td>rp2350 (CAN)</td>
+<td>59K</td>
+<td>17b8ce4c</td>
+<td>arm-none-eabi-gcc (Fedora 14.1.0-1.fc40) 14.1.0</td>
+</tr>
+<tr>
 <td>at90usb1286 (USB)</td>
 <td>75K</td>
 <td>01d2183f</td>