docs: Fix misspelling to *.md file

Fix misspelling in .md files.

apps/system/utils/README.md

@@ -272,7 +272,7 @@ Application Configuration -> System Libraries and Add-Ons -> [*] Kernel shell co
 
 ## getenv/setenv/unsetenv
 These commands are related with setting or getting the environment variables.  
-The **getenv** prints all of environment variables. If specific environment name is given, this prints the value of given envionment.   
+The **getenv** prints all of environment variables. If specific environment name is given, this prints the value of given environment.   
 The **setenv** save new environment variable with given value.  
 The **unsetenv** unsets environment variable with NAME.
 ```bash

build/configs/artik053/hello/README.md

@@ -2,7 +2,7 @@
 This prints "hello world" like minimal. But it has more functionality on kernel and file system.  
 If network functionality is not mandatory, it can be used.  
 
-Because of enabled many configs and big number of arrays comparsed with minimal,  
+Because of enabled many configs and big number of arrays compared with minimal,  
 the [minimal](../minimal/README.md) config is better to know minimal the TizenRT kernel footprint.
 
 ## Enabled Feature

build/configs/sidk_s5jt200/README.md

@@ -105,7 +105,7 @@ SUBSYSTEMS=="usb",ATTRS{idVendor}=="0403",ATTRS{idProduct}=="6010",MODE="0666" R
 
 ## How to program a binary
 
-After buiding a TizenRT, execute below at $TIZENRT_BASEDIR/os folder.  
+After building a TizenRT, execute below at $TIZENRT_BASEDIR/os folder.  
 See [[Getting the sources]](https://github.com/Samsung/TizenRT#getting-the-sources) for how to set *TIZENRT_BASEDIR*.
 ```bash
 ./dbuild.sh download ALL
@@ -170,7 +170,7 @@ There are three configuration sets for sidk_s5jt200, including 'hello_with_tash'
  for running kernel functions
 
 #### tc
- for runnig unit test cases
+ for running unit test cases
 
 #### sidk_tash_aws
  for running AWS IoT SDK examples.

docs/HowToSetEnv.md

@@ -9,7 +9,7 @@ Untar the gcc-arm-none-eabi-6-2017-q1-update-*OS Type*.tar.bz2 and export the pa
 tar xvjf gcc-arm-none-eabi-6-2017-q1-update-[OS Type].tar.bz2
 export PATH=<Your Toolchain PATH>:$PATH
 ```
-Be aware that recommanded toolchain is fully working on 64bits machine.
+Be aware that recommended toolchain is fully working on 64bits machine.
 
 ## Getting the source code
 

docs/HowToUseAudio.md

@@ -33,15 +33,15 @@ Depending on the board schematics, a control path (i2c, spi, etc) and a data pat
 
 Board_initialize sets up audio codec with the instance of the control path and data path.
 
-Psuedocode
+Pseudocode
 ```
 void board_initialize()  
 {  
 	/* Get an i2c instance */
 	i2c = initialize i2c();
 
 	/* Get an i2s instance */
-	i2s = initalize_i2s(); 
+	i2s = initialize_i2s(); 
 
 	/* Setup audio codec */
 	codec_lowerhalf = initialize_audio_codec(i2c, i2s, ..);
@@ -52,7 +52,7 @@ void board_initialize()
 
 After setting up audio codec, the codec's lowerhalf is wrapped around in an audio device upperhalf.
 
-Psuedocode
+Pseudocode
 
 ```
 	/*Embed codec device within audio device */

docs/HowToUseMPU.md

@@ -49,7 +49,7 @@ mpu_user_intsram_wb()      : Read Write        Read Write
 
 ```mpu_priv_noncache()``` - This function is used to configure a memory region as internal memory with _not cacheable_, _not bufferable_, _shareable_ and _instruction access disable_ attributes.
 
-```mpu_peripheral()``` - This function is used to configure a memory region as periperal address space with _shareable_, _bufferable_ and _instruction access disable_ attributes.
+```mpu_peripheral()``` - This function is used to configure a memory region as peripheral address space with _shareable_, _bufferable_ and _instruction access disable_ attributes.
 
 ```mpu_priv_flash()``` - This function is used to configure a memory region as privileged program flash with _cacheable_ attributes.
 

docs/HowToUsePeripheral.md

@@ -302,7 +302,7 @@ int i2c_uioregister(FAR const char *path, FAR struct i2c_dev_s *dev);
 ### I2C Initialization  
 I2C is initialized by invoking up_i2cinitialize.  
 Initialization takes one i2c port and returns a i2c device structure.  
-Initialization is done either as part of _up_intitialize()_ or as part of _board_initialize()_.  
+Initialization is done either as part of _up_initialize()_ or as part of _board_initialize()_.  
 
 Please refer to **[i2c.h](../os/include/tinyara/i2c.h)** to know more about the i2c functions and declarations.  
 

docs/HowToUseTinyAlsa.md

@@ -102,7 +102,7 @@ At any point of time, the user is free to exit the record/play loop and close th
 **pcm_mmap_write**
 These are additional API's provided for the sake of compatibility with the ALSA API list. These API's internally make use of the mmap API's to transfer data. However, these API's require the user to allocate data buffers and then copy the data from these buffer to the mmap buffers internally. Hence, they do not provide the advantage of low latency which would be provided by using the other mmap API's directly. Hence, it is recommended to avoid the use of these API's for improving latency reduction.
 
-The psuedocode below briefly illustrates the use of mmap API's for recording audio:
+The pseudocode below briefly illustrates the use of mmap API's for recording audio:
 ```
 #include <tinyalsa/tinyalsa.h>
 ...

external/aws/CHANGELOG.md

@@ -113,7 +113,7 @@ Bugfixes/Improvements:
 
 Features:
 
-  - Testing with mbedTLS, prepping for relase
+  - Testing with mbedTLS, prepping for release
 
 Bugfixes/Improvements:
 

external/grpc/README.md

@@ -109,7 +109,7 @@ Therefore, our TizenRT application must internally use either `pthread_create` A
 Please refer to `grpc_greeter_client` and `grpc_route_client` applications under `apps/examples` folder as examples on how to achieve this.
 
 An important consideration when running gRPC on TizenRT is the stack size allocated for its threads.
-From our initial verfication, we observe that a minimum thread stack size of 16384 bytes is necessary for the main gRPC thread to run successfully on TizenRT.
+From our initial verification, we observe that a minimum thread stack size of 16384 bytes is necessary for the main gRPC thread to run successfully on TizenRT.
 This can be achieved by either using the `pthread_attr_setstacksize` API or configuring the default pthread stacksize via menuconfig, at the location `Kernel Features -> Stack size information -> Default pthread stack size`.
 Additionally, this gRPC main thread engine uses `pthread_create` internally for its run-time procedures, for which we recommend setting a stack size of 10240 bytes or higher. In order to configure this easily, TizenRT features a menuconfig parameter at the location `Networking Support -> Protocols -> gRPC -> Set thread size for grpc modules`.
 

external/iotivity/README.md

@@ -16,7 +16,7 @@ For more information refer to the [web site](http://www.scons.org/doc/production
 There are two methods to enable IoTivity. One is using a pre-set configuration(defconfig), the other is using menuconfig.  
 As a default configuration, you can use the IoTivity defconfig. Otherwise, you should enable this function with menuconfig.
 
-#### Using pre-set configration
+#### Using pre-set configuration
 Use the IoTivity configuration.  
 ```bash
 ~/TIZENRT_BASEDIR$ cd os/tools

external/iotjs/docs/contributing/Community-Guidelines.md

@@ -7,7 +7,7 @@ Community participants must adhere to these simple rules:
 
 <br>
 
-### Community Consensus, Lazy Consensus and Slient Consent
+### Community Consensus, Lazy Consensus and Silent Consent
 
 Community consensus about a Project issue means that the issue has been submitted to and discussed by Contributors, and that ALL discussing member agree about the issue.<p>
 Lazy consensus means that Contributors may proceed with work when they have reason to believe that other Contributors in the community will agree with the direction of their work, and do not need to stop or initiate unnecessary discussion about the work. Contributors should publish their work (that is, merge proposals to master branch) in a timely manner to allow others to possibly raise issues about the work. When the Contributor is not sure there will be consensus, they should raise a proposal to the community via appropriate public communication channels(**_currently Github issues is possible way to achieve this_**)<p>

external/iotjs/docs/devs/Coding-Style-Guidelines.md

@@ -187,7 +187,7 @@ Do not modify prototypes of builtin objects
 ## Javascript Style Rules
 
 ### Naming
-Use lowerCamelCase for varible names and function names.
+Use lowerCamelCase for variable names and function names.
 
     var myFirstVariable;
     function myFirstFunction {

external/iotjs/docs/devs/Test-Guidelines.md

@@ -2,7 +2,7 @@
 
 Depend on the purpose of the test case (whether it's a positive or negative one), place it under `test/run_pass` or `test/run_fail` directory. The required external resources should be placed into `test/resources`.
 
-All test case files must be named in the following form `test_<module name>[_<functionallity].js` where `<module name>`
+All test case files must be named in the following form `test_<module name>[_<functionality].js` where `<module name>`
 should match one of the JS modules name in the IoT.js. If there is a test case which can not tied to a
 module (like some js features) then the `iotjs` name can be used as module name. It is important to
 correctly specify the module name as the test executor relies on that information.

external/protobuf/README.md

@@ -16,7 +16,7 @@ The following sections detail the steps required to build `protobuf` on TizenRT,
 # Build `protobuf` 
 
 `protobuf` takes in specifications for services and messages in a special `proto` file (with file extension `.proto`), and translates these specifications to actual C++ code that can be used by applications.
-For the translation to happen, `protobuf` needs a protocol complier called `protoc` to compile the specification `.proto` file. Below are mentioned two appproaches for installing `protoc` in your build environment (host OS):
+For the translation to happen, `protobuf` needs a protocol complier called `protoc` to compile the specification `.proto` file. Below are mentioned two approaches for installing `protoc` in your build environment (host OS):
 
 ## Installing `protoc` from source
 
@@ -45,7 +45,7 @@ The following sections describes how to quickly verify the working of `protobuf`
 TizenRT provides a sample program for protobuf, named `addressbook_main` that serializes and deserializes user data.
 `addressbook_main` program could be selected under below menuconfig
 
-[`Application Configuration > Examples > Protocol Buffers exmaple`]
+[`Application Configuration > Examples > Protocol Buffers example`]
 
 Having selected the application as shown above, build it as follows:
 ```

external/protobuf/java/README.md

@@ -92,7 +92,7 @@ Compatibility Notice
   are guaranteed for minor version releases if the user follows the guideline
   described in this section.
 
-* Protobuf major version releases may also be backwards-compatbile with the
+* Protobuf major version releases may also be backwards-compatible with the
   last release of the previous major version. See the release notice for more
   details.
 

external/protobuf/protoc-artifacts/README.md

@@ -108,7 +108,7 @@ repository has all the binaries, close and release this repository.
 
 ## Upload zip packages to github release page.
 After uploading protoc artifacts to Maven Central repository, run the
-build-zip.sh script to bulid zip packages for these protoc binaries
+build-zip.sh script to build zip packages for these protoc binaries
 and upload these zip packages to the download section of the github
 release. For example:
 ```

tools/ramdump/HowToUseRamdump.md

@@ -57,7 +57,7 @@ copying ramdump_0x02020000_0x0210c800.bin to  $TIZENRT_BASEDIR/build/output/bin
 ```
 
 ## How to parse RAMDUMP
-DumpParser Script privodes two interfaces: CUI and GUI
+DumpParser Script provides two interfaces: CUI and GUI
 
 ### DumpParser using CUI
 1. Run Ramdump Parser Script