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

hu/Benchmarks.html

@@ -1174,6 +1174,13 @@
     STM32G0B1 lépésszám referencia
   </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 @@
     STM32G0B1 lépésszám referencia
   </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>trükkök</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>1 léptető</td>
+<td>47</td>
+</tr>
+<tr>
+<td>3 léptető</td>
+<td>208</td>
+</tr>
+</tbody>
+</table>
 <h3 id="lpc176x-lepesszam-referencia">LPC176x lépésszám referencia<a class="headerlink" href="#lpc176x-lepesszam-referencia" title="Permanent link">&para;</a></h3>
 <p>Az LPC176x esetében a következő konfigurációs sorrendet használjuk:</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="linux-mcu-lepesszam-referencia">Linux MCU lépésszám referencia<a class="headerlink" href="#linux-mcu-lepesszam-referencia" title="Permanent link">&para;</a></h3>
 <p>A következő konfigurációs sorrendet egy Raspberry Pi esetében használjuk:</p>
 <div class="highlight"><pre><span></span><code>allocate_oids count=3
@@ -2289,7 +2331,8 @@ get_uptime
 </code></pre></div>
 
 <p>A teszt befejezésekor határozd meg a két "üzemidő" válaszüzenetben jelentett órák közötti különbséget. A másodpercenkénti parancsok teljes száma ekkor <code>100000 * mcu_frequency / clock_diff</code>.</p>
-<p>Vedd figyelembe, hogy ez a teszt telítheti a Raspberry Pi USB/CPU kapacitását. Ha Raspberry Pi, Beaglebone vagy hasonló gazdagépen fut, akkor növeld a késleltetést (pl. <code>DELAY {clock + 20*freq} get_uptime</code>). Ahol alkalmazható, az alábbi referenciák a console.py futtatásával készültek egy asztali számítógépen, ahol az eszköz egy nagy sebességű HUB-on keresztül van csatlakoztatva.</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>