diff --git a/README.md b/README.md index f6dbd27d2..f4ddc39d2 100644 --- a/README.md +++ b/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: diff --git a/adapter/README.md b/adapter/README.md index 207c9db14..33fe40d00 100644 --- a/adapter/README.md +++ b/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. diff --git a/adapter/active-3/README.md b/adapter/active-3/README.md index 75345e784..82d687bba 100644 --- a/adapter/active-3/README.md +++ b/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 diff --git a/adapter/passive-rpi1/README.md b/adapter/passive-rpi1/README.md index 280c50496..4687acff6 100644 --- a/adapter/passive-rpi1/README.md +++ b/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 diff --git a/bindings/c#/RGBLedMatrixOptions.cs b/bindings/c#/RGBLedMatrixOptions.cs index 2ea9a6614..88dedb418 100644 --- a/bindings/c#/RGBLedMatrixOptions.cs +++ b/bindings/c#/RGBLedMatrixOptions.cs @@ -94,7 +94,7 @@ public struct RGBLedMatrixOptions /// /// Panel type. Typically just empty, but certain panels (FM6126) - /// requie an initialization sequence + /// require an initialization sequence /// public string? PanelType = null; diff --git a/bindings/c#/RPiRgbLEDMatrix.csproj b/bindings/c#/RPiRgbLEDMatrix.csproj index 26055fa5b..533f5fa8f 100644 --- a/bindings/c#/RPiRgbLEDMatrix.csproj +++ b/bindings/c#/RPiRgbLEDMatrix.csproj @@ -5,7 +5,7 @@ enable - + true diff --git a/bindings/python/setup.py b/bindings/python/setup.py index 85289c291..9ad0f8818 100644 --- a/bindings/python/setup.py +++ b/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( diff --git a/examples-api-use/README.md b/examples-api-use/README.md index 24cda4108..040544671 100644 --- a/examples-api-use/README.md +++ b/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 ) 2 - backward scrolling an image (-m ) @@ -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 diff --git a/examples-api-use/c-example.c b/examples-api-use/c-example.c index 74bd08835..ba3ef2f83 100644 --- a/examples-api-use/c-example.c +++ b/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); diff --git a/examples-api-use/demo-main.cc b/examples-api-use/demo-main.cc index a055dfe9c..7583a0d49 100644 --- a/examples-api-use/demo-main.cc +++ b/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 )\n" "\t2 - backward scrolling an image (-m )\n" diff --git a/include/canvas.h b/include/canvas.h index bbb892234..795219b35 100644 --- a/include/canvas.h +++ b/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 diff --git a/include/graphics.h b/include/graphics.h index 2feb633d6..454af3f4c 100644 --- a/include/graphics.h +++ b/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 diff --git a/include/led-matrix-c.h b/include/led-matrix-c.h index 15ad90c9c..4f8e5b52b 100644 --- a/include/led-matrix-c.h +++ b/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 diff --git a/include/led-matrix.h b/include/led-matrix.h index ed7960efe..ec2e1d309 100644 --- a/include/led-matrix.h +++ b/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. diff --git a/include/threaded-canvas-manipulator.h b/include/threaded-canvas-manipulator.h index a7ca678d0..c213ec687 100644 --- a/include/threaded-canvas-manipulator.h +++ b/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; diff --git a/lib/framebuffer-internal.h b/lib/framebuffer-internal.h index a3408865a..f3942f213 100644 --- a/lib/framebuffer-internal.h +++ b/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 diff --git a/lib/framebuffer.cc b/lib/framebuffer.cc index 3f9fa5cf3..2e12210d9 100644 --- a/lib/framebuffer.cc +++ b/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; diff --git a/lib/gpio.cc b/lib/gpio.cc index 68edcdbf1..c18e0f09d 100644 --- a/lib/gpio.cc +++ b/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. diff --git a/lib/graphics.cc b/lib/graphics.cc index 7c2c16d21..d69b4a265 100644 --- a/lib/graphics.cc +++ b/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; diff --git a/lib/led-matrix.cc b/lib/led-matrix.cc index 6c89fcaec..855661efa 100644 --- a/lib/led-matrix.cc +++ b/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", diff --git a/lib/multiplex-mappers.cc b/lib/multiplex-mappers.cc index d41bef9cb..d6a853458 100644 --- a/lib/multiplex-mappers.cc +++ b/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 * diff --git a/lib/options-initialize.cc b/lib/options-initialize.cc index ff6e0d462..7ccf23614 100644 --- a/lib/options-initialize.cc +++ b/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; } diff --git a/lib/pixel-mapper.cc b/lib/pixel-mapper.cc index 2cb04d2c6..243a7e6c3 100644 --- a/lib/pixel-mapper.cc +++ b/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 diff --git a/utils/led-image-viewer.cc b/utils/led-image-viewer.cc index 35da8c59e..a9d405029 100644 --- a/utils/led-image-viewer.cc +++ b/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 filename_params; diff --git a/wiring.md b/wiring.md index e542e7289..69993a9f7 100644 --- a/wiring.md +++ b/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).