Fix a few typos

README.md

@@ -54,7 +54,7 @@ and is not yet supported.
 The 26 pin models can drive one chain of RGB panels, the 40 pin models
 **up to three** chains in parallel (each chain 12 or more panels long).
 The Compute Module can drive **up to 6 chains in parallel**.
-The Raspberry Pi 2 and 3 are faster and generally perferred to the older
+The Raspberry Pi 2 and 3 are faster and generally preferred to the older
 models (and the Pi Zero). With the faster models, the panels sometimes
 can't keep up with the speed; check out
 this [troubleshooting section](#troubleshooting) what to do.
@@ -87,7 +87,7 @@ Flag                                | Descriptio
 `--led-cols`          | Columns in the LED matrix, the 'width'.
 `--led-rows`          | Rows in the LED matrix, the 'height'.
 `--led-multiplexing`  | In particular bright outdoor panels with small multiplex ratios require this. Often an indicator: if there are fewer address lines than expected: ABC (instead of ABCD) for 32 high panels and ABCD (instead of ABCDE) for 64 high panels.
-`--led-row-addr-type` | Adressing of rows; in particular panels with only AB address lines might indicate that this is needed.
+`--led-row-addr-type` | Addressing of rows; in particular panels with only AB address lines might indicate that this is needed.
 `--led-panel-type`    | Chipset of the panel. In particular if it doesn't light up at all, you might need to play with this option because it indicates that the panel requires a particular initialization sequence.
 
 Panels can be chained by connecting the output of one panel to the input of
@@ -447,8 +447,8 @@ This will allow higher refresh rate (or same refresh rate with increased
 `--led-pwm-lsb-nanoseconds`).
 The disadvantage could be slightly lower brightness, in particular for longer
 chains, and higher CPU use.
-CPU use is not of concern for Rasbperry Pi 2 or 3 (as we run on a dedicated
-core anyway) but proably for Raspberry Pi 1 or Pi Zero.
+CPU use is not of concern for Raspberry Pi 2 or 3 (as we run on a dedicated
+core anyway) but probably for Raspberry Pi 1 or Pi Zero.
 Default: no dithering; if you have a Pi 3 and struggle with low frame-rate due
 to high multiplexing panels (1:16 or 1:32) or long chains, it might be
 worthwhile to try.
@@ -693,7 +693,7 @@ with traces under the chip, this involves lifting a leg from the
 HCT245 (figure out a free bus driver from the schematic). If all of the
 above makes sense to you, you have the Ninja level to do it!
 
-It might be more convienent at this point to consider the [Active3 adapter](./adapter/active-3)
+It might be more convenient at this point to consider the [Active3 adapter](./adapter/active-3)
 that has that covered already.
 
 Running as root
@@ -728,11 +728,11 @@ about 1'000'000 write operations have to happen every second!
 We can't use hardware support for writing these as DMA is too slow,
 thus the constant CPU use on an RPi is roughly 30-40% of one core.
 Keep that in mind if you plan to run other things on this computer (This
-is less noticable on Raspberry Pi, Version 2 or 3 that has more cores).
+is less noticeable on Raspberry Pi, Version 2 or 3 that has more cores).
 
 Also, the output quality is susceptible to other heavy tasks running on that
-computer - there might be changes in the overall brigthness when this affects
-the referesh rate.
+computer - there might be changes in the overall brightness when this affects
+the refresh rate.
 
 If you have a loaded system and one of the newer Pis with 4 cores, you can
 reserve one core just for the refresh of the display:

adapter/README.md

@@ -5,7 +5,7 @@ Since hand-wiring can be a little tedious, here are some PCBs that help
 with the wiring when using the `rpi-rgb-led-matrix` code.
 
    * [Passive-3](./passive-3) Supports three parallel chains, directly connected
-     to the output of a Rapsberry Pi with 40 GPIO pins. Works, but usually it is better to
+     to the output of a Raspberry Pi with 40 GPIO pins. Works, but usually it is better to
      buffer the outputs using the ...
    * [Active-3](./active-3) board. Supports three parallel chains with active buffering
      and 3.3V -> 5V level shifting for best reliability. Requires SMD soldering.

adapter/active-3/README.md

@@ -16,7 +16,7 @@ Adapter PCB to support up to 3 panel chains
      it easy to hand-solder. Make sure to get the variant with the **T**: HC**T** or AHC**T**
      (there are also HC or AHC, don't use these).
      - 4x 100nF ceramic capacitor (0805 package)
-     - 1x 10kOhm resistor (0805 package). Not critcial, just a pullup (2.2k .. 15k probably ok).
+     - 1x 10kOhm resistor (0805 package). Not critical, just a pullup (2.2k .. 15k probably ok).
      - 3x 16pin IDC (=2x8) male receptible to connect the panels.
      - 1x 40pin female connector to connect to the RPi.
      - 1x (optional) 22μF .. 100μF capacitor for 5V rail (either 1206 SMD or

adapter/passive-rpi1/README.md

@@ -1,4 +1,4 @@
-Adapter PCB to connect to Rasbperry Pi1
+Adapter PCB to connect to Raspberry Pi1
 =======================================
 
    * Passive board. Simple, but might need to define `--led-slowdown-gpio` if you see

bindings/c#/RGBLedMatrixOptions.cs

@@ -94,7 +94,7 @@ public struct RGBLedMatrixOptions
 
     /// <summary>
     /// Panel type. Typically just empty, but certain panels (FM6126)
-    /// requie an initialization sequence
+    /// require an initialization sequence
     /// </summary>
     public string? PanelType = null;
 

bindings/c#/RPiRgbLEDMatrix.csproj

@@ -5,7 +5,7 @@
         <ImplicitUsings>enable</ImplicitUsings>
     </PropertyGroup>
 
-    <!-- Skip builing native libraries by default on Windows -->
+    <!-- Skip building native libraries by default on Windows -->
     <PropertyGroup Condition="$(SkipNative) == '' and $(OS) != 'Unix'">
         <SkipNative>true</SkipNative>
     </PropertyGroup>

bindings/python/setup.py

@@ -2,7 +2,7 @@
 
 # The following distutils seems to stop working with newer
 # Python version >= 3.12
-# Someone with Python knowlege, please fix.
+# Someone with Python knowledge, please fix.
 from distutils.core import setup, Extension
 
 core_ext = Extension(

examples-api-use/README.md

@@ -38,7 +38,7 @@ Options:
         --led-slowdown-gpio=<0..4>: Slowdown GPIO. Needed for faster Pis/slower panels (Default: 1).
         --led-daemon              : Make the process run in the background as daemon.
         --led-no-drop-privs       : Don't drop privileges from 'root' after initializing the hardware.
-Demos, choosen with -D
+Demos, chosen with -D
         0  - some rotating square
         1  - forward scrolling an image (-m <scroll-ms>)
         2  - backward scrolling an image (-m <scroll-ms>)
@@ -215,7 +215,7 @@ was the `matrix` directory:
      RGB_LIBRARY=$(RGB_LIBDIR)/lib$(RGB_LIBRARY_NAME).a
      LDFLAGS+=-L$(RGB_LIBDIR) -l$(RGB_LIBRARY_NAME) -lrt -lm -lpthread
 
-Also, you want to add a target to build the libary in your sub-module
+Also, you want to add a target to build the library in your sub-module
 
 	 # (FYI: Make sure, there is a TAB-character in front of the $(MAKE))
      $(RGB_LIBRARY):
@@ -273,7 +273,7 @@ of 64x64 pixels:
 
 ```
 So the following chain (Viewed looking at the LED-side of the panels)
-    [<][<][<][<] }- Raspbery Pi connector
+    [<][<][<][<] }- Raspberry Pi connector
 
 is arranged in this U-shape (on its side)
     [<][<] }----- Raspberry Pi connector

examples-api-use/c-example.c

@@ -27,7 +27,7 @@ int main(int argc, char **argv) {
 
   /* Let's do an example with double-buffering. We create one extra
    * buffer onto which we draw, which is then swapped on each refresh.
-   * This is typically a good aproach for animations and such.
+   * This is typically a good approach for animations and such.
    */
   offscreen_canvas = led_matrix_create_offscreen_canvas(matrix);
 

examples-api-use/demo-main.cc

@@ -1037,7 +1037,7 @@ static int usage(const char *progname) {
 
   rgb_matrix::PrintMatrixFlags(stderr);
 
-  fprintf(stderr, "Demos, choosen with -D\n");
+  fprintf(stderr, "Demos, chosen with -D\n");
   fprintf(stderr, "\t0  - some rotating square\n"
           "\t1  - forward scrolling an image (-m <scroll-ms>)\n"
           "\t2  - backward scrolling an image (-m <scroll-ms>)\n"

include/canvas.h

@@ -24,7 +24,7 @@ namespace rgb_matrix {
 // This abstraction also allows you to e.g. create delegating
 // implementations that do a particular transformation, e.g. re-map
 // pixels (as you might lay out the physical RGB matrix in a different way),
-// compose images (OR, XOR, transparecy), scale, rotate, anti-alias or
+// compose images (OR, XOR, transparency), scale, rotate, anti-alias or
 // translate coordinates in a funky way.
 //
 // It is a good idea to have your applications use the concept of

include/graphics.h

@@ -50,7 +50,7 @@ class Font {
   // If we don't have it in the font, draws the replacement character "�" if
   // available.
   // Returns how much we advance on the screen, which is the width of the
-  // character or 0 if we didn't draw any chracter.
+  // character or 0 if we didn't draw any character.
   int DrawGlyph(Canvas *c, int x, int y,
                 const Color &color, const Color *background_color,
                 uint32_t unicode_codepoint) const;
@@ -82,7 +82,7 @@ class Font {
 
 // -- Some utility functions.
 
-// Utility function: set an image from the given buffer containting pixels.
+// Utility function: set an image from the given buffer containing pixels.
 //
 // Draw image of size "image_width" and "image_height" from pixel at
 // canvas-offset "canvas_offset_x", "canvas_offset_y". Image will be shown

include/led-matrix-c.h

@@ -172,8 +172,8 @@ struct RGBLedRuntimeOptions {
   // even offered via the command line flags.
   // ----------
 
-  // Thre are three possible values here
-  //   -1 : don't leave choise of becoming daemon to the command line parsing.
+  // There are three possible values here
+  //   -1 : don't leave choice of becoming daemon to the command line parsing.
   //        If set to -1, the --led-daemon option is not offered.
   //    0 : do not becoma a daemon, run in forgreound (default value)
   //    1 : become a daemon, run in background.
@@ -359,7 +359,7 @@ struct LedCanvas *led_matrix_swap_on_vsync(struct RGBLedMatrix *matrix,
 uint8_t led_matrix_get_brightness(struct RGBLedMatrix *matrix);
 void led_matrix_set_brightness(struct RGBLedMatrix *matrix, uint8_t brightness);
 
-// Utility function: set an image from the given buffer containting pixels.
+// Utility function: set an image from the given buffer containing pixels.
 //
 // Draw image of size "image_width" and "image_height" from pixel at
 // canvas-offset "canvas_offset_x", "canvas_offset_y". Image will be shown

include/led-matrix.h

@@ -207,7 +207,7 @@ class RGBMatrix : public Canvas {
   // -- Double- and Multibuffering.
 
   // Create a new buffer to be used for multi-buffering. The returned new
-  // Buffer implements a Canvas with the same size of thie RGBMatrix.
+  // Buffer implements a Canvas with the same size as this RGBMatrix.
   // You can use it to draw off-screen on it, then swap it with the active
   // buffer using SwapOnVSync(). That would be classic double-buffering.
   //
@@ -409,8 +409,8 @@ struct RuntimeOptions {
   // even offered via the command line flags.
   // ----------
 
-  // Thre are three possible values here
-  //   -1 : don't leave choise of becoming daemon to the command line
+  // There are three possible values here
+  //   -1 : don't leave choice of becoming daemon to the command line
   //        parsing. If set to -1, the --led-daemon option is not offered.
   //    0 : do not becoma a daemon, run in forgreound (default value)
   //    1 : become a daemon, run in background.
@@ -481,7 +481,7 @@ int main(int argc, char **argv) {
 // This parses the flags from argv and updates the structs with the parsed-out
 // values. Structs can be NULL if you are not interested in it.
 //
-// The recongized flags are removed from argv if "remove_consumed_flags" is
+// The recognized flags are removed from argv if "remove_consumed_flags" is
 // true; this simplifies your command line processing for the remaining options.
 //
 // Returns 'true' on success, 'false' if there was flag parsing problem.

include/threaded-canvas-manipulator.h

@@ -30,7 +30,7 @@
 
 namespace rgb_matrix {
 //
-// Typically, your programs will crate a canvas and then updating the image
+// Typically, your programs will create a canvas and then updating the image
 // in a loop. If you want to do stuff in parallel, then this utility class
 // helps you doing that. Also a demo for how to use the Thread class.
 //
@@ -59,7 +59,7 @@ namespace rgb_matrix {
   MyCrazyDemo *demo = new MyCrazyDemo(matrix);
   demo->Start();   // Start doing things.
   // This now runs in the background, you can do other things here,
-  // e.g. aquiring new data or simply wait. But for waiting, you wouldn't
+  // e.g. acquiring new data or simply wait. But for waiting, you wouldn't
   // need a thread in the first place.
   demo->Stop();
   delete demo;

lib/framebuffer-internal.h

@@ -75,8 +75,8 @@ class Framebuffer {
   // TODO(hzeller): make the default 15 bit or so, but slide the use of
   //  timing to lower bits if fewer bits requested to not affect the overall
   //  refresh in that case.
-  //  This needs to be balanced to not create too agressive timing however.
-  //  To be explored in a separete commit.
+  //  This needs to be balanced to not create too aggressive timing however.
+  //  To be explored in a separate commit.
   //
   // For now, if someone needs very low level of light, change this to
   // say 13 and recompile. Run with --led-pwm-bits=13. Also, consider

lib/framebuffer.cc

@@ -508,7 +508,7 @@ static void InitFM6126(GPIO *io, const struct HardwareMapping &h, int columns) {
 }
 
 // The FM6217 is very similar to the FM6216.
-// FM6217 adds Register 3 to allow for automatic bad pixel supression.
+// FM6217 adds Register 3 to allow for automatic bad pixel suppression.
 static void InitFM6127(GPIO *io, const struct HardwareMapping &h, int columns) {
   const gpio_bits_t bits_r_on= h.p0_r1 | h.p0_r2;
   const gpio_bits_t bits_g_on= h.p0_g1 | h.p0_g2;

lib/gpio.cc

@@ -31,7 +31,7 @@
  * nanosleep() takes longer than requested because of OS jitter.
  * In about 99.9% of the cases, this is <= 25 microcseconds on
  * the Raspberry Pi (empirically determined with a Raspbian kernel), so
- * we substract this value whenever we do nanosleep(); the remaining time
+ * we subtract this value whenever we do nanosleep(); the remaining time
  * we then busy wait to get a good accurate result.
  *
  * You can measure the overhead using DEBUG_SLEEP_JITTER below.
@@ -363,7 +363,7 @@ static uint32_t *mmap_bcm_register(off_t register_offset) {
   }
 
   uint32_t *result =
-    (uint32_t*) mmap(NULL,                  // Any adddress in our space will do
+    (uint32_t*) mmap(NULL,                  // Any address in our space will do
                      REGISTER_BLOCK_SIZE,   // Map length
                      PROT_READ|PROT_WRITE,  // Enable r/w on GPIO registers.
                      MAP_SHARED,
@@ -382,7 +382,7 @@ static uint32_t *mmap_bcm_register(off_t register_offset) {
 }
 
 static bool mmap_all_bcm_registers_once() {
-  if (s_GPIO_registers != NULL) return true;  // alrady done.
+  if (s_GPIO_registers != NULL) return true;  // already done.
 
   // The common GPIO registers.
   s_GPIO_registers = mmap_bcm_register(GPIO_REGISTER_OFFSET);
@@ -551,7 +551,7 @@ void Timers::sleep_nanos(long nanos) {
   // a chance to do something else.
 
   // However, these timings have a lot of jitter, so if we have the 1Mhz timer
-  // available, we use that to accurately mesure time spent and do the
+  // available, we use that to accurately measure time spent and do the
   // remaining time with busy wait. If we don't have the timer available
   // (not running as root), we just use nanosleep() for larger values.
 

lib/graphics.cc

@@ -53,7 +53,7 @@ bool SetImage(Canvas *c, int canvas_offset_x, int canvas_offset_y,
     ? (canvas_offset_x + image_display_w - w) * 3
     : 0;
 
-  // Let's make this a combined skip per row and ajust where we start.
+  // Let's make this a combined skip per row and adjust where we start.
   const size_t next_row_skip = skip_start_row + skip_end_row;
   buffer += skip_start_row;
 

lib/led-matrix.cc

@@ -658,7 +658,7 @@ RGBMatrix *RGBMatrix::CreateFromOptions(const RGBMatrix::Options &options,
   }
 
   // For the Pi4, we might need 2, maybe up to 4. Let's open up to 5.
-  // on supproted architectures, -1 will emit memory barier (DSB ST) after GPIO write
+  // on supported architectures, -1 will emit memory barier (DSB ST) after GPIO write
   if (runtime_options.gpio_slowdown < (LED_MATRIX_ALLOW_BARRIER_DELAY ? -1 : 0)
       || runtime_options.gpio_slowdown > 5) {
     fprintf(stderr, "--led-slowdown-gpio=%d is outside usable range\n",

lib/multiplex-mappers.cc

@@ -201,7 +201,7 @@ class Kaler2ScanMapper : public MultiplexMapperBase {
 
   void MapSinglePanel(int x, int y, int *matrix_x, int *matrix_y) const {
     // Now we have a 128x4 matrix
-    int offset = ((y%4)/2) == 0 ? -1 : 1;// Add o substract
+    int offset = ((y%4)/2) == 0 ? -1 : 1;// Add or substract
     int deltaOffset = offset < 0 ? 7:8;
     int deltaColumn = ((y%8)/4)== 0 ? 64 : 0;
 
@@ -293,7 +293,7 @@ class InversedZStripe : public MultiplexMapperBase {
 
 
 /*
- * Vairous P10 1R1G1B Outdoor implementations for 16x16 modules with separate
+ * Various P10 1R1G1B Outdoor implementations for 16x16 modules with separate
  * RGB LEDs, e.g.:
  * https://www.ledcontrollercard.com/english/p10-outdoor-rgb-led-module-160x160mm-dip.html
  *

lib/options-initialize.cc

@@ -401,7 +401,7 @@ bool RGBMatrix::Options::Validate(std::string *err_in) const {
   }
 
   if (cols < 16) {
-    err->append("Invlid number of columns for panel (--led-cols). "
+    err->append("Invalid number of columns for panel (--led-cols). "
                 "Typically that is something like 32 or 64\n");
     success = false;
   }
@@ -463,7 +463,7 @@ bool RGBMatrix::Options::Validate(std::string *err_in) const {
   }
 
   if (pwm_dither_bits < 0 || pwm_dither_bits > 2) {
-    err->append("Inavlid range of pwm-dither-bits (0..2 allowed).\n");
+    err->append("Invalid range of pwm-dither-bits (0..2 allowed).\n");
     success = false;
   }
 

lib/pixel-mapper.cc

@@ -150,7 +150,7 @@ class MirrorPixelMapper : public PixelMapper {
 // we have a panel that has double the height but only uses one chain.
 // A single chain display with four 32x32 panels can then be arranged in this
 // 64x64 display:
-//    [<][<][<][<] }- Raspbery Pi connector
+//    [<][<][<][<] }- Raspberry Pi connector
 //
 // can be arranged in this U-shape
 //    [<][<] }----- Raspberry Pi connector

utils/led-image-viewer.cc

@@ -271,7 +271,7 @@ int main(int argc, char *argv[]) {
   // there is a flag modifying them. This map keeps track of filenames
   // and their image params (also for unrelated elements of argv[], but doesn't
   // matter).
-  // We map the pointer instad of the string of the argv parameter so that
+  // We map the pointer instead of the string of the argv parameter so that
   // we can have two times the same image on the commandline list with different
   // parameters.
   std::map<const void *, struct ImageParams> filename_params;

wiring.md

@@ -256,7 +256,7 @@ guidelines:
      at the board are a good choice (two, because lower parallel ESR; also
      fits easier under board).
      (In reality, we need of course less, as the highest ripple comes with
-      50% duty cyle thus half the current; also the input is recharching all
+      50% duty cycle thus half the current; also the input is recharching all
       the time. But: as engineer plan for maximum and then some; in the picture
       above I am using 1x3300uF per panel and it works fine).