docs(intro): fix typos (#7485)

Signed-off-by: bjsylvia <bjsylvia@163.com>

docs/README.md

@@ -264,7 +264,7 @@ Arguments that are expressions (more than one word), or contain non-alphanumeric
     :cpp:expr:`lv_obj_set_layout(*widget, LV_LAYOUT_FLEX)`             <== asterisk
     :cpp:expr:`lv_obj_set_layout((lv_obj_t *)widget, LV_LAYOUT_FLEX)`  <== cast
     :cpp:expr:`lv_obj_set_layout(&widget, LV_LAYOUT_FLEX);`            <== ampersand & semicolon
-    :cpp:expr:`lv_obj_set_layout(widget, ...)`                         <== lone elipsis
+    :cpp:expr:`lv_obj_set_layout(widget, ...)`                         <== lone ellipsis
 
 For such examples, simply use reStructuredText literal markup like this:
 

docs/intro/add-lvgl-to-your-project/configuration.rst

@@ -71,7 +71,7 @@ TODO:  Add all things related to ``lv_conf.h`` file and its contents.
 
 Multiple Instances of LVGL
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
-It is possible to run multiple, independent isntances of LVGL.  To enable its
+It is possible to run multiple, independent instances of LVGL.  To enable its
 multi-instance feature, set :c:macro:`LV_GLOBAL_CUSTOM` in ``lv_conf.h``
 and provide a custom function to :cpp:func:`lv_global_default` using ``__thread`` or
 ``pthread_key_t``.  It will allow running multiple LVGL instances by storing LVGL's

docs/intro/add-lvgl-to-your-project/connecting_lvgl.rst

@@ -127,7 +127,7 @@ thus the delay it introduces cannot be known.
 Display Interface
 *****************
 LVGL needs to be supplied with knowledge about each display panel you want it to use.
-Specificially:
+Specifically:
 
 - its pixel format and size (:ref:`creating_a_display`),
 - where to render pixels for it (:ref:`draw_buffers`), and

docs/intro/add-lvgl-to-your-project/threading.rst

@@ -175,7 +175,7 @@ MUTEX to protect LVGL data structures.
 
 Method 2:  Use a MUTEX
 ----------------------
-A MUTEX stands for "MUTually EXclusive" and is a synchronization primative that
+A MUTEX stands for "MUTually EXclusive" and is a synchronization primitive that
 protects the state of a system resource from being modified or accessed by multiple
 threads of execution at once.  In other words, it makes data so protected "appear"
 atomic (all threads using this data "see" it in a consistent state).  Most OSes
@@ -198,7 +198,7 @@ To be clear:  this must be done *both* by threads that READ from that resource,
 threads that MODIFY that resource.
 
 If a MUTEX is used to protect LVGL data structures, that means *every* LVGL function
-call (or group of function calls) must be preceeded by #1, and followed by #2,
+call (or group of function calls) must be preceded by #1, and followed by #2,
 including calls to :cpp:func:`lv_timer_handler`.
 
 .. note::

docs/intro/basics.rst

@@ -145,7 +145,7 @@ RAM (e.g. for quick re-display again later).  Doing so:
 
 - requires more RAM, but
 - can save the time of repeatedly creating the Screen and its child Widgets;
-- can be handy when a Screen is complex and/or can be made the :ref:`active_screen` freqently.
+- can be handy when a Screen is complex and/or can be made the :ref:`active_screen` frequently.
 
 If multiple Screens are maintained in RAM simultaneously, it is up to the system
 designer as to how they are managed.