Repository: incubator-mynewt-site Updated Branches: refs/heads/asf-site 5491806fd -> a993b8370
removed legacy terms from console overview. Also closed pull request #23. Project: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/repo Commit: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/commit/a993b837 Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/a993b837 Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/a993b837 Branch: refs/heads/asf-site Commit: a993b837089dc2c0010d6f547438f32615997097 Parents: 5491806 Author: aditihilbert <ad...@runtime.io> Authored: Thu Mar 3 12:28:50 2016 -0800 Committer: aditihilbert <ad...@runtime.io> Committed: Thu Mar 3 12:28:50 2016 -0800 ---------------------------------------------------------------------- mkdocs/search_index.json | 4 ++-- os/modules/console/console/index.html | 22 +++++++++++----------- sitemap.xml | 16 ++++++++-------- 3 files changed, 21 insertions(+), 21 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/a993b837/mkdocs/search_index.json ---------------------------------------------------------------------- diff --git a/mkdocs/search_index.json b/mkdocs/search_index.json index 632825b..f09e531 100644 --- a/mkdocs/search_index.json +++ b/mkdocs/search_index.json @@ -2827,7 +2827,7 @@ }, { "location": "/os/modules/console/console/", - "text": "Console\n\n\nThe console is an operating system window where users interact with system programs of the operating system or a console application by entering text input (typically from a keyboard) and reading text output (typically on the computer terminal or monitor). The text written on the console brings some information and is a sequence of characters sent by the OS or programs running on the OS. \n\n\nSupport is currently available for console access via the serial port on the hardware board.\n\n\nDescription\n\n\nIn the Mynewt OS, the console library comes in two versions:\n\n\n\n\nfull - containing the full implementation\n\n\nstub - containing stubs for the API\n\n\n\n\nBoth of these have \negg.yml\n file which states that they provide the \nconsole\n API. If an egg uses this API, it should list \nconsole\n as a requirement.\nFor example, the shell egg is defined by the following egg.yml file:\n\n\n egg.name: libs/shell \n egg.vers: 0.1\n egg.de ps:\n - libs/os\n - libs/util\n egg.reqs:\n - console\n egg.identities:\n - SHELL \n\n\n\n\nThe project .yml file decides which version of the console egg should be included. \nIf project requires the full console capability it lists dependency \nlibs/console/full\n in its egg.yml file. On the other hand, a project may not have a physical console (e.g. a UART port to connect a terminal to) but may have a dependency on an egg that has console capability. In that case you would use a console stub. \n\n\nAnother example would be the bootloader project where we want to keep the size of the image small. It includes the \nlibs/os\n egg that can print out messages on a console (e.g. if there is a hard fault) and the \nlibs/util\n egg that uses full console (but only if SHELL is present to provide a CLI). However, we do not want to use any console I/O capability in this particular bootloader project to keep the size small. We simply use the console stub ins tead, and the egg.yml file for the project boot egg looks like the following:\n\n\n project.name: boot\n project.identities: bootloader\n project.eggs:\n - libs/os\n - libs/bootutil\n - libs/nffs\n - libs/console/stub\n - libs/util \n\n\n\n\nConsole has 2 modes for transmit; \nblocking mode\n and \nnon-blocking mode\n. Usually the \nnon-blocking mode\n is the active one; the output buffer is drained by getting TX completion interrupts from hardware, and more data is added based on these interrupts.\n\nBlocking mode\n is used when we don't want TX completion interrupts. It is used when system crashes, and we still want to output info related to that crash.\n\n\nConsole, by default, echoes everything it receives back. Terminal programs expect this, and is a way for the user to know that the console is connected and responsive. Whether echoing happens or not can be controlled programmatically.\n\n\nData structures\n\n\nN/A\n\n\nList of Functi ons\n\n\nThe functions available in console are:\n\n\n\n\nconsole_blocking_mode\n\n\nconsole_echo\n\n\nconsole_init\n\n\nconsole_is_init\n\n\nconsole_printf\n\n\nconsole_read\n\n\nconsole_write", + "text": "Console\n\n\nThe console is an operating system window where users interact with system programs of the operating system or a console application by entering text input (typically from a keyboard) and reading text output (typically on the computer terminal or monitor). The text written on the console brings some information and is a sequence of characters sent by the OS or programs running on the OS. \n\n\nSupport is currently available for console access via the serial port on the hardware board.\n\n\nDescription\n\n\nIn the Mynewt OS, the console library comes in two versions:\n\n\n\n\nfull - containing the full implementation\n\n\nstub - containing stubs for the API\n\n\n\n\nBoth of these have \npkg.yml\n file which states that they provide the \nconsole\n API. If a pkg uses this API, it should list \nconsole\n as a requirement.\nFor example, the shell pkg is defined by the following pkg.yml file:\n\n\n pkg.name: libs/shell \n pkg.vers: 0.1\n pkg.dep s:\n - libs/os\n - libs/util\n pkg.reqs:\n - console\n pkg.identities:\n - SHELL \n\n\n\n\nThe project .yml file decides which version of the console pkg should be included. \nIf project requires the full console capability it lists dependency \nlibs/console/full\n in its pkg.yml file. On the other hand, a project may not have a physical console (e.g. a UART port to connect a terminal to) but may have a dependency on a pkg that has console capability. In that case you would use a console stub. \n\n\nAnother example would be the bootloader project where we want to keep the size of the image small. It includes the \nlibs/os\n pkg that can print out messages on a console (e.g. if there is a hard fault) and the \nlibs/util\n pkg that uses full console (but only if SHELL is present to provide a CLI). However, we do not want to use any console I/O capability in this particular bootloader project to keep the size small. We simply use the console stub inste ad, and the pkg.yml file for the project boot pkg looks like the following:\n\n\n project.name: boot\n project.identities: bootloader\n project.pkgs:\n - libs/os\n - libs/bootutil\n - libs/nffs\n - libs/console/stub\n - libs/util \n\n\n\n\nConsole has 2 modes for transmit; \nblocking mode\n and \nnon-blocking mode\n. Usually the \nnon-blocking mode\n is the active one; the output buffer is drained by getting TX completion interrupts from hardware, and more data is added based on these interrupts.\n\nBlocking mode\n is used when we don't want TX completion interrupts. It is used when system crashes, and we still want to output info related to that crash.\n\n\nConsole, by default, echoes everything it receives back. Terminal programs expect this, and is a way for the user to know that the console is connected and responsive. Whether echoing happens or not can be controlled programmatically.\n\n\nData structures\n\n\nN/A\n\n\nList of Function s\n\n\nThe functions available in console are:\n\n\n\n\nconsole_blocking_mode\n\n\nconsole_echo\n\n\nconsole_init\n\n\nconsole_is_init\n\n\nconsole_printf\n\n\nconsole_read\n\n\nconsole_write", "title": "Overview" }, { @@ -2837,7 +2837,7 @@ }, { "location": "/os/modules/console/console/#description", - "text": "In the Mynewt OS, the console library comes in two versions: full - containing the full implementation stub - containing stubs for the API Both of these have egg.yml file which states that they provide the console API. If an egg uses this API, it should list console as a requirement.\nFor example, the shell egg is defined by the following egg.yml file: egg.name: libs/shell \n egg.vers: 0.1\n egg.deps:\n - libs/os\n - libs/util\n egg.reqs:\n - console\n egg.identities:\n - SHELL The project .yml file decides which version of the console egg should be included. \nIf project requires the full console capability it lists dependency libs/console/full in its egg.yml file. On the other hand, a project may not have a physical console (e.g. a UART port to connect a terminal to) but may have a dependency on an egg that has console capability. In that case you would use a console stub. Another example would be t he bootloader project where we want to keep the size of the image small. It includes the libs/os egg that can print out messages on a console (e.g. if there is a hard fault) and the libs/util egg that uses full console (but only if SHELL is present to provide a CLI). However, we do not want to use any console I/O capability in this particular bootloader project to keep the size small. We simply use the console stub instead, and the egg.yml file for the project boot egg looks like the following: project.name: boot\n project.identities: bootloader\n project.eggs:\n - libs/os\n - libs/bootutil\n - libs/nffs\n - libs/console/stub\n - libs/util Console has 2 modes for transmit; blocking mode and non-blocking mode . Usually the non-blocking mode is the active one; the output buffer is drained by getting TX completion interrupts from hardware, and more data is added based on these interrupts. Blocking mode is used when we don't want TX completion interrupts. It is used when system crashes, and we still want to output info related to that crash. Console, by default, echoes everything it receives back. Terminal programs expect this, and is a way for the user to know that the console is connected and responsive. Whether echoing happens or not can be controlled programmatically.", + "text": "In the Mynewt OS, the console library comes in two versions: full - containing the full implementation stub - containing stubs for the API Both of these have pkg.yml file which states that they provide the console API. If a pkg uses this API, it should list console as a requirement.\nFor example, the shell pkg is defined by the following pkg.yml file: pkg.name: libs/shell \n pkg.vers: 0.1\n pkg.deps:\n - libs/os\n - libs/util\n pkg.reqs:\n - console\n pkg.identities:\n - SHELL The project .yml file decides which version of the console pkg should be included. \nIf project requires the full console capability it lists dependency libs/console/full in its pkg.yml file. On the other hand, a project may not have a physical console (e.g. a UART port to connect a terminal to) but may have a dependency on a pkg that has console capability. In that case you would use a console stub. Another example would be the bootloader project where we want to keep the size of the image small. It includes the libs/os pkg that can print out messages on a console (e.g. if there is a hard fault) and the libs/util pkg that uses full console (but only if SHELL is present to provide a CLI). However, we do not want to use any console I/O capability in this particular bootloader project to keep the size small. We simply use the console stub instead, and the pkg.yml file for the project boot pkg looks like the following: project.name: boot\n project.identities: bootloader\n project.pkgs:\n - libs/os\n - libs/bootutil\n - libs/nffs\n - libs/console/stub\n - libs/util Console has 2 modes for transmit; blocking mode and non-blocking mode . Usually the non-blocking mode is the active one; the output buffer is drained by getting TX completion interrupts from hardware, and more data is added based on these interrupts. Blocking mode is used when we don't want T X completion interrupts. It is used when system crashes, and we still want to output info related to that crash. Console, by default, echoes everything it receives back. Terminal programs expect this, and is a way for the user to know that the console is connected and responsive. Whether echoing happens or not can be controlled programmatically.", "title": "Description" }, { http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/a993b837/os/modules/console/console/index.html ---------------------------------------------------------------------- diff --git a/os/modules/console/console/index.html b/os/modules/console/console/index.html index cec9913..f71d6bd 100644 --- a/os/modules/console/console/index.html +++ b/os/modules/console/console/index.html @@ -378,25 +378,25 @@ <li>full - containing the full implementation</li> <li>stub - containing stubs for the API</li> </ul> -<p>Both of these have <code>egg.yml</code> file which states that they provide the <code>console</code> API. If an egg uses this API, it should list <code>console</code> as a requirement. -For example, the shell egg is defined by the following egg.yml file:</p> -<pre><code class="no-highlight"> egg.name: libs/shell - egg.vers: 0.1 - egg.deps: +<p>Both of these have <code>pkg.yml</code> file which states that they provide the <code>console</code> API. If a pkg uses this API, it should list <code>console</code> as a requirement. +For example, the shell pkg is defined by the following pkg.yml file:</p> +<pre><code class="no-highlight"> pkg.name: libs/shell + pkg.vers: 0.1 + pkg.deps: - libs/os - libs/util - egg.reqs: + pkg.reqs: - console - egg.identities: + pkg.identities: - SHELL </code></pre> -<p>The project .yml file decides which version of the console egg should be included. -If project requires the full console capability it lists dependency <code>libs/console/full</code> in its egg.yml file. On the other hand, a project may not have a physical console (e.g. a UART port to connect a terminal to) but may have a dependency on an egg that has console capability. In that case you would use a console stub. </p> -<p>Another example would be the bootloader project where we want to keep the size of the image small. It includes the <code>libs/os</code> egg that can print out messages on a console (e.g. if there is a hard fault) and the <code>libs/util</code> egg that uses full console (but only if SHELL is present to provide a CLI). However, we do not want to use any console I/O capability in this particular bootloader project to keep the size small. We simply use the console stub instead, and the egg.yml file for the project boot egg looks like the following:</p> +<p>The project .yml file decides which version of the console pkg should be included. +If project requires the full console capability it lists dependency <code>libs/console/full</code> in its pkg.yml file. On the other hand, a project may not have a physical console (e.g. a UART port to connect a terminal to) but may have a dependency on a pkg that has console capability. In that case you would use a console stub. </p> +<p>Another example would be the bootloader project where we want to keep the size of the image small. It includes the <code>libs/os</code> pkg that can print out messages on a console (e.g. if there is a hard fault) and the <code>libs/util</code> pkg that uses full console (but only if SHELL is present to provide a CLI). However, we do not want to use any console I/O capability in this particular bootloader project to keep the size small. We simply use the console stub instead, and the pkg.yml file for the project boot pkg looks like the following:</p> <pre><code class="no-highlight"> project.name: boot project.identities: bootloader - project.eggs: + project.pkgs: - libs/os - libs/bootutil - libs/nffs http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/a993b837/sitemap.xml ---------------------------------------------------------------------- diff --git a/sitemap.xml b/sitemap.xml index efef728..e612cd3 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -4,7 +4,7 @@ <url> <loc>http://mynewt.apache.org/</loc> - <lastmod>2016-03-02</lastmod> + <lastmod>2016-03-03</lastmod> <changefreq>daily</changefreq> </url> @@ -12,7 +12,7 @@ <url> <loc>http://mynewt.apache.org/documentation/</loc> - <lastmod>2016-03-02</lastmod> + <lastmod>2016-03-03</lastmod> <changefreq>daily</changefreq> </url> @@ -20,7 +20,7 @@ <url> <loc>http://mynewt.apache.org/download/</loc> - <lastmod>2016-03-02</lastmod> + <lastmod>2016-03-03</lastmod> <changefreq>daily</changefreq> </url> @@ -28,7 +28,7 @@ <url> <loc>http://mynewt.apache.org/community/</loc> - <lastmod>2016-03-02</lastmod> + <lastmod>2016-03-03</lastmod> <changefreq>daily</changefreq> </url> @@ -36,7 +36,7 @@ <url> <loc>http://mynewt.apache.org/events/</loc> - <lastmod>2016-03-02</lastmod> + <lastmod>2016-03-03</lastmod> <changefreq>daily</changefreq> </url> @@ -45,7 +45,7 @@ <url> <loc>http://mynewt.apache.org/os/get_started/introduction/</loc> - <lastmod>2016-03-02</lastmod> + <lastmod>2016-03-03</lastmod> <changefreq>daily</changefreq> </url> @@ -79,7 +79,7 @@ <url> <loc>http://mynewt.apache.org/newt/newt_intro/</loc> - <lastmod>2016-03-02</lastmod> + <lastmod>2016-03-03</lastmod> <changefreq>daily</changefreq> </url> @@ -101,7 +101,7 @@ <url> <loc>http://mynewt.apache.org/newtmgr/overview/</loc> - <lastmod>2016-03-02</lastmod> + <lastmod>2016-03-03</lastmod> <changefreq>daily</changefreq> </url>
