You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mynewt.apache.org by ad...@apache.org on 2016/11/18 01:14:41 UTC
[1/7] incubator-mynewt-site git commit: Updated events. Updated event
queue documentation. This closes #126
Repository: incubator-mynewt-site
Updated Branches:
refs/heads/asf-site 0e97d5b38 -> db7dea53a
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/latest/os/tutorials/tasks_lesson/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/tasks_lesson/index.html b/latest/os/tutorials/tasks_lesson/index.html
index d3a9e4e..ddfaa7e 100644
--- a/latest/os/tutorials/tasks_lesson/index.html
+++ b/latest/os/tutorials/tasks_lesson/index.html
@@ -442,9 +442,15 @@
<h1 id="core-os-lesson-tasks-and-priority-management">Core OS Lesson: Tasks and Priority Management</h1>
<p><strong>Target Platform: Arduino M0 Pro</strong> (or legacy Arduino Zero or Zero Pro, but not Arduino M0)</p>
-<p>This lesson is designed to teach core OS concepts and strategies encountered when building applications using Mynewt. Specifically, this lesson will cover tasks, simple multitasking, and priority management running on an Arduino M0 Pro.</p>
+<p>This lesson is designed to teach core OS concepts and strategies encountered when
+building applications using Mynewt. Specifically, this lesson will cover tasks,
+simple multitasking, and priority management running on an Arduino M0 Pro.</p>
<h2 id="prerequisites">Prerequisites</h2>
-<p>Before starting, you should read about Mynewt in the <a href="http://mynewt.apache.org/os/introduction/"><em>Introduction</em></a> section and complete the <a href="http://mynewt.apache.org/os/get_started/get_started/"><em>QuickStart</em></a> guide and the <a href="http://mynewt.apache.org/os/tutorials/arduino_zero/"><em>Blinky</em></a> tutorial. Furthermore, it may be helpful to take a peek at the <a href="http://mynewt.apache.org/os/core_os/task/task/"><em>task documentation</em></a> for additional insights.</p>
+<p>Before starting, you should read about Mynewt in the <a href="http://mynewt.apache.org/os/introduction/"><em>Introduction</em></a>
+section and complete the <a href="http://mynewt.apache.org/os/get_started/get_started/"><em>QuickStart</em></a>
+guide and the <a href="http://mynewt.apache.org/os/tutorials/arduino_zero/"><em>Blinky</em></a> tutorial.
+Furthermore, it may be helpful to take a peek at the <a href="http://mynewt.apache.org/os/core_os/task/task/"><em>task documentation</em></a>
+for additional insights.</p>
<h2 id="equipment">Equipment</h2>
<p>You will need the following equipment:</p>
<ul>
@@ -453,17 +459,28 @@
<li>USB to Micro USB Cable</li>
</ul>
<h2 id="build-your-application">Build Your Application</h2>
-<p>To save time, we will simply modify the Blinky app as it has the basic task structure already implemented. Follow the <a href="http://mynewt.apache.org/os/tutorials/arduino_zero/"><em>Arduino Zero Blinky tutorial</em></a> to create a new project and build your bootloader and application. Finally, build and load the application to your Arduino to verify that everything is in order. Now let\u2019s get started!</p>
+<p>To save time, we will simply modify the Blinky app. We'll add the Task Management code to
+the Blinky app. Follow the <a href="http://mynewt.apache.org/os/tutorials/arduino_zero/"><em>Arduino Zero Blinky tutorial</em></a>
+to create a new project and build your bootloader and application. Finally, build and
+load the application to your Arduino to verify that everything is in order. Now let\u2019s get started!</p>
<h2 id="create-a-new-task">Create a New Task</h2>
-<p>The purpose of this section is to give an introduction to the important aspects of tasks and how to properly initialize them. First, let\u2019s define a second task called <code>work_task</code> in main.c (located in apps/blinky/src):</p>
+<p>The purpose of this section is to give an introduction to the important aspects of tasks
+and how to properly initialize them. First, let\u2019s define a second task called <code>work_task</code>
+in main.c (located in apps/blinky/src):</p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">struct</span> <span style="color: #000000">os_task</span> <span style="color: #000000">work_task</span>;
</pre></div>
-<p>A task is represented by the <a href="http://mynewt.apache.org/os/core_os/task/task/#data-structures"><em>os_task</em></a> struct which will hold the task\u2019s information (name, state, priority, etc.). A task is made up of two main elements, a task function (also known as a task handler) and a task stack.</p>
+<p>A task is represented by the <a href="http://mynewt.apache.org/os/core_os/task/task/#data-structures"><em>os_task</em></a><br />
+struct which will hold the task\u2019s information (name, state, priority, etc.). A task is made up of two
+main elements, a task function (also known as a task handler) and a task stack.</p>
<p>Next, let\u2019s take a look at what is required to initialize our new task.</p>
<h3 id="task-stack">Task Stack</h3>
-<p>The task stack is an array of type <code>os_stack_t</code> which holds the program stack frames. Mynewt gives us the ability to set the stack size for a task giving the application developer room to optimize memory usage. Since we\u2019re not short on memory, our <code>blinky_stack</code> and <code>work_stack</code> are plenty large for the purpose of this lesson. Notice that the elements in our task stack are of type <code>os_stack_t</code> which are generally 32 bits, making our entire stack 1024 Bytes.</p>
+<p>The task stack is an array of type <code>os_stack_t</code> which holds the program stack frames. Mynewt gives
+us the ability to set the stack size for a task giving the application developer room to optimize
+memory usage. Since we\u2019re not short on memory, our <code>blinky_stack</code> and <code>work_stack</code> are plenty large
+for the purpose of this lesson. Notice that the elements in our task stack are of type <code>os_stack_t</code>
+which are generally 32 bits, making our entire stack 1024 Bytes.</p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"> <span style="color: #633820">#define WORK_STACK_SIZE OS_STACK_ALIGN(256)</span>
<span style="color: #A90D91">os_stack_t</span> <span style="color: #000000">work_stack</span>[<span style="color: #000000">WORK_STACK_SIZE</span>];
</pre></div>
@@ -471,7 +488,10 @@
<p>Note: The <code>OS_STACK_ALIGN</code> macro is used to align the stack based on the hardware architecture.</p>
<h3 id="task-function">Task Function</h3>
-<p>The task function is essentially an infinite loop which waits for some \u201cevent\u201d to wake it up. In our Blinky app the task function, named <code>blinky_task_handler()</code>, is initially called when we call <code>os_start()</code> in <code>main()</code>. In general, the task function is where the majority of work is done by a task. Let\u2019s write a task function for <code>work_task</code> called <code>work_task_handler()</code>:</p>
+<p>The task function is essentially an infinite loop which waits for some \u201cevent\u201d to wake it up. In our
+Blinky app the task function, named <code>blinky_task_handler()</code>, is initially called when we call <code>os_start()</code>
+in <code>main()</code>. In general, the task function is where the majority of work is done by a task. Let\u2019s write
+a task function for <code>work_task</code> called <code>work_task_handler()</code>:</p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">void</span>
<span style="color: #000000">work_task_handler</span>(<span style="color: #A90D91">void</span> <span style="color: #000000">*arg</span>)
{
@@ -489,16 +509,23 @@
</pre></div>
-<p>The task function is called when the task is initially put into the <em>running</em> state by the scheduler. We use an infinite loop to ensure that the task function never returns. Our assertion that the current task's handler is the same as our task handler is for illustration purposes only and does not need to be in most task functions.</p>
+<p>The task function is called when the task is initially put into the <em>running</em> state by the scheduler.
+We use an infinite loop to ensure that the task function never returns. Our assertion that the current
+task's handler is the same as our task handler is for illustration purposes only and does not need to
+be in most task functions.</p>
<h3 id="task-priority">Task Priority</h3>
-<p>As a preemptive, multitasking RTOS, Mynewt decides which tasks to run based on which has a higher priority; the highest priority being 0 and the lowest 255. Thus, before initializing our task, we must choose a priority defined as a macro variable.</p>
+<p>As a preemptive, multitasking RTOS, Mynewt decides which tasks to run based on which has a higher
+priority; the highest priority being 0 and the lowest 255. Thus, before initializing our task, we
+must choose a priority defined as a macro variable.</p>
<p>Let\u2019s set the priority of <code>work_task</code> to 0, because everyone knows that work is more important than blinking.</p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"> <span style="color: #633820">#define WORK_TASK_PRIO (0)</span>
</pre></div>
<h3 id="initialization">Initialization</h3>
-<p>To initialize a new task we use <a href="http://mynewt.apache.org/os/core_os/task/os_task_init/"><em>os_task_init()</em></a> which takes a number of arguments including our new task function, stack, and priority. Much like <code>blinky_task</code>, we\u2019re going to initialize <code>work_task</code> inside <code>init_tasks</code> to keep our main function clean.</p>
+<p>To initialize a new task we use <a href="http://mynewt.apache.org/os/core_os/task/os_task_init/"><em>os_task_init()</em></a>
+which takes a number of arguments including our new task function, stack, and priority. Much like <code>blinky_task</code>,
+we\u2019re going to initialize <code>work_task</code> inside <code>init_tasks</code> to keep our main function clean.</p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">int</span>
<span style="color: #000000">init_tasks</span>(<span style="color: #A90D91">void</span>)
{
@@ -551,8 +578,15 @@
<h2 id="task-priority-preempting-and-context-switching">Task Priority, Preempting, and Context Switching</h2>
-<p>A preemptive RTOS is one in which a higher priority task that is <em>ready to run</em> will preempt (i.e. take the place of) the lower priority task which is <em>running</em>. When a lower priority task is preempted by a higher priority task, the lower priority task\u2019s context data (stack pointer, registers, etc.) is saved and the new task is switched in.</p>
-<p>In our example, <code>work_task</code> has a higher priority than <code>blinky_task</code> and, because it is never put into a <em>sleep</em> state, holds the processor focus on its context. Let\u2019s give <code>work_task</code> a delay and some simulated work to keep it busy. Because the delay is measured in os ticks, the actual number of ticks per second is dependent on the board. Therefore, we multiply <code>OS_TICKS_PER_SEC</code>, which is defined in the MCU, by the number of seconds we wish to delay.</p>
+<p>A preemptive RTOS is one in which a higher priority task that is <em>ready to run</em> will preempt (i.e. take the
+place of) the lower priority task which is <em>running</em>. When a lower priority task is preempted by a higher
+priority task, the lower priority task\u2019s context data (stack pointer, registers, etc.) is saved and the new
+task is switched in.</p>
+<p>In our example, <code>work_task</code> has a higher priority than <code>blinky_task</code> and, because it is never put into a
+<em>sleep</em> state, holds the processor focus on its context. Let\u2019s give <code>work_task</code> a delay and some simulated
+work to keep it busy. Because the delay is measured in os ticks, the actual number of ticks per second is
+dependent on the board. Therefore, we multiply <code>OS_TICKS_PER_SEC</code>, which is defined in the MCU, by the
+number of seconds we wish to delay.</p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">void</span>
<span style="color: #000000">work_task_handler</span>(<span style="color: #A90D91">void</span> <span style="color: #000000">*arg</span>)
{
@@ -581,17 +615,28 @@
</pre></div>
-<p>Before we run the app, let\u2019s predict the behavior. With the newest additions to <code>work_task_handler()</code>, our first action will be to sleep for three seconds. This will allow <code>blinky_task</code> to take over the CPU and blink to its heart\u2019s content. After three seconds, <code>work_task</code> will wake up and be made <em>ready to run</em>, causing it to preempt <code>blinky_task</code>. The LED will then remain lit for a short period while <code>work_task</code> loops, then blink again for another three seconds while <code>work_task</code> sleeps. </p>
+<p>Before we run the app, let\u2019s predict the behavior. With the newest additions to <code>work_task_handler()</code>,
+our first action will be to sleep for three seconds. This will allow <code>blinky_task</code> to take over the CPU
+and blink to its heart\u2019s content. After three seconds, <code>work_task</code> will wake up and be made <em>ready to run</em>,
+causing it to preempt <code>blinky_task</code>. The LED will then remain lit for a short period while <code>work_task</code>
+loops, then blink again for another three seconds while <code>work_task</code> sleeps. </p>
<p>Voila, you should see that our prediction was correct! </p>
<h3 id="priority-management-considerations">Priority Management Considerations</h3>
-<p>When projects grow in scope, from blinking LEDs into more sophisticated applications, the number of tasks needed increases alongside complexity. It remains important, then, that each of our tasks is capable of doing its work within a reasonable amount of time.</p>
-<p>Some tasks, such as the Shell task, execute quickly and require almost instantaneous response. Therefore, the Shell task should be given a high priority. On the other hand, tasks which may be communicating over a network, or processing data, should be given a low priority in order to not hog the CPU.</p>
-<p>The diagram below showcases the different scheduling patterns we. would expect from swapping blinky and work tasks priorities.</p>
+<p>When projects grow in scope, from blinking LEDs into more sophisticated applications, the number of
+tasks needed increases alongside complexity. It remains important, then, that each of our tasks is
+capable of doing its work within a reasonable amount of time.</p>
+<p>Some tasks, such as the Shell task, execute quickly and require almost instantaneous response. Therefore,
+the Shell task should be given a high priority. On the other hand, tasks which may be communicating over
+a network, or processing data, should be given a low priority in order to not hog the CPU.</p>
+<p>The diagram below showcases the different scheduling patterns we. would expect from swapping blinky and
+work tasks priorities.</p>
<p><img alt="Task Scheduling" src="../pics/task_lesson.png" /></p>
-<p>In the second case where <code>blinky_task</code> has a higher priority, the \u201cwork\u201d done by <code>work_task</code> would be executed during the millisecond delays in <code>blinky_task</code>, saving us idle time compared to the first case.</p>
+<p>In the second case where <code>blinky_task</code> has a higher priority, the \u201cwork\u201d done by <code>work_task</code> would be
+executed during the millisecond delays in <code>blinky_task</code>, saving us idle time compared to the first case.</p>
<p><strong>Note:</strong> Defining the same priority for two tasks leads to somewhat undefined behavior and should be avoided.</p>
<h2 id="comparing-priority-strategies">Comparing Priority Strategies</h2>
-<p>Instead of stepping through a bunch of changes to our blinky app, clone my task lesson application from github and copy an existing target.</p>
+<p>Instead of stepping through a bunch of changes to our blinky app, clone my task lesson application from
+github and copy an existing target.</p>
<p>Change directory into apps and clone the repository to get our new
files:</p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%">$ cd apps
@@ -609,28 +654,38 @@ $ git clone https://github.com/bgiori/mynewt_tasks_lesson.git
</pre></div>
-<p>Now let\u2019s take a look at our new code. First, notice that we have abandoned blinking, instead choosing to use the <a href="http://mynewt.apache.org/latest/os/modules/console/console/"><em>console</em></a> and <a href="http://mynewt.apache.org/latest/os/modules/shell/shell/"><em>shell</em></a> to follow our tasks through execution.</p>
+<p>Now let\u2019s take a look at our new code. First, notice that we have abandoned blinking, instead choosing t
+o use the <a href="http://mynewt.apache.org/latest/os/modules/console/console/"><em>console</em></a> and <a href="http://mynewt.apache.org/latest/os/modules/shell/shell/"><em>shell</em></a>
+to follow our tasks through execution.</p>
<p>Additionally, we have a number of different tasks:</p>
<ul>
<li>
<p><strong>Task A</strong> (<code>a_task</code>):</p>
<ul>
<li><strong>Priority</strong>: 3 \u2192 2</li>
-<li><strong>Description</strong>: Task A is supposed to represent a task which frequently does a small amount of work, such as one which rapidly polls a sensor for data. Much like <code>blinky_task</code>, Task A will loop 10,000 times then wait 1 millisecond. Priority is changed by <code>timer_task</code> after the first simulation.</li>
+<li><strong>Description</strong>: Task A is supposed to represent a task which frequently does a small amount
+of work, such as one which rapidly polls a sensor for data. Much like <code>blinky_task</code>, Task A will
+loop 10,000 times then wait 1 millisecond. Priority is changed by <code>timer_task</code> after the first simulation.</li>
</ul>
</li>
<li>
<p><strong>Task B</strong> (<code>b_task</code>):</p>
<ul>
<li><strong>Priority</strong>: 2 \u2192 3</li>
-<li><strong>Description</strong>: Task B is supposed to represent a task which does a large amount of work relatively infrequently, such as one which sends/receives data from the cloud. Like work_task, Task B will loop 1,000,000 times then wait 3 seconds. Priority is changed by timer_task after the first simulation.</li>
+<li><strong>Description</strong>: Task B is supposed to represent a task which does a large amount of work
+relatively infrequently, such as one which sends/receives data from the cloud. Like work_task,
+Task B will loop 1,000,000 times then wait 3 seconds. Priority is changed by timer_task after
+the first simulation.</li>
</ul>
</li>
<li>
<p><strong>Timer Task</strong> (<code>timer_task</code>):</p>
<ul>
<li><strong>Priority</strong>: 1</li>
-<li><strong>Description</strong>: With default settings, Timer Task will wait 20 seconds then print the first simulations data for Task A and B. Timer task will then swap A and B\u2019s priorities and restart the simulation. After the second simulation, timer will again print simulation data then compare the two and calculate a final speedup (simulation2 / simulation1).</li>
+<li><strong>Description</strong>: With default settings, Timer Task will wait 20 seconds then print the first
+simulations data for Task A and B. Timer task will then swap A and B\u2019s priorities and restart the
+simulation. After the second simulation, timer will again print simulation data then compare the
+two and calculate a final speedup (simulation2 / simulation1).</li>
</ul>
</li>
<li>
@@ -642,7 +697,9 @@ $ git clone https://github.com/bgiori/mynewt_tasks_lesson.git
</li>
</ul>
<h3 id="connecting-to-the-serial-console">Connecting to the Serial Console</h3>
-<p>Before running our new app, we must first connect to the serial console. First make sure the mynewt_arduino_zero repository is set to the develop branch. (Remove once changes have been moved to master). </p>
+<p>Before running our new app, we must first connect to the serial console. First make sure the
+mynewt_arduino_zero repository is set to the develop branch. (Remove once changes have been
+moved to master). </p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%">$ cd repos/mynewt_arduino_zero
$ git checkout develop
</pre></div>
@@ -655,7 +712,8 @@ $ git checkout develop
</pre></div>
-<p>In the same window, connect to the serial port using a serial communication program. In this case I\u2019ll be using mincom as it can scroll through output.</p>
+<p>In the same window, connect to the serial port using a serial communication program.
+In this case I\u2019ll be using mincom as it can scroll through output.</p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #000000">$</span> <span style="color: #000000">minicom</span> <span style="color: #000000">-D</span> <span style="color: #000000">/dev/tty</span>.<span style="color: #000000">usbmodem14132</span> <span style="color: #000000">-b</span> <span style="color: #1C01CE">115200</span>
</pre></div>
@@ -726,16 +784,49 @@ $ git checkout develop
</pre></div>
-<p>The console output reaffirms our previous prediction and makes both the scheduling differences and subsequent efficiency boost far more apparent. Let\u2019s take a look at scheduling differences before we delve into efficiency.</p>
-<p>In the first case, where Task B\u2019s priority is higher than that of Task A, we see A get starved by Task B\u2019s long execution time. <strong>Starvation</strong> occurs when one task hogs the processor, essentially \u201cstarving\u201d other tasks which also need to run. At the end of the first 20 second simulation period, Task A has only run for 1.4 seconds compared to task B\u2019s 17 second running time \u2013 ouch. As explained before, processes which are expected to run for long periods of time (e.g. network communication, data processing) should be given higher priorities in order to combat starvation.</p>
-<p>In the second simulation with priorities swapped, we can see Task B only running during the millisecond delays when Task A is <em>sleeping</em>. Although having Task B only run during these delays slows its execution time, we benefit from un-starving Task A and using the processor at a higher efficiency.</p>
-<p>The bottom line speedup gives us an immediate and clear indication that we have improved our ability to process work (i.e throughput). In our second run, we processed an additional 400,000 loop iterations, equating to a 26% increase in efficiency. On a standard multi-core processor found in every modern PC, a 1.26 speedup would be an ok result to adding multithreading capabilities to a serial program. However, we accomplished this by simply setting priorities on a single core processor \u2013 not bad!</p>
-<p>NOTE: Usually the the term \u201cspeedup\u201d is used within a parallel programming context and refers to the change in execution time between a serial and parallel program executing over the same problem. In this case we\u2019re using the term loosely to illustrate the priority change\u2019s effect on scheduling and throughput in our specific context.</p>
+<p>The console output reaffirms our previous prediction and makes both the scheduling differences
+and subsequent efficiency boost far more apparent. Let\u2019s take a look at scheduling differences
+before we delve into efficiency.</p>
+<p>In the first case, where Task B\u2019s priority is higher than that of Task A, we see A get starved
+by Task B\u2019s long execution time. <strong>Starvation</strong> occurs when one task hogs the processor, essentially
+\u201cstarving\u201d other tasks which also need to run. At the end of the first 20 second simulation period,
+Task A has only run for 1.4 seconds compared to task B\u2019s 17 second running time \u2013 ouch. As explained
+before, processes which are expected to run for long periods of time (e.g. network communication,
+data processing) should be given higher priorities in order to combat starvation.</p>
+<p>In the second simulation with priorities swapped, we can see Task B only running during the
+millisecond delays when Task A is <em>sleeping</em>. Although having Task B only run during these
+delays slows its execution time, we benefit from un-starving Task A and using the processor
+at a higher efficiency.</p>
+<p>The bottom line speedup gives us an immediate and clear indication that we have improved our
+ability to process work (i.e throughput). In our second run, we processed an additional 400,000
+loop iterations, equating to a 26% increase in efficiency. On a standard multi-core processor
+found in every modern PC, a 1.26 speedup would be an ok result to adding multithreading capabilities
+to a serial program. However, we accomplished this by simply setting priorities on a single core
+processor \u2013 not bad!</p>
+<p>NOTE: Usually the the term \u201cspeedup\u201d is used within a parallel programming context and refers
+to the change in execution time between a serial and parallel program executing over the same
+problem. In this case we\u2019re using the term loosely to illustrate the priority change\u2019s effect
+on scheduling and throughput in our specific context.</p>
<h3 id="efficiency-isnt-everything">Efficiency Isn\u2019t Everything</h3>
-<p>Using the processor during every OS tick isn\u2019t always the best course of action. If we modify Task A\u2019s delay to a tenth of a millisecond and turn off the console output, we can boost our speedup to 1.44. This, however, reduces our ability to process work from Task B who ends up only completing 18% of its work cycle after the second simulation. That would mean, at that rate, Task B would take over a minute to finish one cycle.</p>
+<p>Using the processor during every OS tick isn\u2019t always the best course of action. If we modify
+Task A\u2019s delay to a tenth of a millisecond and turn off the console output, we can boost our
+speedup to 1.44. This, however, reduces our ability to process work from Task B who ends up
+only completing 18% of its work cycle after the second simulation. That would mean, at that
+rate, Task B would take over a minute to finish one cycle.</p>
<p>Feel free to play around with the testing parameters to study the different changes yourself!</p>
<h2 id="conclusion">Conclusion</h2>
-<p>Moving forward, tasks are just the tip of the iceberg. The <a href="http://mynewt.apache.org/latest/os/core_os/context_switch/context_switch/"><em>scheduler</em></a>, <a href="http://mynewt.apache.org/latest/os/core_os/event_queue/event_queue/"><em>event queues</em></a>, <a href="http://mynewt.apache.org/latest/os/core_os/semaphore/semaphore/"><em>semaphores</em></a>, and <a href="http://mynewt.apache.org/latest/os/core_os/mutex/mutex/"><em>mutexes</em></a> also add to tasks functionality, increasing our ability as the developer to control greater numbers of tasks more intricately. For example, when we switch the tasks priority, we have to tell the scheduler that our tasks priorities have changed, allowing us us to use priorities dynamically. When running multiple tasks, logging through either the built-in <a href="http://mynewt.apache.org/latest/os/modules/logs/logs/"><em>Logs</em></a> module (not covered in this lesson) or through the serial console/shell can be very useful for
debugging your application. In the end, the way you manage your tasks depends on the context of your application. You should assign priorities based on execution time, urgency, and frequency, among other things.</p>
+<p>Moving forward, tasks are just the tip of the iceberg. The <a href="http://mynewt.apache.org/latest/os/core_os/context_switch/context_switch/"><em>scheduler</em></a>,
+<a href="http://mynewt.apache.org/latest/os/core_os/event_queue/event_queue/"><em>event queues</em></a>,
+<a href="http://mynewt.apache.org/latest/os/core_os/semaphore/semaphore/"><em>semaphores</em></a>, and
+<a href="http://mynewt.apache.org/latest/os/core_os/mutex/mutex/"><em>mutexes</em></a> also add to tasks functionality,
+increasing our ability as the developer to control greater numbers of tasks more intricately. For
+example, when we switch the tasks priority, we have to tell the scheduler that our tasks priorities
+have changed, allowing us us to use priorities dynamically. When running multiple tasks, logging
+through either the built-in <a href="http://mynewt.apache.org/latest/os/modules/logs/logs/"><em>Logs</em></a> module
+(not covered in this lesson) or through the serial console/shell can be very useful for debugging
+your application. In the end, the way you manage your tasks depends on the context of your
+application. You should assign priorities based on execution time, urgency, and frequency, among
+other things.</p>
<p>Keep blinking and happy hacking!</p>
<div class="row">
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/latest/os/tutorials/wi-fi_on_arduino/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/wi-fi_on_arduino/index.html b/latest/os/tutorials/wi-fi_on_arduino/index.html
index bb0a99f..1edc3e0 100644
--- a/latest/os/tutorials/wi-fi_on_arduino/index.html
+++ b/latest/os/tutorials/wi-fi_on_arduino/index.html
@@ -450,7 +450,7 @@
<ul>
<li>An Arduino Zero, Zero Pro or M0 Pro.<br />
<strong>Note:</strong> Mynewt has not been tested on Arduino M0 which has no internal debugger support.</li>
-<li>An Arduino Wi-Fi Shield 101</li>
+<li>An <a href="https://www.adafruit.com/product/2891">Arduino Wi-Fi Shield 101</a></li>
<li>A computer that can connect to the Arduino board over USB</li>
<li>A local Wi-Fi network that the computer is connected to and which the Arduino board can join.</li>
<li>A USB cable (Type A to micro B) that can connect the computer to the Arduino (or a USB hub between the computer and the Arduino board)</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/latest/sitemap.xml
----------------------------------------------------------------------
diff --git a/latest/sitemap.xml b/latest/sitemap.xml
index 6436c47..e834093 100644
--- a/latest/sitemap.xml
+++ b/latest/sitemap.xml
@@ -4,7 +4,7 @@
<url>
<loc>http://mynewt.apache.org/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -13,13 +13,13 @@
<url>
<loc>http://mynewt.apache.org/pages/ble/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>http://mynewt.apache.org/pages/securitybullets/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -28,7 +28,7 @@
<url>
<loc>http://mynewt.apache.org/quick-start/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -36,7 +36,7 @@
<url>
<loc>http://mynewt.apache.org/about/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -44,7 +44,7 @@
<url>
<loc>http://mynewt.apache.org/talks/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -52,7 +52,7 @@
<url>
<loc>http://mynewt.apache.org/download/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -60,7 +60,7 @@
<url>
<loc>http://mynewt.apache.org/community/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -68,7 +68,7 @@
<url>
<loc>http://mynewt.apache.org/events/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -77,7 +77,7 @@
<url>
<loc>http://mynewt.apache.org/os/introduction/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -89,7 +89,7 @@
<url>
<loc>http://mynewt.apache.org/os/get_started/vocabulary/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -129,13 +129,13 @@
<url>
<loc>http://mynewt.apache.org/faq/how_to_edit_docs/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>http://mynewt.apache.org/faq/answers/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/sitemap.xml
----------------------------------------------------------------------
diff --git a/sitemap.xml b/sitemap.xml
index 6436c47..e834093 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -4,7 +4,7 @@
<url>
<loc>http://mynewt.apache.org/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -13,13 +13,13 @@
<url>
<loc>http://mynewt.apache.org/pages/ble/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>http://mynewt.apache.org/pages/securitybullets/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -28,7 +28,7 @@
<url>
<loc>http://mynewt.apache.org/quick-start/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -36,7 +36,7 @@
<url>
<loc>http://mynewt.apache.org/about/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -44,7 +44,7 @@
<url>
<loc>http://mynewt.apache.org/talks/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -52,7 +52,7 @@
<url>
<loc>http://mynewt.apache.org/download/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -60,7 +60,7 @@
<url>
<loc>http://mynewt.apache.org/community/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -68,7 +68,7 @@
<url>
<loc>http://mynewt.apache.org/events/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -77,7 +77,7 @@
<url>
<loc>http://mynewt.apache.org/os/introduction/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -89,7 +89,7 @@
<url>
<loc>http://mynewt.apache.org/os/get_started/vocabulary/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -129,13 +129,13 @@
<url>
<loc>http://mynewt.apache.org/faq/how_to_edit_docs/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>http://mynewt.apache.org/faq/answers/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/v0_9_0/events/index.html
----------------------------------------------------------------------
diff --git a/v0_9_0/events/index.html b/v0_9_0/events/index.html
index d00e22a..ebe24d1 100644
--- a/v0_9_0/events/index.html
+++ b/v0_9_0/events/index.html
@@ -144,17 +144,17 @@
<div class="event">
- <h2>Linaro Connect - Keynote Presentation</h2>
- <p>Time: 16:10 - 16:45, Date: 26 September 2016, 2016</p>
- <p>Grand Ballroom C, JW Marriott Resort and Spa Hotel, Las Vegas, NV</p>
- <p>LAS16-104: Mynewt Technical Overview. Apache Mynewt developers will be available until September 28th to meet and discuss Mynewt OS and associated Newt tool.</p>
+ <h2>CES</h2>
+ <p>5-8 January, 2017</p>
+ <p>Las Vegas, NV</p>
+ <p>Contact runtime.io or email us at dev@mynewt.incubator.apache.org to check out and discuss Apache Mynewt and its many uses.</p>
</div>
<div class="event">
- <h2>ARM TechCon</h2>
- <p>25-27 October, 2016</p>
- <p>Santa Clara Convention Center, Santa Clara, CA, USA</p>
- <p>See Apache Mynewt in action in Booth #805. Watch it enable a variety of functionalities on different boards!</p>
+ <h2>Embedded Systems Conference</h2>
+ <p>6-8 December, 2016</p>
+ <p>San Jose Convention Center, San Jose, CA, USA</p>
+ <p>Meet up to discuss Apache Mynewt.</p>
</div>
</div>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/v0_9_0/sitemap.xml
----------------------------------------------------------------------
diff --git a/v0_9_0/sitemap.xml b/v0_9_0/sitemap.xml
index 6436c47..e834093 100644
--- a/v0_9_0/sitemap.xml
+++ b/v0_9_0/sitemap.xml
@@ -4,7 +4,7 @@
<url>
<loc>http://mynewt.apache.org/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -13,13 +13,13 @@
<url>
<loc>http://mynewt.apache.org/pages/ble/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>http://mynewt.apache.org/pages/securitybullets/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -28,7 +28,7 @@
<url>
<loc>http://mynewt.apache.org/quick-start/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -36,7 +36,7 @@
<url>
<loc>http://mynewt.apache.org/about/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -44,7 +44,7 @@
<url>
<loc>http://mynewt.apache.org/talks/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -52,7 +52,7 @@
<url>
<loc>http://mynewt.apache.org/download/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -60,7 +60,7 @@
<url>
<loc>http://mynewt.apache.org/community/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -68,7 +68,7 @@
<url>
<loc>http://mynewt.apache.org/events/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -77,7 +77,7 @@
<url>
<loc>http://mynewt.apache.org/os/introduction/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -89,7 +89,7 @@
<url>
<loc>http://mynewt.apache.org/os/get_started/vocabulary/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -129,13 +129,13 @@
<url>
<loc>http://mynewt.apache.org/faq/how_to_edit_docs/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>http://mynewt.apache.org/faq/answers/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
[4/7] incubator-mynewt-site git commit: Updated events. Updated event
queue documentation. This closes #126
Posted by ad...@apache.org.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/develop/os/tutorials/tasks_lesson/index.html
----------------------------------------------------------------------
diff --git a/develop/os/tutorials/tasks_lesson/index.html b/develop/os/tutorials/tasks_lesson/index.html
index bc96d54..e867713 100644
--- a/develop/os/tutorials/tasks_lesson/index.html
+++ b/develop/os/tutorials/tasks_lesson/index.html
@@ -442,9 +442,15 @@
<h1 id="core-os-lesson-tasks-and-priority-management">Core OS Lesson: Tasks and Priority Management</h1>
<p><strong>Target Platform: Arduino M0 Pro</strong> (or legacy Arduino Zero or Zero Pro, but not Arduino M0)</p>
-<p>This lesson is designed to teach core OS concepts and strategies encountered when building applications using Mynewt. Specifically, this lesson will cover tasks, simple multitasking, and priority management running on an Arduino M0 Pro.</p>
+<p>This lesson is designed to teach core OS concepts and strategies encountered when
+building applications using Mynewt. Specifically, this lesson will cover tasks,
+simple multitasking, and priority management running on an Arduino M0 Pro.</p>
<h2 id="prerequisites">Prerequisites</h2>
-<p>Before starting, you should read about Mynewt in the <a href="http://mynewt.apache.org/os/introduction/"><em>Introduction</em></a> section and complete the <a href="http://mynewt.apache.org/os/get_started/get_started/"><em>QuickStart</em></a> guide and the <a href="http://mynewt.apache.org/os/tutorials/arduino_zero/"><em>Blinky</em></a> tutorial. Furthermore, it may be helpful to take a peek at the <a href="http://mynewt.apache.org/os/core_os/task/task/"><em>task documentation</em></a> for additional insights.</p>
+<p>Before starting, you should read about Mynewt in the <a href="http://mynewt.apache.org/os/introduction/"><em>Introduction</em></a>
+section and complete the <a href="http://mynewt.apache.org/os/get_started/get_started/"><em>QuickStart</em></a>
+guide and the <a href="http://mynewt.apache.org/os/tutorials/arduino_zero/"><em>Blinky</em></a> tutorial.
+Furthermore, it may be helpful to take a peek at the <a href="http://mynewt.apache.org/os/core_os/task/task/"><em>task documentation</em></a>
+for additional insights.</p>
<h2 id="equipment">Equipment</h2>
<p>You will need the following equipment:</p>
<ul>
@@ -453,17 +459,28 @@
<li>USB to Micro USB Cable</li>
</ul>
<h2 id="build-your-application">Build Your Application</h2>
-<p>To save time, we will simply modify the Blinky app as it has the basic task structure already implemented. Follow the <a href="http://mynewt.apache.org/os/tutorials/arduino_zero/"><em>Arduino Zero Blinky tutorial</em></a> to create a new project and build your bootloader and application. Finally, build and load the application to your Arduino to verify that everything is in order. Now let\u2019s get started!</p>
+<p>To save time, we will simply modify the Blinky app. We'll add the Task Management code to
+the Blinky app. Follow the <a href="http://mynewt.apache.org/os/tutorials/arduino_zero/"><em>Arduino Zero Blinky tutorial</em></a>
+to create a new project and build your bootloader and application. Finally, build and
+load the application to your Arduino to verify that everything is in order. Now let\u2019s get started!</p>
<h2 id="create-a-new-task">Create a New Task</h2>
-<p>The purpose of this section is to give an introduction to the important aspects of tasks and how to properly initialize them. First, let\u2019s define a second task called <code>work_task</code> in main.c (located in apps/blinky/src):</p>
+<p>The purpose of this section is to give an introduction to the important aspects of tasks
+and how to properly initialize them. First, let\u2019s define a second task called <code>work_task</code>
+in main.c (located in apps/blinky/src):</p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">struct</span> <span style="color: #000000">os_task</span> <span style="color: #000000">work_task</span>;
</pre></div>
-<p>A task is represented by the <a href="http://mynewt.apache.org/os/core_os/task/task/#data-structures"><em>os_task</em></a> struct which will hold the task\u2019s information (name, state, priority, etc.). A task is made up of two main elements, a task function (also known as a task handler) and a task stack.</p>
+<p>A task is represented by the <a href="http://mynewt.apache.org/os/core_os/task/task/#data-structures"><em>os_task</em></a><br />
+struct which will hold the task\u2019s information (name, state, priority, etc.). A task is made up of two
+main elements, a task function (also known as a task handler) and a task stack.</p>
<p>Next, let\u2019s take a look at what is required to initialize our new task.</p>
<h3 id="task-stack">Task Stack</h3>
-<p>The task stack is an array of type <code>os_stack_t</code> which holds the program stack frames. Mynewt gives us the ability to set the stack size for a task giving the application developer room to optimize memory usage. Since we\u2019re not short on memory, our <code>blinky_stack</code> and <code>work_stack</code> are plenty large for the purpose of this lesson. Notice that the elements in our task stack are of type <code>os_stack_t</code> which are generally 32 bits, making our entire stack 1024 Bytes.</p>
+<p>The task stack is an array of type <code>os_stack_t</code> which holds the program stack frames. Mynewt gives
+us the ability to set the stack size for a task giving the application developer room to optimize
+memory usage. Since we\u2019re not short on memory, our <code>blinky_stack</code> and <code>work_stack</code> are plenty large
+for the purpose of this lesson. Notice that the elements in our task stack are of type <code>os_stack_t</code>
+which are generally 32 bits, making our entire stack 1024 Bytes.</p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"> <span style="color: #633820">#define WORK_STACK_SIZE OS_STACK_ALIGN(256)</span>
<span style="color: #A90D91">os_stack_t</span> <span style="color: #000000">work_stack</span>[<span style="color: #000000">WORK_STACK_SIZE</span>];
</pre></div>
@@ -471,7 +488,10 @@
<p>Note: The <code>OS_STACK_ALIGN</code> macro is used to align the stack based on the hardware architecture.</p>
<h3 id="task-function">Task Function</h3>
-<p>The task function is essentially an infinite loop which waits for some \u201cevent\u201d to wake it up. In our Blinky app the task function, named <code>blinky_task_handler()</code>, is initially called when we call <code>os_start()</code> in <code>main()</code>. In general, the task function is where the majority of work is done by a task. Let\u2019s write a task function for <code>work_task</code> called <code>work_task_handler()</code>:</p>
+<p>The task function is essentially an infinite loop which waits for some \u201cevent\u201d to wake it up. In our
+Blinky app the task function, named <code>blinky_task_handler()</code>, is initially called when we call <code>os_start()</code>
+in <code>main()</code>. In general, the task function is where the majority of work is done by a task. Let\u2019s write
+a task function for <code>work_task</code> called <code>work_task_handler()</code>:</p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">void</span>
<span style="color: #000000">work_task_handler</span>(<span style="color: #A90D91">void</span> <span style="color: #000000">*arg</span>)
{
@@ -489,16 +509,23 @@
</pre></div>
-<p>The task function is called when the task is initially put into the <em>running</em> state by the scheduler. We use an infinite loop to ensure that the task function never returns. Our assertion that the current task's handler is the same as our task handler is for illustration purposes only and does not need to be in most task functions.</p>
+<p>The task function is called when the task is initially put into the <em>running</em> state by the scheduler.
+We use an infinite loop to ensure that the task function never returns. Our assertion that the current
+task's handler is the same as our task handler is for illustration purposes only and does not need to
+be in most task functions.</p>
<h3 id="task-priority">Task Priority</h3>
-<p>As a preemptive, multitasking RTOS, Mynewt decides which tasks to run based on which has a higher priority; the highest priority being 0 and the lowest 255. Thus, before initializing our task, we must choose a priority defined as a macro variable.</p>
+<p>As a preemptive, multitasking RTOS, Mynewt decides which tasks to run based on which has a higher
+priority; the highest priority being 0 and the lowest 255. Thus, before initializing our task, we
+must choose a priority defined as a macro variable.</p>
<p>Let\u2019s set the priority of <code>work_task</code> to 0, because everyone knows that work is more important than blinking.</p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"> <span style="color: #633820">#define WORK_TASK_PRIO (0)</span>
</pre></div>
<h3 id="initialization">Initialization</h3>
-<p>To initialize a new task we use <a href="http://mynewt.apache.org/os/core_os/task/os_task_init/"><em>os_task_init()</em></a> which takes a number of arguments including our new task function, stack, and priority. Much like <code>blinky_task</code>, we\u2019re going to initialize <code>work_task</code> inside <code>init_tasks</code> to keep our main function clean.</p>
+<p>To initialize a new task we use <a href="http://mynewt.apache.org/os/core_os/task/os_task_init/"><em>os_task_init()</em></a>
+which takes a number of arguments including our new task function, stack, and priority. Much like <code>blinky_task</code>,
+we\u2019re going to initialize <code>work_task</code> inside <code>init_tasks</code> to keep our main function clean.</p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">int</span>
<span style="color: #000000">init_tasks</span>(<span style="color: #A90D91">void</span>)
{
@@ -551,8 +578,15 @@
<h2 id="task-priority-preempting-and-context-switching">Task Priority, Preempting, and Context Switching</h2>
-<p>A preemptive RTOS is one in which a higher priority task that is <em>ready to run</em> will preempt (i.e. take the place of) the lower priority task which is <em>running</em>. When a lower priority task is preempted by a higher priority task, the lower priority task\u2019s context data (stack pointer, registers, etc.) is saved and the new task is switched in.</p>
-<p>In our example, <code>work_task</code> has a higher priority than <code>blinky_task</code> and, because it is never put into a <em>sleep</em> state, holds the processor focus on its context. Let\u2019s give <code>work_task</code> a delay and some simulated work to keep it busy. Because the delay is measured in os ticks, the actual number of ticks per second is dependent on the board. Therefore, we multiply <code>OS_TICKS_PER_SEC</code>, which is defined in the MCU, by the number of seconds we wish to delay.</p>
+<p>A preemptive RTOS is one in which a higher priority task that is <em>ready to run</em> will preempt (i.e. take the
+place of) the lower priority task which is <em>running</em>. When a lower priority task is preempted by a higher
+priority task, the lower priority task\u2019s context data (stack pointer, registers, etc.) is saved and the new
+task is switched in.</p>
+<p>In our example, <code>work_task</code> has a higher priority than <code>blinky_task</code> and, because it is never put into a
+<em>sleep</em> state, holds the processor focus on its context. Let\u2019s give <code>work_task</code> a delay and some simulated
+work to keep it busy. Because the delay is measured in os ticks, the actual number of ticks per second is
+dependent on the board. Therefore, we multiply <code>OS_TICKS_PER_SEC</code>, which is defined in the MCU, by the
+number of seconds we wish to delay.</p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">void</span>
<span style="color: #000000">work_task_handler</span>(<span style="color: #A90D91">void</span> <span style="color: #000000">*arg</span>)
{
@@ -581,17 +615,28 @@
</pre></div>
-<p>Before we run the app, let\u2019s predict the behavior. With the newest additions to <code>work_task_handler()</code>, our first action will be to sleep for three seconds. This will allow <code>blinky_task</code> to take over the CPU and blink to its heart\u2019s content. After three seconds, <code>work_task</code> will wake up and be made <em>ready to run</em>, causing it to preempt <code>blinky_task</code>. The LED will then remain lit for a short period while <code>work_task</code> loops, then blink again for another three seconds while <code>work_task</code> sleeps. </p>
+<p>Before we run the app, let\u2019s predict the behavior. With the newest additions to <code>work_task_handler()</code>,
+our first action will be to sleep for three seconds. This will allow <code>blinky_task</code> to take over the CPU
+and blink to its heart\u2019s content. After three seconds, <code>work_task</code> will wake up and be made <em>ready to run</em>,
+causing it to preempt <code>blinky_task</code>. The LED will then remain lit for a short period while <code>work_task</code>
+loops, then blink again for another three seconds while <code>work_task</code> sleeps. </p>
<p>Voila, you should see that our prediction was correct! </p>
<h3 id="priority-management-considerations">Priority Management Considerations</h3>
-<p>When projects grow in scope, from blinking LEDs into more sophisticated applications, the number of tasks needed increases alongside complexity. It remains important, then, that each of our tasks is capable of doing its work within a reasonable amount of time.</p>
-<p>Some tasks, such as the Shell task, execute quickly and require almost instantaneous response. Therefore, the Shell task should be given a high priority. On the other hand, tasks which may be communicating over a network, or processing data, should be given a low priority in order to not hog the CPU.</p>
-<p>The diagram below showcases the different scheduling patterns we. would expect from swapping blinky and work tasks priorities.</p>
+<p>When projects grow in scope, from blinking LEDs into more sophisticated applications, the number of
+tasks needed increases alongside complexity. It remains important, then, that each of our tasks is
+capable of doing its work within a reasonable amount of time.</p>
+<p>Some tasks, such as the Shell task, execute quickly and require almost instantaneous response. Therefore,
+the Shell task should be given a high priority. On the other hand, tasks which may be communicating over
+a network, or processing data, should be given a low priority in order to not hog the CPU.</p>
+<p>The diagram below showcases the different scheduling patterns we. would expect from swapping blinky and
+work tasks priorities.</p>
<p><img alt="Task Scheduling" src="../pics/task_lesson.png" /></p>
-<p>In the second case where <code>blinky_task</code> has a higher priority, the \u201cwork\u201d done by <code>work_task</code> would be executed during the millisecond delays in <code>blinky_task</code>, saving us idle time compared to the first case.</p>
+<p>In the second case where <code>blinky_task</code> has a higher priority, the \u201cwork\u201d done by <code>work_task</code> would be
+executed during the millisecond delays in <code>blinky_task</code>, saving us idle time compared to the first case.</p>
<p><strong>Note:</strong> Defining the same priority for two tasks leads to somewhat undefined behavior and should be avoided.</p>
<h2 id="comparing-priority-strategies">Comparing Priority Strategies</h2>
-<p>Instead of stepping through a bunch of changes to our blinky app, clone my task lesson application from github and copy an existing target.</p>
+<p>Instead of stepping through a bunch of changes to our blinky app, clone my task lesson application from
+github and copy an existing target.</p>
<p>Change directory into apps and clone the repository to get our new
files:</p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%">$ cd apps
@@ -609,28 +654,38 @@ $ git clone https://github.com/bgiori/mynewt_tasks_lesson.git
</pre></div>
-<p>Now let\u2019s take a look at our new code. First, notice that we have abandoned blinking, instead choosing to use the <a href="http://mynewt.apache.org/latest/os/modules/console/console/"><em>console</em></a> and <a href="http://mynewt.apache.org/latest/os/modules/shell/shell/"><em>shell</em></a> to follow our tasks through execution.</p>
+<p>Now let\u2019s take a look at our new code. First, notice that we have abandoned blinking, instead choosing t
+o use the <a href="http://mynewt.apache.org/latest/os/modules/console/console/"><em>console</em></a> and <a href="http://mynewt.apache.org/latest/os/modules/shell/shell/"><em>shell</em></a>
+to follow our tasks through execution.</p>
<p>Additionally, we have a number of different tasks:</p>
<ul>
<li>
<p><strong>Task A</strong> (<code>a_task</code>):</p>
<ul>
<li><strong>Priority</strong>: 3 \u2192 2</li>
-<li><strong>Description</strong>: Task A is supposed to represent a task which frequently does a small amount of work, such as one which rapidly polls a sensor for data. Much like <code>blinky_task</code>, Task A will loop 10,000 times then wait 1 millisecond. Priority is changed by <code>timer_task</code> after the first simulation.</li>
+<li><strong>Description</strong>: Task A is supposed to represent a task which frequently does a small amount
+of work, such as one which rapidly polls a sensor for data. Much like <code>blinky_task</code>, Task A will
+loop 10,000 times then wait 1 millisecond. Priority is changed by <code>timer_task</code> after the first simulation.</li>
</ul>
</li>
<li>
<p><strong>Task B</strong> (<code>b_task</code>):</p>
<ul>
<li><strong>Priority</strong>: 2 \u2192 3</li>
-<li><strong>Description</strong>: Task B is supposed to represent a task which does a large amount of work relatively infrequently, such as one which sends/receives data from the cloud. Like work_task, Task B will loop 1,000,000 times then wait 3 seconds. Priority is changed by timer_task after the first simulation.</li>
+<li><strong>Description</strong>: Task B is supposed to represent a task which does a large amount of work
+relatively infrequently, such as one which sends/receives data from the cloud. Like work_task,
+Task B will loop 1,000,000 times then wait 3 seconds. Priority is changed by timer_task after
+the first simulation.</li>
</ul>
</li>
<li>
<p><strong>Timer Task</strong> (<code>timer_task</code>):</p>
<ul>
<li><strong>Priority</strong>: 1</li>
-<li><strong>Description</strong>: With default settings, Timer Task will wait 20 seconds then print the first simulations data for Task A and B. Timer task will then swap A and B\u2019s priorities and restart the simulation. After the second simulation, timer will again print simulation data then compare the two and calculate a final speedup (simulation2 / simulation1).</li>
+<li><strong>Description</strong>: With default settings, Timer Task will wait 20 seconds then print the first
+simulations data for Task A and B. Timer task will then swap A and B\u2019s priorities and restart the
+simulation. After the second simulation, timer will again print simulation data then compare the
+two and calculate a final speedup (simulation2 / simulation1).</li>
</ul>
</li>
<li>
@@ -642,7 +697,9 @@ $ git clone https://github.com/bgiori/mynewt_tasks_lesson.git
</li>
</ul>
<h3 id="connecting-to-the-serial-console">Connecting to the Serial Console</h3>
-<p>Before running our new app, we must first connect to the serial console. First make sure the mynewt_arduino_zero repository is set to the develop branch. (Remove once changes have been moved to master). </p>
+<p>Before running our new app, we must first connect to the serial console. First make sure the
+mynewt_arduino_zero repository is set to the develop branch. (Remove once changes have been
+moved to master). </p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%">$ cd repos/mynewt_arduino_zero
$ git checkout develop
</pre></div>
@@ -655,7 +712,8 @@ $ git checkout develop
</pre></div>
-<p>In the same window, connect to the serial port using a serial communication program. In this case I\u2019ll be using mincom as it can scroll through output.</p>
+<p>In the same window, connect to the serial port using a serial communication program.
+In this case I\u2019ll be using mincom as it can scroll through output.</p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #000000">$</span> <span style="color: #000000">minicom</span> <span style="color: #000000">-D</span> <span style="color: #000000">/dev/tty</span>.<span style="color: #000000">usbmodem14132</span> <span style="color: #000000">-b</span> <span style="color: #1C01CE">115200</span>
</pre></div>
@@ -726,16 +784,49 @@ $ git checkout develop
</pre></div>
-<p>The console output reaffirms our previous prediction and makes both the scheduling differences and subsequent efficiency boost far more apparent. Let\u2019s take a look at scheduling differences before we delve into efficiency.</p>
-<p>In the first case, where Task B\u2019s priority is higher than that of Task A, we see A get starved by Task B\u2019s long execution time. <strong>Starvation</strong> occurs when one task hogs the processor, essentially \u201cstarving\u201d other tasks which also need to run. At the end of the first 20 second simulation period, Task A has only run for 1.4 seconds compared to task B\u2019s 17 second running time \u2013 ouch. As explained before, processes which are expected to run for long periods of time (e.g. network communication, data processing) should be given higher priorities in order to combat starvation.</p>
-<p>In the second simulation with priorities swapped, we can see Task B only running during the millisecond delays when Task A is <em>sleeping</em>. Although having Task B only run during these delays slows its execution time, we benefit from un-starving Task A and using the processor at a higher efficiency.</p>
-<p>The bottom line speedup gives us an immediate and clear indication that we have improved our ability to process work (i.e throughput). In our second run, we processed an additional 400,000 loop iterations, equating to a 26% increase in efficiency. On a standard multi-core processor found in every modern PC, a 1.26 speedup would be an ok result to adding multithreading capabilities to a serial program. However, we accomplished this by simply setting priorities on a single core processor \u2013 not bad!</p>
-<p>NOTE: Usually the the term \u201cspeedup\u201d is used within a parallel programming context and refers to the change in execution time between a serial and parallel program executing over the same problem. In this case we\u2019re using the term loosely to illustrate the priority change\u2019s effect on scheduling and throughput in our specific context.</p>
+<p>The console output reaffirms our previous prediction and makes both the scheduling differences
+and subsequent efficiency boost far more apparent. Let\u2019s take a look at scheduling differences
+before we delve into efficiency.</p>
+<p>In the first case, where Task B\u2019s priority is higher than that of Task A, we see A get starved
+by Task B\u2019s long execution time. <strong>Starvation</strong> occurs when one task hogs the processor, essentially
+\u201cstarving\u201d other tasks which also need to run. At the end of the first 20 second simulation period,
+Task A has only run for 1.4 seconds compared to task B\u2019s 17 second running time \u2013 ouch. As explained
+before, processes which are expected to run for long periods of time (e.g. network communication,
+data processing) should be given higher priorities in order to combat starvation.</p>
+<p>In the second simulation with priorities swapped, we can see Task B only running during the
+millisecond delays when Task A is <em>sleeping</em>. Although having Task B only run during these
+delays slows its execution time, we benefit from un-starving Task A and using the processor
+at a higher efficiency.</p>
+<p>The bottom line speedup gives us an immediate and clear indication that we have improved our
+ability to process work (i.e throughput). In our second run, we processed an additional 400,000
+loop iterations, equating to a 26% increase in efficiency. On a standard multi-core processor
+found in every modern PC, a 1.26 speedup would be an ok result to adding multithreading capabilities
+to a serial program. However, we accomplished this by simply setting priorities on a single core
+processor \u2013 not bad!</p>
+<p>NOTE: Usually the the term \u201cspeedup\u201d is used within a parallel programming context and refers
+to the change in execution time between a serial and parallel program executing over the same
+problem. In this case we\u2019re using the term loosely to illustrate the priority change\u2019s effect
+on scheduling and throughput in our specific context.</p>
<h3 id="efficiency-isnt-everything">Efficiency Isn\u2019t Everything</h3>
-<p>Using the processor during every OS tick isn\u2019t always the best course of action. If we modify Task A\u2019s delay to a tenth of a millisecond and turn off the console output, we can boost our speedup to 1.44. This, however, reduces our ability to process work from Task B who ends up only completing 18% of its work cycle after the second simulation. That would mean, at that rate, Task B would take over a minute to finish one cycle.</p>
+<p>Using the processor during every OS tick isn\u2019t always the best course of action. If we modify
+Task A\u2019s delay to a tenth of a millisecond and turn off the console output, we can boost our
+speedup to 1.44. This, however, reduces our ability to process work from Task B who ends up
+only completing 18% of its work cycle after the second simulation. That would mean, at that
+rate, Task B would take over a minute to finish one cycle.</p>
<p>Feel free to play around with the testing parameters to study the different changes yourself!</p>
<h2 id="conclusion">Conclusion</h2>
-<p>Moving forward, tasks are just the tip of the iceberg. The <a href="http://mynewt.apache.org/latest/os/core_os/context_switch/context_switch/"><em>scheduler</em></a>, <a href="http://mynewt.apache.org/latest/os/core_os/event_queue/event_queue/"><em>event queues</em></a>, <a href="http://mynewt.apache.org/latest/os/core_os/semaphore/semaphore/"><em>semaphores</em></a>, and <a href="http://mynewt.apache.org/latest/os/core_os/mutex/mutex/"><em>mutexes</em></a> also add to tasks functionality, increasing our ability as the developer to control greater numbers of tasks more intricately. For example, when we switch the tasks priority, we have to tell the scheduler that our tasks priorities have changed, allowing us us to use priorities dynamically. When running multiple tasks, logging through either the built-in <a href="http://mynewt.apache.org/latest/os/modules/logs/logs/"><em>Logs</em></a> module (not covered in this lesson) or through the serial console/shell can be very useful for
debugging your application. In the end, the way you manage your tasks depends on the context of your application. You should assign priorities based on execution time, urgency, and frequency, among other things.</p>
+<p>Moving forward, tasks are just the tip of the iceberg. The <a href="http://mynewt.apache.org/latest/os/core_os/context_switch/context_switch/"><em>scheduler</em></a>,
+<a href="http://mynewt.apache.org/latest/os/core_os/event_queue/event_queue/"><em>event queues</em></a>,
+<a href="http://mynewt.apache.org/latest/os/core_os/semaphore/semaphore/"><em>semaphores</em></a>, and
+<a href="http://mynewt.apache.org/latest/os/core_os/mutex/mutex/"><em>mutexes</em></a> also add to tasks functionality,
+increasing our ability as the developer to control greater numbers of tasks more intricately. For
+example, when we switch the tasks priority, we have to tell the scheduler that our tasks priorities
+have changed, allowing us us to use priorities dynamically. When running multiple tasks, logging
+through either the built-in <a href="http://mynewt.apache.org/latest/os/modules/logs/logs/"><em>Logs</em></a> module
+(not covered in this lesson) or through the serial console/shell can be very useful for debugging
+your application. In the end, the way you manage your tasks depends on the context of your
+application. You should assign priorities based on execution time, urgency, and frequency, among
+other things.</p>
<p>Keep blinking and happy hacking!</p>
<div class="row">
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/develop/os/tutorials/wi-fi_on_arduino/index.html
----------------------------------------------------------------------
diff --git a/develop/os/tutorials/wi-fi_on_arduino/index.html b/develop/os/tutorials/wi-fi_on_arduino/index.html
index f853b1f..1b939f0 100644
--- a/develop/os/tutorials/wi-fi_on_arduino/index.html
+++ b/develop/os/tutorials/wi-fi_on_arduino/index.html
@@ -450,7 +450,7 @@
<ul>
<li>An Arduino Zero, Zero Pro or M0 Pro.<br />
<strong>Note:</strong> Mynewt has not been tested on Arduino M0 which has no internal debugger support.</li>
-<li>An Arduino Wi-Fi Shield 101</li>
+<li>An <a href="https://www.adafruit.com/product/2891">Arduino Wi-Fi Shield 101</a></li>
<li>A computer that can connect to the Arduino board over USB</li>
<li>A local Wi-Fi network that the computer is connected to and which the Arduino board can join.</li>
<li>A USB cable (Type A to micro B) that can connect the computer to the Arduino (or a USB hub between the computer and the Arduino board)</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/develop/sitemap.xml
----------------------------------------------------------------------
diff --git a/develop/sitemap.xml b/develop/sitemap.xml
index 6436c47..e834093 100644
--- a/develop/sitemap.xml
+++ b/develop/sitemap.xml
@@ -4,7 +4,7 @@
<url>
<loc>http://mynewt.apache.org/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -13,13 +13,13 @@
<url>
<loc>http://mynewt.apache.org/pages/ble/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>http://mynewt.apache.org/pages/securitybullets/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -28,7 +28,7 @@
<url>
<loc>http://mynewt.apache.org/quick-start/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -36,7 +36,7 @@
<url>
<loc>http://mynewt.apache.org/about/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -44,7 +44,7 @@
<url>
<loc>http://mynewt.apache.org/talks/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -52,7 +52,7 @@
<url>
<loc>http://mynewt.apache.org/download/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -60,7 +60,7 @@
<url>
<loc>http://mynewt.apache.org/community/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -68,7 +68,7 @@
<url>
<loc>http://mynewt.apache.org/events/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -77,7 +77,7 @@
<url>
<loc>http://mynewt.apache.org/os/introduction/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -89,7 +89,7 @@
<url>
<loc>http://mynewt.apache.org/os/get_started/vocabulary/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -129,13 +129,13 @@
<url>
<loc>http://mynewt.apache.org/faq/how_to_edit_docs/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>http://mynewt.apache.org/faq/answers/</loc>
- <lastmod>2016-11-15</lastmod>
+ <lastmod>2016-11-17</lastmod>
<changefreq>daily</changefreq>
</url>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/events/index.html
----------------------------------------------------------------------
diff --git a/events/index.html b/events/index.html
index d00e22a..ebe24d1 100644
--- a/events/index.html
+++ b/events/index.html
@@ -144,17 +144,17 @@
<div class="event">
- <h2>Linaro Connect - Keynote Presentation</h2>
- <p>Time: 16:10 - 16:45, Date: 26 September 2016, 2016</p>
- <p>Grand Ballroom C, JW Marriott Resort and Spa Hotel, Las Vegas, NV</p>
- <p>LAS16-104: Mynewt Technical Overview. Apache Mynewt developers will be available until September 28th to meet and discuss Mynewt OS and associated Newt tool.</p>
+ <h2>CES</h2>
+ <p>5-8 January, 2017</p>
+ <p>Las Vegas, NV</p>
+ <p>Contact runtime.io or email us at dev@mynewt.incubator.apache.org to check out and discuss Apache Mynewt and its many uses.</p>
</div>
<div class="event">
- <h2>ARM TechCon</h2>
- <p>25-27 October, 2016</p>
- <p>Santa Clara Convention Center, Santa Clara, CA, USA</p>
- <p>See Apache Mynewt in action in Booth #805. Watch it enable a variety of functionalities on different boards!</p>
+ <h2>Embedded Systems Conference</h2>
+ <p>6-8 December, 2016</p>
+ <p>San Jose Convention Center, San Jose, CA, USA</p>
+ <p>Meet up to discuss Apache Mynewt.</p>
</div>
</div>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/latest/events/index.html
----------------------------------------------------------------------
diff --git a/latest/events/index.html b/latest/events/index.html
index 97aa3d0..ae2da31 100644
--- a/latest/events/index.html
+++ b/latest/events/index.html
@@ -144,17 +144,17 @@
<div class="event">
- <h2>Linaro Connect - Keynote Presentation</h2>
- <p>Time: 16:10 - 16:45, Date: 26 September 2016, 2016</p>
- <p>Grand Ballroom C, JW Marriott Resort and Spa Hotel, Las Vegas, NV</p>
- <p>LAS16-104: Mynewt Technical Overview. Apache Mynewt developers will be available until September 28th to meet and discuss Mynewt OS and associated Newt tool.</p>
+ <h2>CES</h2>
+ <p>5-8 January, 2017</p>
+ <p>Las Vegas, NV</p>
+ <p>Contact runtime.io or email us at dev@mynewt.incubator.apache.org to check out and discuss Apache Mynewt and its many uses.</p>
</div>
<div class="event">
- <h2>ARM TechCon</h2>
- <p>25-27 October, 2016</p>
- <p>Santa Clara Convention Center, Santa Clara, CA, USA</p>
- <p>See Apache Mynewt in action in Booth #805. Watch it enable a variety of functionalities on different boards!</p>
+ <h2>Embedded Systems Conference</h2>
+ <p>6-8 December, 2016</p>
+ <p>San Jose Convention Center, San Jose, CA, USA</p>
+ <p>Meet up to discuss Apache Mynewt.</p>
</div>
</div>
[5/7] incubator-mynewt-site git commit: Updated events. Updated event
queue documentation. This closes #126
Posted by ad...@apache.org.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/develop/os/core_os/event_queue/event_queue/index.html
----------------------------------------------------------------------
diff --git a/develop/os/core_os/event_queue/event_queue/index.html b/develop/os/core_os/event_queue/event_queue/index.html
index 8302e06..8a6b3f2 100644
--- a/develop/os/core_os/event_queue/event_queue/index.html
+++ b/develop/os/core_os/event_queue/event_queue/index.html
@@ -306,7 +306,7 @@
<li><a href="
- ../os_eventq_get/
+ ../os_eventq_init/
">Functions</a>
@@ -661,21 +661,25 @@
</div>
<h1 id="event-queues">Event Queues</h1>
-<p>Event queue is a way of serializing events arring to a task. This makes it easy to queue processing to happen inside task's context. This would be done either from an interrupt handler, or from another task.</p>
-<p>Events arrive in a form of a data structure <code>struct os_event</code>.</p>
+<p>Event queue is a way for a task to serialize events sent to it. This makes it easy to process events required to happen inside the task's context. Events may arrive either from an interrupt handler, or from another task.</p>
<h3 id="description">Description</h3>
-<p>Events are in form of a data structure <code>struct os_event</code>, and they are queued to data structure <code>struct os_eventq</code>.</p>
-<p>Queue must be initialized before trying to add events to it. This is done using <code>os_eventq_init()</code>.</p>
-<p>Common way of using event queues is to have a task loop while calling <code>os_eventq_get()</code>, waiting for work to do.
-Other tasks (or interrupts) then call <code>os_eventq_put()</code> to wake it up. Once event has been queued task waiting on that queue is woken up, and will get a pointer to queued event structure.
-Processing task would then act according to event type.</p>
+<p>Events arrive in form the of a data structure <code>struct os_event</code> and
+they are queued to another data structure <code>struct os_eventq</code>.</p>
+<p>The Event Queue must be initialized before trying to add events to
+it. This is done using <code>os_eventq_init()</code>.</p>
+<p>A common way of using event queues is to have a task loop while calling <code>os_eventq_get()</code>,
+waiting for work to do. Other tasks (or interrupts) then call <code>os_eventq_put()</code>
+to wake it up. Once an event has been queued, the task waiting on that queue is woken up. The event dispatching logic is built into each event via a callback function pointer. The task handler can simply pull events
+off the queue and call its callback handler. The processing task would then act according to the event type. </p>
<p>When <code>os_event</code> is queued, it should not be freed until processing task is done with it.</p>
<p>It is assumed that there is only one task consuming events from an event queue. Only one task should be sleeping on a particular <code>os_eventq</code> at a time.</p>
<p>Note that <a href="../../callout/callout/">os_callout</a> subsystem assumes that event queue is used as the wakeup mechanism.</p>
<h3 id="data-structures">Data structures</h3>
-<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">struct</span> <span style="color: #000000">os_event</span> {
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">typedef</span> <span style="color: #A90D91">void</span> <span style="color: #000000">os_event_fn</span>(<span style="color: #A90D91">struct</span> <span style="color: #000000">os_event</span> <span style="color: #000000">*ev</span>);
+
+<span style="color: #A90D91">struct</span> <span style="color: #000000">os_event</span> {
<span style="color: #A90D91">uint8_t</span> <span style="color: #000000">ev_queued</span>;
- <span style="color: #A90D91">uint8_t</span> <span style="color: #000000">ev_type</span>;
+ <span style="color: #000000">os_event_fn</span> <span style="color: #000000">*ev_cb</span>;
<span style="color: #A90D91">void</span> <span style="color: #000000">*ev_arg</span>;
<span style="color: #000000">STAILQ_ENTRY</span>(<span style="color: #000000">os_event</span>) <span style="color: #000000">ev_next</span>;
};
@@ -691,23 +695,56 @@ Processing task would then act according to event type.</p>
</thead>
<tbody>
<tr>
-<td>ev_queued</td>
+<td><code>ev_queued</code></td>
<td>Internal field, which tells whether event is linked into an <em>os_eventq</em> already</td>
</tr>
<tr>
-<td>ev_type</td>
-<td>Type of an event. This should be unique, as it should be used by processing task to figure out what the event means</td>
+<td><code>ev_cb</code></td>
+<td>A callback function pointer that is called when a new event arrives on the queue</td>
</tr>
<tr>
-<td>ev_arg</td>
+<td><code>ev_arg</code></td>
<td>Can be used further as input to task processing this event</td>
</tr>
<tr>
-<td>ev_next</td>
+<td><code>ev_next</code></td>
<td>Linkage attaching this event to an event queue</td>
</tr>
</tbody>
</table>
+<p>With the callback function pointer, the dispatch logic gets built into each event. The task handler simply pulls an event off its queue and blindly calls its callback function. A helper function was added to do just this:
+<code>os_eventq_run()</code>. As an example, the task handler for the bleprph application is below:</p>
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">static</span> <span style="color: #A90D91">void</span>
+<span style="color: #000000">bleprph_task_handler</span>(<span style="color: #A90D91">void</span> <span style="color: #000000">*unused</span>)
+{
+ <span style="color: #A90D91">while</span> (<span style="color: #1C01CE">1</span>) {
+ <span style="color: #000000">os_eventq_run</span>(<span style="color: #000000">&bleprph_evq</span>);
+ }
+}
+</pre></div>
+
+
+<p>The callback associated with an event is specified when the event gets
+initialized. For example, here are some statically-initialized events
+in the NimBLE host:</p>
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">static</span> <span style="color: #A90D91">void</span> <span style="color: #000000">ble_hs_event_tx_notify</span>(<span style="color: #A90D91">struct</span> <span style="color: #000000">os_event</span> <span style="color: #000000">*ev</span>);
+<span style="color: #A90D91">static</span> <span style="color: #A90D91">void</span> <span style="color: #000000">ble_hs_event_reset</span>(<span style="color: #A90D91">struct</span> <span style="color: #000000">os_event</span> <span style="color: #000000">*ev</span>);
+
+<span style="color: #177500">/** OS event - triggers tx of pending notifications and indications. */</span>
+<span style="color: #A90D91">static</span> <span style="color: #A90D91">struct</span> <span style="color: #000000">os_event</span> <span style="color: #000000">ble_hs_ev_tx_notifications</span> <span style="color: #000000">=</span> {
+ .<span style="color: #000000">ev_cb</span> <span style="color: #000000">=</span> <span style="color: #000000">ble_hs_event_tx_notify</span>,
+};
+
+<span style="color: #177500">/** OS event - triggers a full reset. */</span>
+<span style="color: #A90D91">static</span> <span style="color: #A90D91">struct</span> <span style="color: #000000">os_event</span> <span style="color: #000000">ble_hs_ev_reset</span> <span style="color: #000000">=</span> {
+ .<span style="color: #000000">ev_cb</span> <span style="color: #000000">=</span> <span style="color: #000000">ble_hs_event_reset</span>,
+};
+</pre></div>
+
+
+<p>The callback function receives a single parameter: a
+pointer to the event being processed. If the event is allocated
+dynamically, the callback function should free the event. </p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">struct</span> <span style="color: #000000">os_eventq</span> {
<span style="color: #A90D91">struct</span> <span style="color: #000000">os_task</span> <span style="color: #000000">*evq_task</span>;
<span style="color: #000000">STAILQ_HEAD</span>(, <span style="color: #000000">os_event</span>) <span style="color: #000000">evq_list</span>;
@@ -724,11 +761,11 @@ Processing task would then act according to event type.</p>
</thead>
<tbody>
<tr>
-<td>evq_task</td>
+<td><code>evq_task</code></td>
<td>Pointer to task if there is task sleeping on <em>os_eventq_get()</em></td>
</tr>
<tr>
-<td>evq_list</td>
+<td><code>evq_list</code></td>
<td>Queue head for list of events in this queue</td>
</tr>
</tbody>
@@ -744,21 +781,33 @@ Processing task would then act according to event type.</p>
</thead>
<tbody>
<tr>
-<td><a href="../os_eventq_get/">os_eventq_get</a></td>
-<td>Fetches the first event from a queue. Task will sleep until something gets queued.</td>
+<td><a href="../os_eventq_init/"><code>os_eventq_init</code></a></td>
+<td>Initializes the given event queue, making it ready for use.</td>
</tr>
<tr>
-<td><a href="../os_eventq_init/">os_eventq_init</a></td>
-<td>Initializes the given event queue, making it ready for use.</td>
+<td><a href="../os_eventq_inited/"><code>os_eventq_inited</code></a></td>
+<td>Has the event queue been initialized.</td>
+</tr>
+<tr>
+<td><a href="../os_eventq_get/"><code>os_eventq_get</code></a></td>
+<td>Fetches the first event from a queue. Task will sleep until something gets queued.</td>
</tr>
<tr>
-<td><a href="../os_eventq_put/">os_eventq_put</a></td>
+<td><a href="../os_eventq_put/"><code>os_eventq_put</code></a></td>
<td>Queues an event to tail of the event queue.</td>
</tr>
<tr>
-<td><a href="../os_eventq_remove/">os_eventq_remove</a></td>
+<td><a href="../os_eventq_remove/"><code>os_eventq_remove</code></a></td>
<td>Removes an event which has been placed in a queue.</td>
</tr>
+<tr>
+<td><a href="../os_eventq_dflt_set/"><code>os_eventq_dflt_set</code></a></td>
+<td>Set the default event queue.</td>
+</tr>
+<tr>
+<td><a href="../os_eventq_dflt_get/"><code>os_eventq_dflt_get</code></a></td>
+<td>Get the default event queue.</td>
+</tr>
</tbody>
</table>
@@ -778,8 +827,8 @@ Processing task would then act according to event type.</p>
</li>
<li class="pull-right">
- <a href=../os_eventq_get/>
- Next: os_eventq_get
+ <a href=../os_eventq_init/>
+ Next: os_eventq_init
<span class="fa fa-arrow-right"></span>
</a>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/develop/os/core_os/event_queue/os_eventq_dflt_get/index.html
----------------------------------------------------------------------
diff --git a/develop/os/core_os/event_queue/os_eventq_dflt_get/index.html b/develop/os/core_os/event_queue/os_eventq_dflt_get/index.html
new file mode 100644
index 0000000..c8c574e
--- /dev/null
+++ b/develop/os/core_os/event_queue/os_eventq_dflt_get/index.html
@@ -0,0 +1,807 @@
+<!DOCTYPE html>
+<html lang="en">
+ <head>
+ <meta charset="utf-8">
+ <meta http-equiv="X-UA-Compatible" content="IE=edge">
+ <meta name="viewport" content="width=device-width, initial-scale=1.0">
+
+
+ <!-- This is broken by doc revisioning.
+ <link rel="canonical" href="http://mynewt.apache.org/os/core_os/event_queue/os_eventq_dflt_get/"> -->
+ <link rel="shortcut icon" href="../../../../img/favicon.ico">
+
+ <title>os_eventq_dflt_get - Apache Mynewt</title>
+
+ <link href="../../../../css/bootstrap-3.0.3.min.css" rel="stylesheet">
+ <link rel="stylesheet" href="../../../../css/highlight.css">
+ <link href="../../../../css/base.css" rel="stylesheet">
+ <link href="../../../../css/custom.css" rel="stylesheet">
+ <link href="../../../../css/v2.css" rel="stylesheet">
+ <link href="https://fonts.googleapis.com/css?family=Lato" rel="stylesheet">
+ <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css">
+ <link href="../../../../extra.css" rel="stylesheet">
+
+ <!-- HTML5 shim and Respond.js IE8 support of HTML5 elements and media queries -->
+ <!--[if lt IE 9]>
+ <script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
+ <script src="https://oss.maxcdn.com/libs/respond.js/1.3.0/respond.min.js"></script>
+ <![endif]-->
+
+
+ <script>
+ (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+ m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+ })(window,document,'script','//www.google-analytics.com/analytics.js','ga');
+
+ ga('create', 'UA-72162311-1', 'auto');
+ ga('send', 'pageview');
+ </script>
+
+ </head>
+
+
+ <body class="os_eventq_dflt_get">
+
+
+ <div class="container">
+ <div class="row v2-main-banner">
+ <div class="col-xs-12 v2-vcenter">
+ <a href="/"><img class="logo" src="/img/logo.png"></a>
+
+ <h4 class="tagline">An OS to build, deploy and securely manage billions of devices</h4>
+ </div>
+ </div>
+</div>
+
+
+
+
+
+
+
+
+<nav id="navbar" class="navbar navbar-inverse affix-top" data-spy="affix" data-offset-top="150" role="navigation">
+ <div class="container">
+ <!-- Collapsed navigation -->
+ <div class="navbar-header">
+ <!-- Expander button -->
+ <button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse">
+ <span class="sr-only">Toggle navigation</span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ </button>
+
+ </div>
+
+ <!-- Expanded navigation -->
+ <div class="navbar-collapse collapse">
+ <!-- Main navigation -->
+ <ul class="nav navbar-nav navbar-right">
+ <li
+ class=""
+>
+ <a href="/"><i class="fa fa-home" style="font-size: larger;"></i></a>
+ </li>
+ <li
+ class="important"
+>
+ <a href="/quick-start/">Quick Start</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/about/">About</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/talks/">Talks</a>
+ </li>
+ <li
+ class="active"
+>
+ <a href="/latest/os/introduction">Documentation</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/download/">Download</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/community/">Community</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/events/">Events</a>
+ </li>
+ </ul>
+
+ <!-- Search, Navigation and Repo links -->
+ <ul class="nav navbar-nav navbar-right">
+
+ </ul>
+ </div>
+ </div>
+</nav>
+
+
+
+ <div class="container">
+
+ <div class="row">
+ <div class="col-md-3 v2-sidebar sidebar-container"><div id="docSidebar" class="hidden-print" role="complementary">
+ <div class="top">
+ <div role="search">
+ <form id="rtd-search-form" class="wy-form" action="../../../../search.html" method="get">
+ <div class="form-group">
+ <input type="text" name="q" class="form-control" placeholder="Search documentation" />
+ </div>
+ </form>
+ </div>
+ </div>
+ <ul class="toc-nav">
+ <li class="doc-version">
+<select class="form-control" onchange="if (this.value) window.location.href=this.value">
+
+ <option
+ value="/develop/os/introduction"
+ selected="selected"
+ >
+ Version: develop (latest)
+ </option>
+
+ <option
+ value="/v0_9_0/os/introduction"
+
+ >
+ Version: 0.9.0
+ </option>
+
+</select>
+</li>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ <li ><a href="../../../introduction/">Mynewt Documentation</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li ><a href="../../../get_started/get_started/">Basic Setup</a>
+
+
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../../../get_started/vocabulary/">Concepts</a>
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../tutorials/tutorials/">Tutorials</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../os_user_guide/">OS User Guide</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li ><a href="../../mynewt_os/">OS Core</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li><a href="
+ ../../os_init/
+">System-level Functions</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../context_switch/context_switch/">Scheduler</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../time/os_time/">Time</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../task/task/">Tasks</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../event_queue/">Event Queues</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li><a href="
+ ../os_eventq_init/
+">Functions</a>
+
+
+ <ul>
+
+
+
+ <li >
+ <a href="../os_eventq_init/">os_eventq_init</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_inited/">os_eventq_inited</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_get/">os_eventq_get</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_put/">os_eventq_put</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_remove/">os_eventq_remove</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_dflt_set/">os_eventq_dflt_set</a>
+ </li>
+
+
+
+
+
+ <li class="active">
+ <a href="./">os_eventq_dflt_get</a>
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../semaphore/semaphore/">Semaphores</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../mutex/mutex/">Mutexes</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../memory_pool/memory_pool/">Memory Pools</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../heap/heap/">Heap</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+
+
+ ../../mbuf/mbuf/
+
+">Memory Buffers</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../sanity/sanity/">Sanity</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../callout/callout/">Callouts</a>
+
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../porting/port_os/">Porting to your Platform</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/console/console/">Console</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/shell/shell/">Shell</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/split/split/">Split Images</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/bootloader/bootloader/">Bootloader</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+
+
+ ../../../modules/fs/fs/fs/
+
+">File System</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/hal/hal/">Hardware Abstraction Layer</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/testutil/testutil/">Test Utilities</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/imgmgr/imgmgr/">Image Manager</a>
+
+
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../../../modules/baselibc/">Baselibc library</a>
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/elua/elua/">Embedded Lua</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/json/json/">JSON</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/fcb/fcb/">Flash Circular Buffer</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/stats/stats/">Stats</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/logs/logs/">Logs</a>
+
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+ ../../../../network/ble/ble_intro/
+">BLE User Guide</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../../newt/newt_intro/">Newt Tool Guide</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../../newtmgr/overview/">Newt Manager Guide</a>
+
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+ ../../../../faq/how_to_edit_docs/
+">Appendix</a>
+
+
+ </li>
+
+
+
+ </ul>
+</div></div>
+
+ <div class="col-md-9" role="main">
+ <div class="doc-header">
+ <div role="navigation" aria-label="breadcrumbs navigation">
+ <ul class="wy-breadcrumbs pull-right">
+ <li><a href="/develop/os/introduction">Docs</a></li>
+
+
+
+ <li>» <a href="../event_queue/">Event Queues</a></li>
+
+
+
+ <li>» <a href="../os_eventq_init/">Functions</a></li>
+
+
+
+ <li>» os_eventq_dflt_get</li>
+
+
+
+ </ul>
+</div>
+ </div>
+
+ <h2 id="os_eventq_dflt_get"><font color="F2853F" style="font-size:24pt"> os_eventq_dflt_get</font></h2>
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"> <span style="color: #A90D91">struct</span> <span style="color: #000000">os_eventq</span>
+ <span style="color: #000000">*os_eventq_dflt_get</span>(<span style="color: #A90D91">void</span>)
+</pre></div>
+
+
+<p>Get the default event queue that was set</p>
+<h4 id="arguments">Arguments</h4>
+<p>None</p>
+<h4 id="returned-values">Returned values</h4>
+<p><code>struct os_eventq *</code> A pointer to the default event queue, if set. </p>
+<h4 id="notes">Notes</h4>
+<p>None</p>
+<h4 id="example">Example</h4>
+<p><Add text to set up the context for the example here>
+This checks the default event queue and sets it if not already set.</p>
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">struct</span> <span style="color: #000000">os_eventq</span> <span style="color: #000000">g_my_evq</span>;
+
+<span style="color: #A90D91">int</span>
+<span style="color: #000000">event_q_check</span>()
+{
+ <span style="color: #A90D91">if</span>(<span style="color: #000000">os_eventq_dflt_get</span>() <span style="color: #000000">==</span> <span style="color: #A90D91">NULL</span>)
+ {
+ <span style="color: #000000">os_eventq_dflt_set</span>(<span style="color: #000000">g_my_evq</span>);
+ }
+
+}
+</pre></div>
+
+ <div class="row">
+
+
+
+
+<ul class="nav nav-pills" style="margin-bottom: 10px">
+ <li>
+
+ <a href=../os_eventq_dflt_set/>
+ <span class="fa fa-arrow-left"></span>
+ Previous: os_eventq_dflt_set
+ </a>
+
+ </li>
+ <li class="pull-right">
+
+ <a href=../../semaphore/semaphore/>
+ Next: Semaphores
+ <span class="fa fa-arrow-right"></span>
+ </a>
+
+ </li>
+</ul>
+ </div>
+ <footer class="row">
+ <div class="col-xs-12">
+
+ <p class="copyright">Copyright © 2015 The Apache Software Foundation, Licensed under the Apache License, Version 2.0 Apache and the Apache feather logo are trademarks of The Apache Software Foundation.</p>
+
+ </div>
+ <div class="col-xs-12">
+ <div class="logos">
+ <img src="/img/asf_logo_wide_small.png" alt="Apache" title="Apache">
+ <small class="footnote">
+ MyNewt is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the Apache Incubator. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+ </small>
+ <img src="/img/egg-logo2.png" alt="Apache Incubator" title="Apache Incubator">
+ </div>
+ </div>
+</footer>
+ </div>
+ </div>
+
+
+ </div>
+
+ <script src="../../../../js/jquery-1.10.2.min.js"></script>
+ <script src="../../../../js/bootstrap-3.0.3.min.js"></script>
+ <script src="../../../../js/highlight.pack.js"></script>
+ <script src="../../../../js/base.js"></script>
+ <script src="../../../../js/custom.js"></script>
+
+ </body>
+</html>
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/develop/os/core_os/event_queue/os_eventq_dflt_set/index.html
----------------------------------------------------------------------
diff --git a/develop/os/core_os/event_queue/os_eventq_dflt_set/index.html b/develop/os/core_os/event_queue/os_eventq_dflt_set/index.html
new file mode 100644
index 0000000..54e026b
--- /dev/null
+++ b/develop/os/core_os/event_queue/os_eventq_dflt_set/index.html
@@ -0,0 +1,821 @@
+<!DOCTYPE html>
+<html lang="en">
+ <head>
+ <meta charset="utf-8">
+ <meta http-equiv="X-UA-Compatible" content="IE=edge">
+ <meta name="viewport" content="width=device-width, initial-scale=1.0">
+
+
+ <!-- This is broken by doc revisioning.
+ <link rel="canonical" href="http://mynewt.apache.org/os/core_os/event_queue/os_eventq_dflt_set/"> -->
+ <link rel="shortcut icon" href="../../../../img/favicon.ico">
+
+ <title>os_eventq_dflt_set - Apache Mynewt</title>
+
+ <link href="../../../../css/bootstrap-3.0.3.min.css" rel="stylesheet">
+ <link rel="stylesheet" href="../../../../css/highlight.css">
+ <link href="../../../../css/base.css" rel="stylesheet">
+ <link href="../../../../css/custom.css" rel="stylesheet">
+ <link href="../../../../css/v2.css" rel="stylesheet">
+ <link href="https://fonts.googleapis.com/css?family=Lato" rel="stylesheet">
+ <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css">
+ <link href="../../../../extra.css" rel="stylesheet">
+
+ <!-- HTML5 shim and Respond.js IE8 support of HTML5 elements and media queries -->
+ <!--[if lt IE 9]>
+ <script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
+ <script src="https://oss.maxcdn.com/libs/respond.js/1.3.0/respond.min.js"></script>
+ <![endif]-->
+
+
+ <script>
+ (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+ m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+ })(window,document,'script','//www.google-analytics.com/analytics.js','ga');
+
+ ga('create', 'UA-72162311-1', 'auto');
+ ga('send', 'pageview');
+ </script>
+
+ </head>
+
+
+ <body class="os_eventq_dflt_set">
+
+
+ <div class="container">
+ <div class="row v2-main-banner">
+ <div class="col-xs-12 v2-vcenter">
+ <a href="/"><img class="logo" src="/img/logo.png"></a>
+
+ <h4 class="tagline">An OS to build, deploy and securely manage billions of devices</h4>
+ </div>
+ </div>
+</div>
+
+
+
+
+
+
+
+
+<nav id="navbar" class="navbar navbar-inverse affix-top" data-spy="affix" data-offset-top="150" role="navigation">
+ <div class="container">
+ <!-- Collapsed navigation -->
+ <div class="navbar-header">
+ <!-- Expander button -->
+ <button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse">
+ <span class="sr-only">Toggle navigation</span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ </button>
+
+ </div>
+
+ <!-- Expanded navigation -->
+ <div class="navbar-collapse collapse">
+ <!-- Main navigation -->
+ <ul class="nav navbar-nav navbar-right">
+ <li
+ class=""
+>
+ <a href="/"><i class="fa fa-home" style="font-size: larger;"></i></a>
+ </li>
+ <li
+ class="important"
+>
+ <a href="/quick-start/">Quick Start</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/about/">About</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/talks/">Talks</a>
+ </li>
+ <li
+ class="active"
+>
+ <a href="/latest/os/introduction">Documentation</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/download/">Download</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/community/">Community</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/events/">Events</a>
+ </li>
+ </ul>
+
+ <!-- Search, Navigation and Repo links -->
+ <ul class="nav navbar-nav navbar-right">
+
+ </ul>
+ </div>
+ </div>
+</nav>
+
+
+
+ <div class="container">
+
+ <div class="row">
+ <div class="col-md-3 v2-sidebar sidebar-container"><div id="docSidebar" class="hidden-print" role="complementary">
+ <div class="top">
+ <div role="search">
+ <form id="rtd-search-form" class="wy-form" action="../../../../search.html" method="get">
+ <div class="form-group">
+ <input type="text" name="q" class="form-control" placeholder="Search documentation" />
+ </div>
+ </form>
+ </div>
+ </div>
+ <ul class="toc-nav">
+ <li class="doc-version">
+<select class="form-control" onchange="if (this.value) window.location.href=this.value">
+
+ <option
+ value="/develop/os/introduction"
+ selected="selected"
+ >
+ Version: develop (latest)
+ </option>
+
+ <option
+ value="/v0_9_0/os/introduction"
+
+ >
+ Version: 0.9.0
+ </option>
+
+</select>
+</li>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ <li ><a href="../../../introduction/">Mynewt Documentation</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li ><a href="../../../get_started/get_started/">Basic Setup</a>
+
+
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../../../get_started/vocabulary/">Concepts</a>
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../tutorials/tutorials/">Tutorials</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../os_user_guide/">OS User Guide</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li ><a href="../../mynewt_os/">OS Core</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li><a href="
+ ../../os_init/
+">System-level Functions</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../context_switch/context_switch/">Scheduler</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../time/os_time/">Time</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../task/task/">Tasks</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../event_queue/">Event Queues</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li><a href="
+ ../os_eventq_init/
+">Functions</a>
+
+
+ <ul>
+
+
+
+ <li >
+ <a href="../os_eventq_init/">os_eventq_init</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_inited/">os_eventq_inited</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_get/">os_eventq_get</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_put/">os_eventq_put</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_remove/">os_eventq_remove</a>
+ </li>
+
+
+
+
+
+ <li class="active">
+ <a href="./">os_eventq_dflt_set</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_dflt_get/">os_eventq_dflt_get</a>
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../semaphore/semaphore/">Semaphores</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../mutex/mutex/">Mutexes</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../memory_pool/memory_pool/">Memory Pools</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../heap/heap/">Heap</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+
+
+ ../../mbuf/mbuf/
+
+">Memory Buffers</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../sanity/sanity/">Sanity</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../callout/callout/">Callouts</a>
+
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../porting/port_os/">Porting to your Platform</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/console/console/">Console</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/shell/shell/">Shell</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/split/split/">Split Images</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/bootloader/bootloader/">Bootloader</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+
+
+ ../../../modules/fs/fs/fs/
+
+">File System</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/hal/hal/">Hardware Abstraction Layer</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/testutil/testutil/">Test Utilities</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/imgmgr/imgmgr/">Image Manager</a>
+
+
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../../../modules/baselibc/">Baselibc library</a>
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/elua/elua/">Embedded Lua</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/json/json/">JSON</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/fcb/fcb/">Flash Circular Buffer</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/stats/stats/">Stats</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/logs/logs/">Logs</a>
+
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+ ../../../../network/ble/ble_intro/
+">BLE User Guide</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../../newt/newt_intro/">Newt Tool Guide</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../../newtmgr/overview/">Newt Manager Guide</a>
+
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+ ../../../../faq/how_to_edit_docs/
+">Appendix</a>
+
+
+ </li>
+
+
+
+ </ul>
+</div></div>
+
+ <div class="col-md-9" role="main">
+ <div class="doc-header">
+ <div role="navigation" aria-label="breadcrumbs navigation">
+ <ul class="wy-breadcrumbs pull-right">
+ <li><a href="/develop/os/introduction">Docs</a></li>
+
+
+
+ <li>» <a href="../event_queue/">Event Queues</a></li>
+
+
+
+ <li>» <a href="../os_eventq_init/">Functions</a></li>
+
+
+
+ <li>» os_eventq_dflt_set</li>
+
+
+
+ </ul>
+</div>
+ </div>
+
+ <h2 id="os_eventq_dflt_set"><font color="F2853F" style="font-size:24pt"> os_eventq_dflt_set</font></h2>
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"> <span style="color: #A90D91">void</span>
+ <span style="color: #000000">os_eventq_dflt_set</span>(<span style="color: #A90D91">struct</span> <span style="color: #000000">os_eventq</span> <span style="color: #000000">*evq</span>)
+</pre></div>
+
+
+<p>Sets <code>struct os_eventq</code> as the default event queue</p>
+<h4 id="arguments">Arguments</h4>
+<table>
+<thead>
+<tr>
+<th>Arguments</th>
+<th>Description</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td><code>evq</code></td>
+<td>Pointer to default event queue to use</td>
+</tr>
+</tbody>
+</table>
+<h4 id="returned-values">Returned values</h4>
+<p>None</p>
+<h4 id="notes">Notes</h4>
+<p>Usually done at subsystem init time; before OS has been started, and before interrupts generating events have been enabled.</p>
+<h4 id="example">Example</h4>
+<p><Add text to set up the context for the example here>
+This sets the default event queue used by newtmgr task.</p>
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">struct</span> <span style="color: #000000">os_eventq</span> <span style="color: #000000">g_nmgr_evq</span>;
+
+<span style="color: #A90D91">int</span>
+<span style="color: #000000">nmgr_task_init</span>(<span style="color: #A90D91">uint8_t</span> <span style="color: #000000">prio</span>, <span style="color: #A90D91">os_stack_t</span> <span style="color: #000000">*stack_ptr</span>, <span style="color: #A90D91">uint16_t</span> <span style="color: #000000">stack_len</span>)
+{
+ <span style="color: #177500">/* variable declarations here */</span>
+
+ <span style="color: #000000">os_eventq_init</span>(<span style="color: #000000">&g_nmgr_evq</span>);
+ <span style="color: #000000">os_eventq_dflt_set</span>(<span style="color: #000000">&g_nmgr_evq</span>);
+
+ <span style="color: #177500">/* initialization continues here */</span>
+}
+</pre></div>
+
+ <div class="row">
+
+
+
+
+<ul class="nav nav-pills" style="margin-bottom: 10px">
+ <li>
+
+ <a href=../os_eventq_remove/>
+ <span class="fa fa-arrow-left"></span>
+ Previous: os_eventq_remove
+ </a>
+
+ </li>
+ <li class="pull-right">
+
+ <a href=../os_eventq_dflt_get/>
+ Next: os_eventq_dflt_get
+ <span class="fa fa-arrow-right"></span>
+ </a>
+
+ </li>
+</ul>
+ </div>
+ <footer class="row">
+ <div class="col-xs-12">
+
+ <p class="copyright">Copyright © 2015 The Apache Software Foundation, Licensed under the Apache License, Version 2.0 Apache and the Apache feather logo are trademarks of The Apache Software Foundation.</p>
+
+ </div>
+ <div class="col-xs-12">
+ <div class="logos">
+ <img src="/img/asf_logo_wide_small.png" alt="Apache" title="Apache">
+ <small class="footnote">
+ MyNewt is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the Apache Incubator. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+ </small>
+ <img src="/img/egg-logo2.png" alt="Apache Incubator" title="Apache Incubator">
+ </div>
+ </div>
+</footer>
+ </div>
+ </div>
+
+
+ </div>
+
+ <script src="../../../../js/jquery-1.10.2.min.js"></script>
+ <script src="../../../../js/bootstrap-3.0.3.min.js"></script>
+ <script src="../../../../js/highlight.pack.js"></script>
+ <script src="../../../../js/base.js"></script>
+ <script src="../../../../js/custom.js"></script>
+
+ </body>
+</html>
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/develop/os/core_os/event_queue/os_eventq_get/index.html
----------------------------------------------------------------------
diff --git a/develop/os/core_os/event_queue/os_eventq_get/index.html b/develop/os/core_os/event_queue/os_eventq_get/index.html
index ebc2feb..8e3e69c 100644
--- a/develop/os/core_os/event_queue/os_eventq_get/index.html
+++ b/develop/os/core_os/event_queue/os_eventq_get/index.html
@@ -306,7 +306,7 @@
<li><a href="
- ./
+ ../os_eventq_init/
">Functions</a>
@@ -314,8 +314,8 @@
- <li class="active">
- <a href="./">os_eventq_get</a>
+ <li >
+ <a href="../os_eventq_init/">os_eventq_init</a>
</li>
@@ -323,7 +323,15 @@
<li >
- <a href="../os_eventq_init/">os_eventq_init</a>
+ <a href="../os_eventq_inited/">os_eventq_inited</a>
+ </li>
+
+
+
+
+
+ <li class="active">
+ <a href="./">os_eventq_get</a>
</li>
@@ -344,6 +352,22 @@
+
+
+ <li >
+ <a href="../os_eventq_dflt_set/">os_eventq_dflt_set</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_dflt_get/">os_eventq_dflt_get</a>
+ </li>
+
+
+
</ul>
</li>
@@ -686,7 +710,7 @@
- <li>» Functions</li>
+ <li>» <a href="../os_eventq_init/">Functions</a></li>
@@ -742,16 +766,16 @@
<ul class="nav nav-pills" style="margin-bottom: 10px">
<li>
- <a href=../event_queue/>
+ <a href=../os_eventq_inited/>
<span class="fa fa-arrow-left"></span>
- Previous: Event Queues
+ Previous: os_eventq_inited
</a>
</li>
<li class="pull-right">
- <a href=../os_eventq_init/>
- Next: os_eventq_init
+ <a href=../os_eventq_put/>
+ Next: os_eventq_put
<span class="fa fa-arrow-right"></span>
</a>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/develop/os/core_os/event_queue/os_eventq_init/index.html
----------------------------------------------------------------------
diff --git a/develop/os/core_os/event_queue/os_eventq_init/index.html b/develop/os/core_os/event_queue/os_eventq_init/index.html
index fefebab..b66541d 100644
--- a/develop/os/core_os/event_queue/os_eventq_init/index.html
+++ b/develop/os/core_os/event_queue/os_eventq_init/index.html
@@ -306,7 +306,7 @@
<li><a href="
- ../os_eventq_get/
+ ./
">Functions</a>
@@ -314,16 +314,24 @@
+ <li class="active">
+ <a href="./">os_eventq_init</a>
+ </li>
+
+
+
+
+
<li >
- <a href="../os_eventq_get/">os_eventq_get</a>
+ <a href="../os_eventq_inited/">os_eventq_inited</a>
</li>
- <li class="active">
- <a href="./">os_eventq_init</a>
+ <li >
+ <a href="../os_eventq_get/">os_eventq_get</a>
</li>
@@ -344,6 +352,22 @@
+
+
+ <li >
+ <a href="../os_eventq_dflt_set/">os_eventq_dflt_set</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_dflt_get/">os_eventq_dflt_get</a>
+ </li>
+
+
+
</ul>
</li>
@@ -686,7 +710,7 @@
- <li>» <a href="../os_eventq_get/">Functions</a></li>
+ <li>» Functions</li>
@@ -748,16 +772,16 @@ This initializes event queue used by newtmgr task.</p>
<ul class="nav nav-pills" style="margin-bottom: 10px">
<li>
- <a href=../os_eventq_get/>
+ <a href=../event_queue/>
<span class="fa fa-arrow-left"></span>
- Previous: os_eventq_get
+ Previous: Event Queues
</a>
</li>
<li class="pull-right">
- <a href=../os_eventq_put/>
- Next: os_eventq_put
+ <a href=../os_eventq_inited/>
+ Next: os_eventq_inited
<span class="fa fa-arrow-right"></span>
</a>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/develop/os/core_os/event_queue/os_eventq_inited/index.html
----------------------------------------------------------------------
diff --git a/develop/os/core_os/event_queue/os_eventq_inited/index.html b/develop/os/core_os/event_queue/os_eventq_inited/index.html
new file mode 100644
index 0000000..237d975
--- /dev/null
+++ b/develop/os/core_os/event_queue/os_eventq_inited/index.html
@@ -0,0 +1,823 @@
+<!DOCTYPE html>
+<html lang="en">
+ <head>
+ <meta charset="utf-8">
+ <meta http-equiv="X-UA-Compatible" content="IE=edge">
+ <meta name="viewport" content="width=device-width, initial-scale=1.0">
+
+
+ <!-- This is broken by doc revisioning.
+ <link rel="canonical" href="http://mynewt.apache.org/os/core_os/event_queue/os_eventq_inited/"> -->
+ <link rel="shortcut icon" href="../../../../img/favicon.ico">
+
+ <title>os_eventq_inited - Apache Mynewt</title>
+
+ <link href="../../../../css/bootstrap-3.0.3.min.css" rel="stylesheet">
+ <link rel="stylesheet" href="../../../../css/highlight.css">
+ <link href="../../../../css/base.css" rel="stylesheet">
+ <link href="../../../../css/custom.css" rel="stylesheet">
+ <link href="../../../../css/v2.css" rel="stylesheet">
+ <link href="https://fonts.googleapis.com/css?family=Lato" rel="stylesheet">
+ <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css">
+ <link href="../../../../extra.css" rel="stylesheet">
+
+ <!-- HTML5 shim and Respond.js IE8 support of HTML5 elements and media queries -->
+ <!--[if lt IE 9]>
+ <script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
+ <script src="https://oss.maxcdn.com/libs/respond.js/1.3.0/respond.min.js"></script>
+ <![endif]-->
+
+
+ <script>
+ (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+ m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+ })(window,document,'script','//www.google-analytics.com/analytics.js','ga');
+
+ ga('create', 'UA-72162311-1', 'auto');
+ ga('send', 'pageview');
+ </script>
+
+ </head>
+
+
+ <body class="os_eventq_inited">
+
+
+ <div class="container">
+ <div class="row v2-main-banner">
+ <div class="col-xs-12 v2-vcenter">
+ <a href="/"><img class="logo" src="/img/logo.png"></a>
+
+ <h4 class="tagline">An OS to build, deploy and securely manage billions of devices</h4>
+ </div>
+ </div>
+</div>
+
+
+
+
+
+
+
+
+<nav id="navbar" class="navbar navbar-inverse affix-top" data-spy="affix" data-offset-top="150" role="navigation">
+ <div class="container">
+ <!-- Collapsed navigation -->
+ <div class="navbar-header">
+ <!-- Expander button -->
+ <button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse">
+ <span class="sr-only">Toggle navigation</span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ </button>
+
+ </div>
+
+ <!-- Expanded navigation -->
+ <div class="navbar-collapse collapse">
+ <!-- Main navigation -->
+ <ul class="nav navbar-nav navbar-right">
+ <li
+ class=""
+>
+ <a href="/"><i class="fa fa-home" style="font-size: larger;"></i></a>
+ </li>
+ <li
+ class="important"
+>
+ <a href="/quick-start/">Quick Start</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/about/">About</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/talks/">Talks</a>
+ </li>
+ <li
+ class="active"
+>
+ <a href="/latest/os/introduction">Documentation</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/download/">Download</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/community/">Community</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/events/">Events</a>
+ </li>
+ </ul>
+
+ <!-- Search, Navigation and Repo links -->
+ <ul class="nav navbar-nav navbar-right">
+
+ </ul>
+ </div>
+ </div>
+</nav>
+
+
+
+ <div class="container">
+
+ <div class="row">
+ <div class="col-md-3 v2-sidebar sidebar-container"><div id="docSidebar" class="hidden-print" role="complementary">
+ <div class="top">
+ <div role="search">
+ <form id="rtd-search-form" class="wy-form" action="../../../../search.html" method="get">
+ <div class="form-group">
+ <input type="text" name="q" class="form-control" placeholder="Search documentation" />
+ </div>
+ </form>
+ </div>
+ </div>
+ <ul class="toc-nav">
+ <li class="doc-version">
+<select class="form-control" onchange="if (this.value) window.location.href=this.value">
+
+ <option
+ value="/develop/os/introduction"
+ selected="selected"
+ >
+ Version: develop (latest)
+ </option>
+
+ <option
+ value="/v0_9_0/os/introduction"
+
+ >
+ Version: 0.9.0
+ </option>
+
+</select>
+</li>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ <li ><a href="../../../introduction/">Mynewt Documentation</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li ><a href="../../../get_started/get_started/">Basic Setup</a>
+
+
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../../../get_started/vocabulary/">Concepts</a>
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../tutorials/tutorials/">Tutorials</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../os_user_guide/">OS User Guide</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li ><a href="../../mynewt_os/">OS Core</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li><a href="
+ ../../os_init/
+">System-level Functions</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../context_switch/context_switch/">Scheduler</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../time/os_time/">Time</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../task/task/">Tasks</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../event_queue/">Event Queues</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li><a href="
+ ../os_eventq_init/
+">Functions</a>
+
+
+ <ul>
+
+
+
+ <li >
+ <a href="../os_eventq_init/">os_eventq_init</a>
+ </li>
+
+
+
+
+
+ <li class="active">
+ <a href="./">os_eventq_inited</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_get/">os_eventq_get</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_put/">os_eventq_put</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_remove/">os_eventq_remove</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_dflt_set/">os_eventq_dflt_set</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_dflt_get/">os_eventq_dflt_get</a>
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../semaphore/semaphore/">Semaphores</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../mutex/mutex/">Mutexes</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../memory_pool/memory_pool/">Memory Pools</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../heap/heap/">Heap</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+
+
+ ../../mbuf/mbuf/
+
+">Memory Buffers</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../sanity/sanity/">Sanity</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../callout/callout/">Callouts</a>
+
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../porting/port_os/">Porting to your Platform</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/console/console/">Console</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/shell/shell/">Shell</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/split/split/">Split Images</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/bootloader/bootloader/">Bootloader</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+
+
+ ../../../modules/fs/fs/fs/
+
+">File System</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/hal/hal/">Hardware Abstraction Layer</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/testutil/testutil/">Test Utilities</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/imgmgr/imgmgr/">Image Manager</a>
+
+
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../../../modules/baselibc/">Baselibc library</a>
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/elua/elua/">Embedded Lua</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/json/json/">JSON</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/fcb/fcb/">Flash Circular Buffer</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/stats/stats/">Stats</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/logs/logs/">Logs</a>
+
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+ ../../../../network/ble/ble_intro/
+">BLE User Guide</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../../newt/newt_intro/">Newt Tool Guide</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../../newtmgr/overview/">Newt Manager Guide</a>
+
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+ ../../../../faq/how_to_edit_docs/
+">Appendix</a>
+
+
+ </li>
+
+
+
+ </ul>
+</div></div>
+
+ <div class="col-md-9" role="main">
+ <div class="doc-header">
+ <div role="navigation" aria-label="breadcrumbs navigation">
+ <ul class="wy-breadcrumbs pull-right">
+ <li><a href="/develop/os/introduction">Docs</a></li>
+
+
+
+ <li>» <a href="../event_queue/">Event Queues</a></li>
+
+
+
+ <li>» <a href="../os_eventq_init/">Functions</a></li>
+
+
+
+ <li>» os_eventq_inited</li>
+
+
+
+ </ul>
+</div>
+ </div>
+
+ <h2 id="os_eventq_inited"><font color="F2853F" style="font-size:24pt"> os_eventq_inited</font></h2>
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"> <span style="color: #A90D91">int</span>
+ <span style="color: #000000">os_eventq_inited</span>(<span style="color: #A90D91">const</span> <span style="color: #A90D91">struct</span> <span style="color: #000000">os_eventq</span> <span style="color: #000000">*evq</span>)
+</pre></div>
+
+
+<p>Check if event queue <code>const struct os_eventq</code> is ready for use.</p>
+<h4 id="arguments">Arguments</h4>
+<table>
+<thead>
+<tr>
+<th>Arguments</th>
+<th>Description</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td><code>evq</code></td>
+<td>Pointer to event queue to check</td>
+</tr>
+</tbody>
+</table>
+<h4 id="returned-values">Returned values</h4>
+<p><code>0</code> if event queue is ready</p>
+<h4 id="notes">Notes</h4>
+<p>If an event queue was properly initialized (and the proper checks were done at initialization)
+this check is not needed prior to using an event queue.</p>
+<h4 id="example">Example</h4>
+<p><Add text to set up the context for the example here>
+This checks an event queue before using it.</p>
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">struct</span> <span style="color: #000000">os_eventq</span> <span style="color: #000000">g_my_evq</span>;
+
+<span style="color: #A90D91">int</span>
+<span style="color: #000000">my_task_init</span>(<span style="color: #A90D91">uint8_t</span> <span style="color: #000000">prio</span>, <span style="color: #A90D91">os_stack_t</span> <span style="color: #000000">*stack_ptr</span>, <span style="color: #A90D91">uint16_t</span> <span style="color: #000000">stack_len</span>)
+{
+ <span style="color: #177500">/* variable declarations here */</span>
+
+ <span style="color: #A90D91">if</span>(<span style="color: #000000">os_eventq_inited</span>(<span style="color: #000000">&g_my_evq</span>))
+ {
+ <span style="color: #177500">/* deal with the event queue */</span>
+ };
+
+}
+</pre></div>
+
+ <div class="row">
+
+
+
+
+<ul class="nav nav-pills" style="margin-bottom: 10px">
+ <li>
+
+ <a href=../os_eventq_init/>
+ <span class="fa fa-arrow-left"></span>
+ Previous: os_eventq_init
+ </a>
+
+ </li>
+ <li class="pull-right">
+
+ <a href=../os_eventq_get/>
+ Next: os_eventq_get
+ <span class="fa fa-arrow-right"></span>
+ </a>
+
+ </li>
+</ul>
+ </div>
+ <footer class="row">
+ <div class="col-xs-12">
+
+ <p class="copyright">Copyright © 2015 The Apache Software Foundation, Licensed under the Apache License, Version 2.0 Apache and the Apache feather logo are trademarks of The Apache Software Foundation.</p>
+
+ </div>
+ <div class="col-xs-12">
+ <div class="logos">
+ <img src="/img/asf_logo_wide_small.png" alt="Apache" title="Apache">
+ <small class="footnote">
+ MyNewt is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the Apache Incubator. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+ </small>
+ <img src="/img/egg-logo2.png" alt="Apache Incubator" title="Apache Incubator">
+ </div>
+ </div>
+</footer>
+ </div>
+ </div>
+
+
+ </div>
+
+ <script src="../../../../js/jquery-1.10.2.min.js"></script>
+ <script src="../../../../js/bootstrap-3.0.3.min.js"></script>
+ <script src="../../../../js/highlight.pack.js"></script>
+ <script src="../../../../js/base.js"></script>
+ <script src="../../../../js/custom.js"></script>
+
+ </body>
+</html>
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/develop/os/core_os/event_queue/os_eventq_put/index.html
----------------------------------------------------------------------
diff --git a/develop/os/core_os/event_queue/os_eventq_put/index.html b/develop/os/core_os/event_queue/os_eventq_put/index.html
index caba04d..3252b29 100644
--- a/develop/os/core_os/event_queue/os_eventq_put/index.html
+++ b/develop/os/core_os/event_queue/os_eventq_put/index.html
@@ -306,7 +306,7 @@
<li><a href="
- ../os_eventq_get/
+ ../os_eventq_init/
">Functions</a>
@@ -315,7 +315,7 @@
<li >
- <a href="../os_eventq_get/">os_eventq_get</a>
+ <a href="../os_eventq_init/">os_eventq_init</a>
</li>
@@ -323,7 +323,15 @@
<li >
- <a href="../os_eventq_init/">os_eventq_init</a>
+ <a href="../os_eventq_inited/">os_eventq_inited</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_get/">os_eventq_get</a>
</li>
@@ -344,6 +352,22 @@
+
+
+ <li >
+ <a href="../os_eventq_dflt_set/">os_eventq_dflt_set</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_dflt_get/">os_eventq_dflt_get</a>
+ </li>
+
+
+
</ul>
</li>
@@ -686,7 +710,7 @@
- <li>» <a href="../os_eventq_get/">Functions</a></li>
+ <li>» <a href="../os_eventq_init/">Functions</a></li>
@@ -752,9 +776,9 @@ This is used to pass info about an event to a task handling it.</p>
<ul class="nav nav-pills" style="margin-bottom: 10px">
<li>
- <a href=../os_eventq_init/>
+ <a href=../os_eventq_get/>
<span class="fa fa-arrow-left"></span>
- Previous: os_eventq_init
+ Previous: os_eventq_get
</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/develop/os/core_os/event_queue/os_eventq_remove/index.html
----------------------------------------------------------------------
diff --git a/develop/os/core_os/event_queue/os_eventq_remove/index.html b/develop/os/core_os/event_queue/os_eventq_remove/index.html
index 3d2f421..bb3cf4e 100644
--- a/develop/os/core_os/event_queue/os_eventq_remove/index.html
+++ b/develop/os/core_os/event_queue/os_eventq_remove/index.html
@@ -306,7 +306,7 @@
<li><a href="
- ../os_eventq_get/
+ ../os_eventq_init/
">Functions</a>
@@ -315,7 +315,7 @@
<li >
- <a href="../os_eventq_get/">os_eventq_get</a>
+ <a href="../os_eventq_init/">os_eventq_init</a>
</li>
@@ -323,7 +323,15 @@
<li >
- <a href="../os_eventq_init/">os_eventq_init</a>
+ <a href="../os_eventq_inited/">os_eventq_inited</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_get/">os_eventq_get</a>
</li>
@@ -344,6 +352,22 @@
+
+
+ <li >
+ <a href="../os_eventq_dflt_set/">os_eventq_dflt_set</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_dflt_get/">os_eventq_dflt_get</a>
+ </li>
+
+
+
</ul>
</li>
@@ -686,7 +710,7 @@
- <li>» <a href="../os_eventq_get/">Functions</a></li>
+ <li>» <a href="../os_eventq_init/">Functions</a></li>
@@ -751,8 +775,8 @@ This is from <code>os_callout_stop()</code>. User wants to stop a callout from g
</li>
<li class="pull-right">
- <a href=../../semaphore/semaphore/>
- Next: Semaphores
+ <a href=../os_eventq_dflt_set/>
+ Next: os_eventq_dflt_set
<span class="fa fa-arrow-right"></span>
</a>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/develop/os/core_os/semaphore/semaphore/index.html
----------------------------------------------------------------------
diff --git a/develop/os/core_os/semaphore/semaphore/index.html b/develop/os/core_os/semaphore/semaphore/index.html
index cd31e62..cd672b7 100644
--- a/develop/os/core_os/semaphore/semaphore/index.html
+++ b/develop/os/core_os/semaphore/semaphore/index.html
@@ -732,9 +732,9 @@
<ul class="nav nav-pills" style="margin-bottom: 10px">
<li>
- <a href=../../event_queue/os_eventq_remove/>
+ <a href=../../event_queue/os_eventq_dflt_get/>
<span class="fa fa-arrow-left"></span>
- Previous: os_eventq_remove
+ Previous: os_eventq_dflt_get
</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/develop/os/tutorials/repo/create_repo/index.html
----------------------------------------------------------------------
diff --git a/develop/os/tutorials/repo/create_repo/index.html b/develop/os/tutorials/repo/create_repo/index.html
index 15f679a..cbed4e4 100644
--- a/develop/os/tutorials/repo/create_repo/index.html
+++ b/develop/os/tutorials/repo/create_repo/index.html
@@ -503,7 +503,7 @@ repo.versions:
<p>It contains the following:</p>
<ul>
<li><strong>repo.name</strong> The external name that is used to include the library in
-your <code>project.yml</code> file. This is the name you in include in the <code>project.repositories</code>
+your <code>project.yml</code> file. This is the name you include in the <code>project.repositories</code>
variable when adding this repository to your project.</li>
<li><strong>repo.versions</strong> A description of what versions to give the user depending
on the settings in their <code>project.yml</code> file. See below for a thorough description
[6/7] incubator-mynewt-site git commit: Updated events. Updated event
queue documentation. This closes #126
Posted by ad...@apache.org.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/develop/mkdocs/search_index.json
----------------------------------------------------------------------
diff --git a/develop/mkdocs/search_index.json b/develop/mkdocs/search_index.json
index c1bb107..8cbfaeb 100644
--- a/develop/mkdocs/search_index.json
+++ b/develop/mkdocs/search_index.json
@@ -932,7 +932,7 @@
},
{
"location": "/os/tutorials/repo/create_repo/",
- "text": "Create a Repo out of a Project\n\n\nIn order to create a repository out of a project, all you need to do is create a \n\nrepository.yml\n file, and check it into the master branch of your project.\n\n\nNOTE:\n Currently only github source control service is supported by our \npackage management system, but support for plain git is planned for a future\nversion.\n\n\nThe \nrepository.yml\n defines all versions of the repository and the corresponding \nsource control tags that these versions correspond to. As an example, if the \n\nrepository.yml\n file has the following content, it means there is one version \nof the apache-mynewt-core operating system available, which is \n0.0.0\n (implying we \nhaven't released yet!). Such a version number corresponds to the \"develop\" branch \nin this repository. \n0-latest\n would also resolved to this same \n0.0.0\n version. \nThe next section explains the versioning system a bit more.\n\n\n$ more repository.yml\nrepo.name
: apache-mynewt-core\nrepo.versions:\n \n0.0.0\n: \ndevelop\n\n \n0-latest\n: \n0.0.0\n\n\n\n\n\n\n\n\nWhere should the repository.yml file be?\n\n\nThe \nrepository.yml\n file lives only in the master branch of the git\nrepository. \nNewt\n will always fetch this file from the master branch and then\nuse that to resolve the actual branch required depending on the version\nspecified in the project. \nSpecial care should be taken to ensure that this\nfile exists only in the master branch.\n\n\nHere is the \nrepository.yml\n file from a certain snapshot of apache-Mynewt-core:\n\n\nrepo.name: apache-mynewt-core\nrepo.versions:\n \n0.7.9\n: \nMynewt_0_8_0_b2_tag\n\n \n0-latest\n: \n0.7.9\n\n \n0.8-latest\n: \n0.7.9\n\n\n\n\n\n\n\n\nIt contains the following:\n\n\n\n\nrepo.name\n The external name that is used to include the library in \nyour \nproject.yml\n file. This is the name you in include in the \nproject.repositories\n \nvariable when adding this repository t
o your project.\n\n\nrepo.versions\n A description of what versions to give the user depending \non the settings in their \nproject.yml\n file. See below for a thorough description\non versioning. Its a flexible mapping between version numbers and git branches.\n\n\n\n\n\n\nRepo Version Specification\n\n\nThe version field argument for a repo has the following format:\n\n\nmajor_num\n.\nminor_num\n.\nrevision_num\n\n\n\n\n\n\nor\n\n\nmajor_num\n.\nminor_num\n-\nstability string\n\n\n\n\n\n\nor \n\n\nmajor_num\n-\nstability string\n\n\n\n\n\n\n\n\nThe stability string can be one of 3 pre-defined stability values.\n\n\n\n\nstable\n -- A stable release version of the repository\n\n\ndev\n -- A development version from the repository\n\n\nlatest\n -- The latest from the repository\n\n\n\n\nIn your \nproject.yml\n file you can specify different combinations of \nthe version number and stability value. For example:\n\n\n\n\n0-latest\n -- The latest version with major number 0\n\
n\n1.2-stable\n -- The latest stable version with major and minor number 1.2\n\n\n1.2-dev\n -- The development version from 1.2\n\n\n1.1.1\n -- a specific version 1.1.1\n\n\n\n\nYou \ncannot\n specify a stability string with a fully numbered version, e.g.\n\n\n1.2.8-stable\n\n\n\n\n\n\n\nRepo Version Resolution\n\n\nA \nrepository.yml\n file contains information to match this version request\ninto a git branch to fetch for your project.\n\n\nIt's up to you as the repository maintainer to map these to actual github branches \nof the repository. For example, let's say in a fictitious repository the \nfollowing are defined.\n\n\nrepo.versions:\n \n0.8.0\n: \nxxx_branch_0_8_0\n\n \n1.0.0\n: \nxxx_branch_1_0_0\n\n \n1.0.2\n: \nxxx_branch_1_0_2\n\n \n1.1.1\n: \nxxx_branch_1_1_0\n\n \n1.1.2\n: \nxxx_branch_1_1_2\n\n \n1.2.0\n: \nxxx_branch_1_2_0\n\n \n1.2.1\n: \nxxx_branch_1_2_1\n\n \n1.2-dev\n: \n1.2.1\n\n \n1-dev\n: \n1.2-dev\n\n \n1.2-stab
le\n: \n1.2.0\n\n \n0-latest\n: \n0.8.0\n\n \n1-latest\n: \n1-dev\n\n ....\n\n\n\n\n\nWhen the \nproject.yml\n file asks for \n1.2-stable\n it will be resolved to version\n\n1.2.0\n which in turn will resolve to a specific branch \nxxx_branch_1_2_0\n.\n\nThis is the branch that \nnewt\n will then fetch into the project with that \nproject.yml\n file.\n\n\n\n\nDependencies on other repos\n\n\nRepositories can also have dependencies on other repositories. These \ndependencies should be listed out on a per-tag basis. So, for example, \nif apache-mynewt-core were to depend on sterlys-little-repo, you might \nhave the following directives in the repository.yml:\n\n\ndevelop.repositories:\n sterlys-little-repo:\n type: github\n vers: 0.8-latest\n user: sterlinghughes\n repo: sterlys-little-repo\n\n\n\n\n\n\n\nThis would tell Newt that for anything that resolves to the develop \nbranch, this repository requires the sterlys-little-repo repository. \
n\n\nDependencies are resolved circularly by the newt tool, and every \ndependent repository is placed as a sibling in the repos directory. \nCurrently, if two repositories have the same name, they will conflict \nand bad things will happen.\n\n\nWhen a repository is installed to the repos/ directory, the current \nversion of that repository is written to the \nproject.state\n file. The \nproject state file contains the currently installed version of any given \nrepository. This way, the current set of repositories can be recreated \nfrom the \nproject.state\n file reliably, whereas the \nproject.yml\n file can \nhave higher level directives (i.e. include 0.8-stable.)\n\n\nResolving dependencies\n\n\nAt the moment, all dependencies must match, otherwise newt will provide \nan error. As an example, if you have a set of dependencies such that:\n\n\napache-mynewt-core depends on sterlys-little-repo 0.6-stable\napache-mynewt-core depends on sterlys-big-repo 0.5.1\nsterlys-big-repo-0.
5.1 depends on sterlys-little-repo 0.6.2\n\n\n\n\n\n\n\nwhere 0.6-stable is 0.6.3, the newt tool will try and resolve the dependency to \nsterlys-little-repo. It will notice that there are two conflicting \nversions of the same repository, and not perform installation.\n\n\nIn the future Newt will be smarter about loading in all dependencies, \nand then looking to satisfy those dependencies to the best match of all \npotential options.",
+ "text": "Create a Repo out of a Project\n\n\nIn order to create a repository out of a project, all you need to do is create a \n\nrepository.yml\n file, and check it into the master branch of your project.\n\n\nNOTE:\n Currently only github source control service is supported by our \npackage management system, but support for plain git is planned for a future\nversion.\n\n\nThe \nrepository.yml\n defines all versions of the repository and the corresponding \nsource control tags that these versions correspond to. As an example, if the \n\nrepository.yml\n file has the following content, it means there is one version \nof the apache-mynewt-core operating system available, which is \n0.0.0\n (implying we \nhaven't released yet!). Such a version number corresponds to the \"develop\" branch \nin this repository. \n0-latest\n would also resolved to this same \n0.0.0\n version. \nThe next section explains the versioning system a bit more.\n\n\n$ more repository.yml\nrepo.name
: apache-mynewt-core\nrepo.versions:\n \n0.0.0\n: \ndevelop\n\n \n0-latest\n: \n0.0.0\n\n\n\n\n\n\n\n\nWhere should the repository.yml file be?\n\n\nThe \nrepository.yml\n file lives only in the master branch of the git\nrepository. \nNewt\n will always fetch this file from the master branch and then\nuse that to resolve the actual branch required depending on the version\nspecified in the project. \nSpecial care should be taken to ensure that this\nfile exists only in the master branch.\n\n\nHere is the \nrepository.yml\n file from a certain snapshot of apache-Mynewt-core:\n\n\nrepo.name: apache-mynewt-core\nrepo.versions:\n \n0.7.9\n: \nMynewt_0_8_0_b2_tag\n\n \n0-latest\n: \n0.7.9\n\n \n0.8-latest\n: \n0.7.9\n\n\n\n\n\n\n\n\nIt contains the following:\n\n\n\n\nrepo.name\n The external name that is used to include the library in \nyour \nproject.yml\n file. This is the name you include in the \nproject.repositories\n \nvariable when adding this repository to y
our project.\n\n\nrepo.versions\n A description of what versions to give the user depending \non the settings in their \nproject.yml\n file. See below for a thorough description\non versioning. Its a flexible mapping between version numbers and git branches.\n\n\n\n\n\n\nRepo Version Specification\n\n\nThe version field argument for a repo has the following format:\n\n\nmajor_num\n.\nminor_num\n.\nrevision_num\n\n\n\n\n\n\nor\n\n\nmajor_num\n.\nminor_num\n-\nstability string\n\n\n\n\n\n\nor \n\n\nmajor_num\n-\nstability string\n\n\n\n\n\n\n\n\nThe stability string can be one of 3 pre-defined stability values.\n\n\n\n\nstable\n -- A stable release version of the repository\n\n\ndev\n -- A development version from the repository\n\n\nlatest\n -- The latest from the repository\n\n\n\n\nIn your \nproject.yml\n file you can specify different combinations of \nthe version number and stability value. For example:\n\n\n\n\n0-latest\n -- The latest version with major number 0\n\n\n
1.2-stable\n -- The latest stable version with major and minor number 1.2\n\n\n1.2-dev\n -- The development version from 1.2\n\n\n1.1.1\n -- a specific version 1.1.1\n\n\n\n\nYou \ncannot\n specify a stability string with a fully numbered version, e.g.\n\n\n1.2.8-stable\n\n\n\n\n\n\n\nRepo Version Resolution\n\n\nA \nrepository.yml\n file contains information to match this version request\ninto a git branch to fetch for your project.\n\n\nIt's up to you as the repository maintainer to map these to actual github branches \nof the repository. For example, let's say in a fictitious repository the \nfollowing are defined.\n\n\nrepo.versions:\n \n0.8.0\n: \nxxx_branch_0_8_0\n\n \n1.0.0\n: \nxxx_branch_1_0_0\n\n \n1.0.2\n: \nxxx_branch_1_0_2\n\n \n1.1.1\n: \nxxx_branch_1_1_0\n\n \n1.1.2\n: \nxxx_branch_1_1_2\n\n \n1.2.0\n: \nxxx_branch_1_2_0\n\n \n1.2.1\n: \nxxx_branch_1_2_1\n\n \n1.2-dev\n: \n1.2.1\n\n \n1-dev\n: \n1.2-dev\n\n \n1.2-stable\
n: \n1.2.0\n\n \n0-latest\n: \n0.8.0\n\n \n1-latest\n: \n1-dev\n\n ....\n\n\n\n\n\nWhen the \nproject.yml\n file asks for \n1.2-stable\n it will be resolved to version\n\n1.2.0\n which in turn will resolve to a specific branch \nxxx_branch_1_2_0\n.\n\nThis is the branch that \nnewt\n will then fetch into the project with that \nproject.yml\n file.\n\n\n\n\nDependencies on other repos\n\n\nRepositories can also have dependencies on other repositories. These \ndependencies should be listed out on a per-tag basis. So, for example, \nif apache-mynewt-core were to depend on sterlys-little-repo, you might \nhave the following directives in the repository.yml:\n\n\ndevelop.repositories:\n sterlys-little-repo:\n type: github\n vers: 0.8-latest\n user: sterlinghughes\n repo: sterlys-little-repo\n\n\n\n\n\n\n\nThis would tell Newt that for anything that resolves to the develop \nbranch, this repository requires the sterlys-little-repo repository. \n\n
\nDependencies are resolved circularly by the newt tool, and every \ndependent repository is placed as a sibling in the repos directory. \nCurrently, if two repositories have the same name, they will conflict \nand bad things will happen.\n\n\nWhen a repository is installed to the repos/ directory, the current \nversion of that repository is written to the \nproject.state\n file. The \nproject state file contains the currently installed version of any given \nrepository. This way, the current set of repositories can be recreated \nfrom the \nproject.state\n file reliably, whereas the \nproject.yml\n file can \nhave higher level directives (i.e. include 0.8-stable.)\n\n\nResolving dependencies\n\n\nAt the moment, all dependencies must match, otherwise newt will provide \nan error. As an example, if you have a set of dependencies such that:\n\n\napache-mynewt-core depends on sterlys-little-repo 0.6-stable\napache-mynewt-core depends on sterlys-big-repo 0.5.1\nsterlys-big-repo-0.5.1
depends on sterlys-little-repo 0.6.2\n\n\n\n\n\n\n\nwhere 0.6-stable is 0.6.3, the newt tool will try and resolve the dependency to \nsterlys-little-repo. It will notice that there are two conflicting \nversions of the same repository, and not perform installation.\n\n\nIn the future Newt will be smarter about loading in all dependencies, \nand then looking to satisfy those dependencies to the best match of all \npotential options.",
"title": "Turn project into a repo"
},
{
@@ -942,7 +942,7 @@
},
{
"location": "/os/tutorials/repo/create_repo/#where-should-the-repositoryyml-file-be",
- "text": "The repository.yml file lives only in the master branch of the git\nrepository. Newt will always fetch this file from the master branch and then\nuse that to resolve the actual branch required depending on the version\nspecified in the project. Special care should be taken to ensure that this\nfile exists only in the master branch. Here is the repository.yml file from a certain snapshot of apache-Mynewt-core: repo.name: apache-mynewt-core\nrepo.versions:\n 0.7.9 : Mynewt_0_8_0_b2_tag \n 0-latest : 0.7.9 \n 0.8-latest : 0.7.9 It contains the following: repo.name The external name that is used to include the library in \nyour project.yml file. This is the name you in include in the project.repositories \nvariable when adding this repository to your project. repo.versions A description of what versions to give the user depending \non the settings in their project.yml file. See below for a thorough description\non versionin
g. Its a flexible mapping between version numbers and git branches.",
+ "text": "The repository.yml file lives only in the master branch of the git\nrepository. Newt will always fetch this file from the master branch and then\nuse that to resolve the actual branch required depending on the version\nspecified in the project. Special care should be taken to ensure that this\nfile exists only in the master branch. Here is the repository.yml file from a certain snapshot of apache-Mynewt-core: repo.name: apache-mynewt-core\nrepo.versions:\n 0.7.9 : Mynewt_0_8_0_b2_tag \n 0-latest : 0.7.9 \n 0.8-latest : 0.7.9 It contains the following: repo.name The external name that is used to include the library in \nyour project.yml file. This is the name you include in the project.repositories \nvariable when adding this repository to your project. repo.versions A description of what versions to give the user depending \non the settings in their project.yml file. See below for a thorough description\non versioning.
Its a flexible mapping between version numbers and git branches.",
"title": "Where should the repository.yml file be?"
},
{
@@ -967,17 +967,17 @@
},
{
"location": "/os/tutorials/tasks_lesson/",
- "text": "Core OS Lesson: Tasks and Priority Management\n\n\nTarget Platform: Arduino M0 Pro\n (or legacy Arduino Zero or Zero Pro, but not Arduino M0)\n\n\nThis lesson is designed to teach core OS concepts and strategies encountered when building applications using Mynewt. Specifically, this lesson will cover tasks, simple multitasking, and priority management running on an Arduino M0 Pro.\n\n\nPrerequisites\n\n\nBefore starting, you should read about Mynewt in the \nIntroduction\n section and complete the \nQuickStart\n guide and the \nBlinky\n tutorial. Furthermore, it may be helpful to take a peek at the \ntask documentation\n for additional insights.\n\n\nEquipment\n\n\nYou will need the following equipment:\n\n\n\n\nArduino M0 Pro (or legacy Arduino Zero or Zero Pro, but not Arduino M0)\n\n\nComputer with Mynewt installed\n\n\nUSB to Micro USB Cable\n\n\n\n\nBuild Your Application\n\n\nTo save time, we will simply modify the Blinky app as it has the basic task struc
ture already implemented. Follow the \nArduino Zero Blinky tutorial\n to create a new project and build your bootloader and application. Finally, build and load the application to your Arduino to verify that everything is in order. Now let\u2019s get started!\n\n\nCreate a New Task\n\n\nThe purpose of this section is to give an introduction to the important aspects of tasks and how to properly initialize them. First, let\u2019s define a second task called \nwork_task\n in main.c (located in apps/blinky/src):\n\n\nstruct\n \nos_task\n \nwork_task\n;\n\n\n\n\n\nA task is represented by the \nos_task\n struct which will hold the task\u2019s information (name, state, priority, etc.). A task is made up of two main elements, a task function (also known as a task handler) and a task stack.\n\n\nNext, let\u2019s take a look at what is required to initialize our new task.\n\n\nTask Stack\n\n\nThe task stack is an array of type \nos_stack_t\n which holds the program stack frames. Mynewt give
s us the ability to set the stack size for a task giving the application developer room to optimize memory usage. Since we\u2019re not short on memory, our \nblinky_stack\n and \nwork_stack\n are plenty large for the purpose of this lesson. Notice that the elements in our task stack are of type \nos_stack_t\n which are generally 32 bits, making our entire stack 1024 Bytes.\n\n\n \n#define WORK_STACK_SIZE OS_STACK_ALIGN(256)\n\n \nos_stack_t\n \nwork_stack\n[\nWORK_STACK_SIZE\n];\n\n\n\n\n\nNote: The \nOS_STACK_ALIGN\n macro is used to align the stack based on the hardware architecture.\n\n\nTask Function\n\n\nThe task function is essentially an infinite loop which waits for some \u201cevent\u201d to wake it up. In our Blinky app the task function, named \nblinky_task_handler()\n, is initially called when we call \nos_start()\n in \nmain()\n. In general, the task function is where the majority of work is done by a task. Let\u2019s write a task function for \nwork_task\n called \nwo
rk_task_handler()\n:\n\n\nvoid\n\n\nwork_task_handler\n(\nvoid\n \n*arg\n)\n{\n \nstruct\n \nos_task\n \n*t\n;\n\n \ng_led_pin\n \n=\n \nLED_BLINK_PIN\n;\n \nhal_gpio_init_out\n(\ng_led_pin\n, \n1\n);\n\n \nwhile\n (\n1\n) {\n \nt\n \n=\n \nos_sched_get_current_task\n();\n \nassert\n(\nt-\nt_func\n \n==\n \nwork_task_handler\n);\n \n/* Do work... */\n\n }\n}\n\n\n\n\n\nThe task function is called when the task is initially put into the \nrunning\n state by the scheduler. We use an infinite loop to ensure that the task function never returns. Our assertion that the current task's handler is the same as our task handler is for illustration purposes only and does not need to be in most task functions.\n\n\nTask Priority\n\n\nAs a preemptive, multitasking RTOS, Mynewt decides which tasks to run based on which has a higher priority; the highest priority being 0 and the lowest 255. Thus, before initializing our task, we must choose a priority defined as
a macro variable.\n\n\nLet\u2019s set the priority of \nwork_task\n to 0, because everyone knows that work is more important than blinking.\n\n\n \n#define WORK_TASK_PRIO (0)\n\n\n\n\n\n\nInitialization\n\n\nTo initialize a new task we use \nos_task_init()\n which takes a number of arguments including our new task function, stack, and priority. Much like \nblinky_task\n, we\u2019re going to initialize \nwork_task\n inside \ninit_tasks\n to keep our main function clean.\n\n\nint\n\n\ninit_tasks\n(\nvoid\n)\n{\n \n/* \u2026 */\n\n \nos_task_init\n(\nwork_task\n, \nwork\n, \nwork_task_handler\n, \nNULL\n,\n \nWORK_TASK_PRIO\n, \nOS_WAIT_FOREVER\n, \nwork_stack\n,\n \nWORK_STACK_SIZE\n);\n\n \ntasks_initialized\n \n=\n \n1\n;\n \nreturn\n \n0\n;\n}\n\n\n\n\n\nAnd that\u2019s it! Now run your application using the newt run command.\n\n\n$ newt run arduino_blinky 0.0.0\n\n\n\n\n\nWhen GDB appears press C then Enter to continue and \u2026 \nwait, why doe
sn't our LED blink anymore?\n\n\nReview\n\n\nBefore we run our new app, let\u2019s review what we need in order to create a task. This is a general case for a new task called mytask:\n\n\n1)\n Define a new task, task stack, and priority:\n\n\n/* My Task */\n\n\nstruct\n \nos_task\n \nmytask\n\n\n/* My Task Stack */\n\n\n#define MYTASK_STACK_SIZE OS_STACK_ALIGN(256)\n\n\nos_stack_t\n \nmytask_stack\n[\nMYTASK_STACK_SIZE\n];\n\n/* My Task Priority */\n\n\n#define MYTASK_PRIO (0)\n\n\n\n\n\n\n2)\n Define task function:\n\n\nvoid\n \n\nmytask_handler\n(\nvoid\n \n*arg\n)\n{\n \nwhile\n (\n1\n) {\n \n/* ... */\n\n }\n}\n\n\n\n\n\n3)\n Initialize task before calling \nos_start()\n:\n\n\nos_task_init\n(\nmytask\n, \nmytask\n, \nmytask_handler\n, \nNULL\n, \n \nMYTASK_PRIO\n, \nOS_WAIT_FOREVER\n, \nmytask_stack\n,\n \nMYTASK_STACK_SIZE\n);\n\n\n\n\n\nTask Priority, Preempting, and Context Switching\n\n\nA preemptive RTOS is one in which a higher priority task
that is \nready to run\n will preempt (i.e. take the place of) the lower priority task which is \nrunning\n. When a lower priority task is preempted by a higher priority task, the lower priority task\u2019s context data (stack pointer, registers, etc.) is saved and the new task is switched in.\n\n\nIn our example, \nwork_task\n has a higher priority than \nblinky_task\n and, because it is never put into a \nsleep\n state, holds the processor focus on its context. Let\u2019s give \nwork_task\n a delay and some simulated work to keep it busy. Because the delay is measured in os ticks, the actual number of ticks per second is dependent on the board. Therefore, we multiply \nOS_TICKS_PER_SEC\n, which is defined in the MCU, by the number of seconds we wish to delay.\n\n\nvoid\n\n\nwork_task_handler\n(\nvoid\n \n*arg\n)\n{\n \nstruct\n \nos_task\n \n*t\n;\n\n \ng_led_pin\n \n=\n \nLED_BLINK_PIN\n;\n \nhal_gpio_init_out\n(\ng_led_pin\n, \n1\n);\n\n \nwhile\n (\n1\n) {\n
\nt\n \n=\n \nos_sched_get_current_t\n:ask\n();\n \nassert\n(\nt-\nt_func\n \n==\n \nwork_task_handler\n);\n \n/* Do work... */\n\n \nint\n \ni\n;\n \nfor\n(\ni\n \n=\n \n0\n; \ni\n \n \n1000000\n; \n++i\n) {\n \n/* Simulate doing a noticeable amount of work */\n\n \nhal_gpio_set\n(\ng_led_pin\n);\n }\n \nos_time_delay\n(\n3\n*OS_TICKS_PER_SECOND\n);\n }\n}\n\n\n\n\n\nIn order to notice the LED changing, modify the time delay in \nblinky_task_handler()\n to blink at a higher frequency.\n\n\nos_time_delay\n(\nOS_TICKS_PER_SEC/\n10\n);\n\n\n\n\n\nBefore we run the app, let\u2019s predict the behavior. With the newest additions to \nwork_task_handler()\n, our first action will be to sleep for three seconds. This will allow \nblinky_task\n to take over the CPU and blink to its heart\u2019s content. After three seconds, \nwork_task\n will wake up and be made \nready to run\n, causing it to preempt \nblinky_task\n. The LED
will then remain lit for a short period while \nwork_task\n loops, then blink again for another three seconds while \nwork_task\n sleeps. \n\n\nVoila, you should see that our prediction was correct! \n\n\nPriority Management Considerations\n\n\nWhen projects grow in scope, from blinking LEDs into more sophisticated applications, the number of tasks needed increases alongside complexity. It remains important, then, that each of our tasks is capable of doing its work within a reasonable amount of time.\n\n\nSome tasks, such as the Shell task, execute quickly and require almost instantaneous response. Therefore, the Shell task should be given a high priority. On the other hand, tasks which may be communicating over a network, or processing data, should be given a low priority in order to not hog the CPU.\n\n\nThe diagram below showcases the different scheduling patterns we. would expect from swapping blinky and work tasks priorities.\n\n\n\n\nIn the second case where \nblinky_task\n h
as a higher priority, the \u201cwork\u201d done by \nwork_task\n would be executed during the millisecond delays in \nblinky_task\n, saving us idle time compared to the first case.\n\n\nNote:\n Defining the same priority for two tasks leads to somewhat undefined behavior and should be avoided.\n\n\nComparing Priority Strategies\n\n\nInstead of stepping through a bunch of changes to our blinky app, clone my task lesson application from github and copy an existing target.\n\n\nChange directory into apps and clone the repository to get our new\nfiles:\n\n\n$ cd apps\n$ git clone https://github.com/bgiori/mynewt_tasks_lesson.git\n\n\n\n\n\nChange directory back to your project root and copy the arduino_blinky target to a new target called task_tgt.\n\n\n$\n \nnewt\n \ntarget\n \ncopy\n \narduino_blinky\n \ntask_tgt\n\n\n\n\n\n\nSet a new app location.\n\n\n$\n \nnewt\n \ntarget\n \nset\n \ntask_tgt\n \napp=apps/mynewt_tasks_lesson\n\n\n\n\n\n\nNow let\u2019s take a look at our new code
. First, notice that we have abandoned blinking, instead choosing to use the \nconsole\n and \nshell\n to follow our tasks through execution.\n\n\nAdditionally, we have a number of different tasks:\n\n\n\n\n\n\nTask A\n (\na_task\n):\n\n\n\n\nPriority\n: 3 \u2192 2\n\n\nDescription\n: Task A is supposed to represent a task which frequently does a small amount of work, such as one which rapidly polls a sensor for data. Much like \nblinky_task\n, Task A will loop 10,000 times then wait 1 millisecond. Priority is changed by \ntimer_task\n after the first simulation.\n\n\n\n\n\n\n\n\nTask B\n (\nb_task\n):\n\n\n\n\nPriority\n: 2 \u2192 3\n\n\nDescription\n: Task B is supposed to represent a task which does a large amount of work relatively infrequently, such as one which sends/receives data from the cloud. Like work_task, Task B will loop 1,000,000 times then wait 3 seconds. Priority is changed by timer_task after the first simulation.\n\n\n\n\n\n\n\n\nTimer Task\n (\ntimer_task\n):\n\n
\n\n\nPriority\n: 1\n\n\nDescription\n: With default settings, Timer Task will wait 20 seconds then print the first simulations data for Task A and B. Timer task will then swap A and B\u2019s priorities and restart the simulation. After the second simulation, timer will again print simulation data then compare the two and calculate a final speedup (simulation2 / simulation1).\n\n\n\n\n\n\n\n\nShell Task\n:\n\n\n\n\nPriority\n: 0\n\n\nDescription\n: Task used by Shell behind the scenes to communicate with the serial port.\n\n\n\n\n\n\n\n\nConnecting to the Serial Console\n\n\nBefore running our new app, we must first connect to the serial console. First make sure the mynewt_arduino_zero repository is set to the develop branch. (Remove once changes have been moved to master). \n\n\n$ cd repos/mynewt_arduino_zero\n$ git checkout develop\n\n\n\n\n\nOpen a new terminal window and list your serial connections to find our Arduino.\n\n\n$\n \nls\n \n/dev/tty\n.\n*\n\n\n\n/dev/tty\n.\nBlueto
oth-Incoming-Port\n \n/dev/tty\n.\nusbmodem14132\n\n\n\n\n\n\nIn the same window, connect to the serial port using a serial communication program. In this case I\u2019ll be using mincom as it can scroll through output.\n\n\n$\n \nminicom\n \n-D\n \n/dev/tty\n.\nusbmodem14132\n \n-b\n \n115200\n\n\n\n\n\n\nIf you see minicom welcome you, you\u2019re ready to move on!\n\n\nOutput Analysis\n\n\nRun our new target, task_tgt, and you should see an output similar to this:\n\n\nStarting First Simulation...\n1: Task B: 0% \n78: Task B: 1% \n155: Task B: 2% \n257: Task B: 3% \n359: Task B: 4% \n461: Task B: 5% \n\n\nsnip\n\n\n========== Timer Expired ==========\n\n \n Task A \n\n Priority: 3\n Loop count: 162849\n Cycle count: 16.28\n Run time: 1.40 sec\n\n \n Task B \n\n Priority: 2\n Loop count: 1345852\n Cycle count: 1.34\n Run time: 17.0 sec\n\n Total loops: 1508709\n\n20023: Switching priorities and restarting...\n20111: Task A looped\n20113: Task
B: 0% \n20191: Task B: 1% \n20297: Task A looped\n20356: Task B: 2% \n20483: Task A looped\n20545: Task B: 3% \n20669: Task A looped\n20734: Task B: 4% \n20855: Task A looped\n20923: Task B: 5% \n\n\nsnip\n\n\n========== Timer Expired ==========\n\n \n Task A \n\n Priority: 2\n Loop count: 1080000\n Cycle count: 108.0\n Run time: 9.28 sec\n\n \n Task B \n\n Priority: 3\n Loop count: 830356\n Cycle count: 0.83\n Run time: 10.72 sec\n\n Total loops: 1910404\n\n40058:\n\n Final Speedup (Sim2 / Sim1): 1.26\n\n\n\n\n\nThe console output reaffirms our previous prediction and makes both the scheduling differences and subsequent efficiency boost far more apparent. Let\u2019s take a look at scheduling differences before we delve into efficiency.\n\n\nIn the first case, where Task B\u2019s priority is higher than that of Task A, we see A get starved by Task B\u2019s long execution time. \nStarvation\n occurs when one task hogs the processor, essentially \u
201cstarving\u201d other tasks which also need to run. At the end of the first 20 second simulation period, Task A has only run for 1.4 seconds compared to task B\u2019s 17 second running time \u2013 ouch. As explained before, processes which are expected to run for long periods of time (e.g. network communication, data processing) should be given higher priorities in order to combat starvation.\n\n\nIn the second simulation with priorities swapped, we can see Task B only running during the millisecond delays when Task A is \nsleeping\n. Although having Task B only run during these delays slows its execution time, we benefit from un-starving Task A and using the processor at a higher efficiency.\n\n\nThe bottom line speedup gives us an immediate and clear indication that we have improved our ability to process work (i.e throughput). In our second run, we processed an additional 400,000 loop iterations, equating to a 26% increase in efficiency. On a standard multi-core processor foun
d in every modern PC, a 1.26 speedup would be an ok result to adding multithreading capabilities to a serial program. However, we accomplished this by simply setting priorities on a single core processor \u2013 not bad!\n\n\nNOTE: Usually the the term \u201cspeedup\u201d is used within a parallel programming context and refers to the change in execution time between a serial and parallel program executing over the same problem. In this case we\u2019re using the term loosely to illustrate the priority change\u2019s effect on scheduling and throughput in our specific context.\n\n\nEfficiency Isn\u2019t Everything\n\n\nUsing the processor during every OS tick isn\u2019t always the best course of action. If we modify Task A\u2019s delay to a tenth of a millisecond and turn off the console output, we can boost our speedup to 1.44. This, however, reduces our ability to process work from Task B who ends up only completing 18% of its work cycle after the second simulation. That would mean,
at that rate, Task B would take over a minute to finish one cycle.\n\n\nFeel free to play around with the testing parameters to study the different changes yourself!\n\n\nConclusion\n\n\nMoving forward, tasks are just the tip of the iceberg. The \nscheduler\n, \nevent queues\n, \nsemaphores\n, and \nmutexes\n also add to tasks functionality, increasing our ability as the developer to control greater numbers of tasks more intricately. For example, when we switch the tasks priority, we have to tell the scheduler that our tasks priorities have changed, allowing us us to use priorities dynamically. When running multiple tasks, logging through either the built-in \nLogs\n module (not covered in this lesson) or through the serial console/shell can be very useful for debugging your application. In the end, the way you manage your tasks depends on the context of your application. You should assign priorities based on execution time, urgency, and frequency, among other things.\n\n\nKeep blin
king and happy hacking!",
+ "text": "Core OS Lesson: Tasks and Priority Management\n\n\nTarget Platform: Arduino M0 Pro\n (or legacy Arduino Zero or Zero Pro, but not Arduino M0)\n\n\nThis lesson is designed to teach core OS concepts and strategies encountered when \nbuilding applications using Mynewt. Specifically, this lesson will cover tasks, \nsimple multitasking, and priority management running on an Arduino M0 Pro.\n\n\nPrerequisites\n\n\nBefore starting, you should read about Mynewt in the \nIntroduction\n \nsection and complete the \nQuickStart\n \nguide and the \nBlinky\n tutorial. \nFurthermore, it may be helpful to take a peek at the \ntask documentation\n \nfor additional insights.\n\n\nEquipment\n\n\nYou will need the following equipment:\n\n\n\n\nArduino M0 Pro (or legacy Arduino Zero or Zero Pro, but not Arduino M0)\n\n\nComputer with Mynewt installed\n\n\nUSB to Micro USB Cable\n\n\n\n\nBuild Your Application\n\n\nTo save time, we will simply modify the Blinky app. We'll add the Tas
k Management code to\nthe Blinky app. Follow the \nArduino Zero Blinky tutorial\n \nto create a new project and build your bootloader and application. Finally, build and \nload the application to your Arduino to verify that everything is in order. Now let\u2019s get started!\n\n\nCreate a New Task\n\n\nThe purpose of this section is to give an introduction to the important aspects of tasks \nand how to properly initialize them. First, let\u2019s define a second task called \nwork_task\n \nin main.c (located in apps/blinky/src):\n\n\nstruct\n \nos_task\n \nwork_task\n;\n\n\n\n\n\nA task is represented by the \nos_task\n\nstruct which will hold the task\u2019s information (name, state, priority, etc.). A task is made up of two \nmain elements, a task function (also known as a task handler) and a task stack.\n\n\nNext, let\u2019s take a look at what is required to initialize our new task.\n\n\nTask Stack\n\n\nThe task stack is an array of type \nos_stack_t\n which holds the program sta
ck frames. Mynewt gives \nus the ability to set the stack size for a task giving the application developer room to optimize \nmemory usage. Since we\u2019re not short on memory, our \nblinky_stack\n and \nwork_stack\n are plenty large \nfor the purpose of this lesson. Notice that the elements in our task stack are of type \nos_stack_t\n \nwhich are generally 32 bits, making our entire stack 1024 Bytes.\n\n\n \n#define WORK_STACK_SIZE OS_STACK_ALIGN(256)\n\n \nos_stack_t\n \nwork_stack\n[\nWORK_STACK_SIZE\n];\n\n\n\n\n\nNote: The \nOS_STACK_ALIGN\n macro is used to align the stack based on the hardware architecture.\n\n\nTask Function\n\n\nThe task function is essentially an infinite loop which waits for some \u201cevent\u201d to wake it up. In our \nBlinky app the task function, named \nblinky_task_handler()\n, is initially called when we call \nos_start()\n \nin \nmain()\n. In general, the task function is where the majority of work is done by a task. Let\u2019s write \na task fu
nction for \nwork_task\n called \nwork_task_handler()\n:\n\n\nvoid\n\n\nwork_task_handler\n(\nvoid\n \n*arg\n)\n{\n \nstruct\n \nos_task\n \n*t\n;\n\n \ng_led_pin\n \n=\n \nLED_BLINK_PIN\n;\n \nhal_gpio_init_out\n(\ng_led_pin\n, \n1\n);\n\n \nwhile\n (\n1\n) {\n \nt\n \n=\n \nos_sched_get_current_task\n();\n \nassert\n(\nt-\nt_func\n \n==\n \nwork_task_handler\n);\n \n/* Do work... */\n\n }\n}\n\n\n\n\n\nThe task function is called when the task is initially put into the \nrunning\n state by the scheduler. \nWe use an infinite loop to ensure that the task function never returns. Our assertion that the current \ntask's handler is the same as our task handler is for illustration purposes only and does not need to \nbe in most task functions.\n\n\nTask Priority\n\n\nAs a preemptive, multitasking RTOS, Mynewt decides which tasks to run based on which has a higher \npriority; the highest priority being 0 and the lowest 255. Thus, before initializing ou
r task, we \nmust choose a priority defined as a macro variable.\n\n\nLet\u2019s set the priority of \nwork_task\n to 0, because everyone knows that work is more important than blinking.\n\n\n \n#define WORK_TASK_PRIO (0)\n\n\n\n\n\n\nInitialization\n\n\nTo initialize a new task we use \nos_task_init()\n \nwhich takes a number of arguments including our new task function, stack, and priority. Much like \nblinky_task\n, \nwe\u2019re going to initialize \nwork_task\n inside \ninit_tasks\n to keep our main function clean.\n\n\nint\n\n\ninit_tasks\n(\nvoid\n)\n{\n \n/* \u2026 */\n\n \nos_task_init\n(\nwork_task\n, \nwork\n, \nwork_task_handler\n, \nNULL\n,\n \nWORK_TASK_PRIO\n, \nOS_WAIT_FOREVER\n, \nwork_stack\n,\n \nWORK_STACK_SIZE\n);\n\n \ntasks_initialized\n \n=\n \n1\n;\n \nreturn\n \n0\n;\n}\n\n\n\n\n\nAnd that\u2019s it! Now run your application using the newt run command.\n\n\n$ newt run arduino_blinky 0.0.0\n\n\n\n\n\nWhen GDB appears press C
then Enter to continue and \u2026 \nwait, why doesn't our LED blink anymore?\n\n\nReview\n\n\nBefore we run our new app, let\u2019s review what we need in order to create a task. This is a general case for a new task called mytask:\n\n\n1)\n Define a new task, task stack, and priority:\n\n\n/* My Task */\n\n\nstruct\n \nos_task\n \nmytask\n\n\n/* My Task Stack */\n\n\n#define MYTASK_STACK_SIZE OS_STACK_ALIGN(256)\n\n\nos_stack_t\n \nmytask_stack\n[\nMYTASK_STACK_SIZE\n];\n\n/* My Task Priority */\n\n\n#define MYTASK_PRIO (0)\n\n\n\n\n\n\n2)\n Define task function:\n\n\nvoid\n \n\nmytask_handler\n(\nvoid\n \n*arg\n)\n{\n \nwhile\n (\n1\n) {\n \n/* ... */\n\n }\n}\n\n\n\n\n\n3)\n Initialize task before calling \nos_start()\n:\n\n\nos_task_init\n(\nmytask\n, \nmytask\n, \nmytask_handler\n, \nNULL\n, \n \nMYTASK_PRIO\n, \nOS_WAIT_FOREVER\n, \nmytask_stack\n,\n \nMYTASK_STACK_SIZE\n);\n\n\n\n\n\nTask Priority, Preempting, and Context Switching\n\n\nA preem
ptive RTOS is one in which a higher priority task that is \nready to run\n will preempt (i.e. take the \nplace of) the lower priority task which is \nrunning\n. When a lower priority task is preempted by a higher \npriority task, the lower priority task\u2019s context data (stack pointer, registers, etc.) is saved and the new \ntask is switched in.\n\n\nIn our example, \nwork_task\n has a higher priority than \nblinky_task\n and, because it is never put into a \n\nsleep\n state, holds the processor focus on its context. Let\u2019s give \nwork_task\n a delay and some simulated \nwork to keep it busy. Because the delay is measured in os ticks, the actual number of ticks per second is \ndependent on the board. Therefore, we multiply \nOS_TICKS_PER_SEC\n, which is defined in the MCU, by the \nnumber of seconds we wish to delay.\n\n\nvoid\n\n\nwork_task_handler\n(\nvoid\n \n*arg\n)\n{\n \nstruct\n \nos_task\n \n*t\n;\n\n \ng_led_pin\n \n=\n \nLED_BLINK_PIN\n;\n \nhal_gpio_init_o
ut\n(\ng_led_pin\n, \n1\n);\n\n \nwhile\n (\n1\n) {\n \nt\n \n=\n \nos_sched_get_current_t\n:ask\n();\n \nassert\n(\nt-\nt_func\n \n==\n \nwork_task_handler\n);\n \n/* Do work... */\n\n \nint\n \ni\n;\n \nfor\n(\ni\n \n=\n \n0\n; \ni\n \n \n1000000\n; \n++i\n) {\n \n/* Simulate doing a noticeable amount of work */\n\n \nhal_gpio_set\n(\ng_led_pin\n);\n }\n \nos_time_delay\n(\n3\n*OS_TICKS_PER_SECOND\n);\n }\n}\n\n\n\n\n\nIn order to notice the LED changing, modify the time delay in \nblinky_task_handler()\n to blink at a higher frequency.\n\n\nos_time_delay\n(\nOS_TICKS_PER_SEC/\n10\n);\n\n\n\n\n\nBefore we run the app, let\u2019s predict the behavior. With the newest additions to \nwork_task_handler()\n, \nour first action will be to sleep for three seconds. This will allow \nblinky_task\n to take over the CPU \nand blink to its heart\u2019s content. After three seconds, \nwork_task\n will wake up and be m
ade \nready to run\n, \ncausing it to preempt \nblinky_task\n. The LED will then remain lit for a short period while \nwork_task\n \nloops, then blink again for another three seconds while \nwork_task\n sleeps. \n\n\nVoila, you should see that our prediction was correct! \n\n\nPriority Management Considerations\n\n\nWhen projects grow in scope, from blinking LEDs into more sophisticated applications, the number of \ntasks needed increases alongside complexity. It remains important, then, that each of our tasks is \ncapable of doing its work within a reasonable amount of time.\n\n\nSome tasks, such as the Shell task, execute quickly and require almost instantaneous response. Therefore, \nthe Shell task should be given a high priority. On the other hand, tasks which may be communicating over \na network, or processing data, should be given a low priority in order to not hog the CPU.\n\n\nThe diagram below showcases the different scheduling patterns we. would expect from swapping blink
y and \nwork tasks priorities.\n\n\n\n\nIn the second case where \nblinky_task\n has a higher priority, the \u201cwork\u201d done by \nwork_task\n would be \nexecuted during the millisecond delays in \nblinky_task\n, saving us idle time compared to the first case.\n\n\nNote:\n Defining the same priority for two tasks leads to somewhat undefined behavior and should be avoided.\n\n\nComparing Priority Strategies\n\n\nInstead of stepping through a bunch of changes to our blinky app, clone my task lesson application from \ngithub and copy an existing target.\n\n\nChange directory into apps and clone the repository to get our new\nfiles:\n\n\n$ cd apps\n$ git clone https://github.com/bgiori/mynewt_tasks_lesson.git\n\n\n\n\n\nChange directory back to your project root and copy the arduino_blinky target to a new target called task_tgt.\n\n\n$\n \nnewt\n \ntarget\n \ncopy\n \narduino_blinky\n \ntask_tgt\n\n\n\n\n\n\nSet a new app location.\n\n\n$\n \nnewt\n \ntarget\n \nset\n \ntask_tgt\n
\napp=apps/mynewt_tasks_lesson\n\n\n\n\n\n\nNow let\u2019s take a look at our new code. First, notice that we have abandoned blinking, instead choosing t\no use the \nconsole\n and \nshell\n \nto follow our tasks through execution.\n\n\nAdditionally, we have a number of different tasks:\n\n\n\n\n\n\nTask A\n (\na_task\n):\n\n\n\n\nPriority\n: 3 \u2192 2\n\n\nDescription\n: Task A is supposed to represent a task which frequently does a small amount \nof work, such as one which rapidly polls a sensor for data. Much like \nblinky_task\n, Task A will \nloop 10,000 times then wait 1 millisecond. Priority is changed by \ntimer_task\n after the first simulation.\n\n\n\n\n\n\n\n\nTask B\n (\nb_task\n):\n\n\n\n\nPriority\n: 2 \u2192 3\n\n\nDescription\n: Task B is supposed to represent a task which does a large amount of work \nrelatively infrequently, such as one which sends/receives data from the cloud. Like work_task, \nTask B will loop 1,000,000 times then wait 3 seconds. Priority is cha
nged by timer_task after \nthe first simulation.\n\n\n\n\n\n\n\n\nTimer Task\n (\ntimer_task\n):\n\n\n\n\nPriority\n: 1\n\n\nDescription\n: With default settings, Timer Task will wait 20 seconds then print the first \nsimulations data for Task A and B. Timer task will then swap A and B\u2019s priorities and restart the \nsimulation. After the second simulation, timer will again print simulation data then compare the \ntwo and calculate a final speedup (simulation2 / simulation1).\n\n\n\n\n\n\n\n\nShell Task\n:\n\n\n\n\nPriority\n: 0\n\n\nDescription\n: Task used by Shell behind the scenes to communicate with the serial port.\n\n\n\n\n\n\n\n\nConnecting to the Serial Console\n\n\nBefore running our new app, we must first connect to the serial console. First make sure the \nmynewt_arduino_zero repository is set to the develop branch. (Remove once changes have been \nmoved to master). \n\n\n$ cd repos/mynewt_arduino_zero\n$ git checkout develop\n\n\n\n\n\nOpen a new terminal window and
list your serial connections to find our Arduino.\n\n\n$\n \nls\n \n/dev/tty\n.\n*\n\n\n\n/dev/tty\n.\nBluetooth-Incoming-Port\n \n/dev/tty\n.\nusbmodem14132\n\n\n\n\n\n\nIn the same window, connect to the serial port using a serial communication program. \nIn this case I\u2019ll be using mincom as it can scroll through output.\n\n\n$\n \nminicom\n \n-D\n \n/dev/tty\n.\nusbmodem14132\n \n-b\n \n115200\n\n\n\n\n\n\nIf you see minicom welcome you, you\u2019re ready to move on!\n\n\nOutput Analysis\n\n\nRun our new target, task_tgt, and you should see an output similar to this:\n\n\nStarting First Simulation...\n1: Task B: 0% \n78: Task B: 1% \n155: Task B: 2% \n257: Task B: 3% \n359: Task B: 4% \n461: Task B: 5% \n\n\nsnip\n\n\n========== Timer Expired ==========\n\n \n Task A \n\n Priority: 3\n Loop count: 162849\n Cycle count: 16.28\n Run time: 1.40 sec\n\n \n Task B \n\n Priority: 2\n Loop count: 1345852\n Cycle count: 1.34\n Run time: 17.0 sec\n\n
Total loops: 1508709\n\n20023: Switching priorities and restarting...\n20111: Task A looped\n20113: Task B: 0% \n20191: Task B: 1% \n20297: Task A looped\n20356: Task B: 2% \n20483: Task A looped\n20545: Task B: 3% \n20669: Task A looped\n20734: Task B: 4% \n20855: Task A looped\n20923: Task B: 5% \n\n\nsnip\n\n\n========== Timer Expired ==========\n\n \n Task A \n\n Priority: 2\n Loop count: 1080000\n Cycle count: 108.0\n Run time: 9.28 sec\n\n \n Task B \n\n Priority: 3\n Loop count: 830356\n Cycle count: 0.83\n Run time: 10.72 sec\n\n Total loops: 1910404\n\n40058:\n\n Final Speedup (Sim2 / Sim1): 1.26\n\n\n\n\n\nThe console output reaffirms our previous prediction and makes both the scheduling differences \nand subsequent efficiency boost far more apparent. Let\u2019s take a look at scheduling differences \nbefore we delve into efficiency.\n\n\nIn the first case, where Task B\u2019s priority is higher than that of Task A, we see A get
starved \nby Task B\u2019s long execution time. \nStarvation\n occurs when one task hogs the processor, essentially \n\u201cstarving\u201d other tasks which also need to run. At the end of the first 20 second simulation period, \nTask A has only run for 1.4 seconds compared to task B\u2019s 17 second running time \u2013 ouch. As explained \nbefore, processes which are expected to run for long periods of time (e.g. network communication, \ndata processing) should be given higher priorities in order to combat starvation.\n\n\nIn the second simulation with priorities swapped, we can see Task B only running during the \nmillisecond delays when Task A is \nsleeping\n. Although having Task B only run during these \ndelays slows its execution time, we benefit from un-starving Task A and using the processor \nat a higher efficiency.\n\n\nThe bottom line speedup gives us an immediate and clear indication that we have improved our \nability to process work (i.e throughput). In our second run,
we processed an additional 400,000 \nloop iterations, equating to a 26% increase in efficiency. On a standard multi-core processor \nfound in every modern PC, a 1.26 speedup would be an ok result to adding multithreading capabilities \nto a serial program. However, we accomplished this by simply setting priorities on a single core \nprocessor \u2013 not bad!\n\n\nNOTE: Usually the the term \u201cspeedup\u201d is used within a parallel programming context and refers \nto the change in execution time between a serial and parallel program executing over the same \nproblem. In this case we\u2019re using the term loosely to illustrate the priority change\u2019s effect \non scheduling and throughput in our specific context.\n\n\nEfficiency Isn\u2019t Everything\n\n\nUsing the processor during every OS tick isn\u2019t always the best course of action. If we modify \nTask A\u2019s delay to a tenth of a millisecond and turn off the console output, we can boost our \nspeedup to 1.44. This, h
owever, reduces our ability to process work from Task B who ends up \nonly completing 18% of its work cycle after the second simulation. That would mean, at that \nrate, Task B would take over a minute to finish one cycle.\n\n\nFeel free to play around with the testing parameters to study the different changes yourself!\n\n\nConclusion\n\n\nMoving forward, tasks are just the tip of the iceberg. The \nscheduler\n, \n\nevent queues\n, \n\nsemaphores\n, and \n\nmutexes\n also add to tasks functionality, \nincreasing our ability as the developer to control greater numbers of tasks more intricately. For \nexample, when we switch the tasks priority, we have to tell the scheduler that our tasks priorities \nhave changed, allowing us us to use priorities dynamically. When running multiple tasks, logging \nthrough either the built-in \nLogs\n module \n(not covered in this lesson) or through the serial console/shell can be very useful for debugging \nyour application. In the end, the way you
manage your tasks depends on the context of your \napplication. You should assign priorities based on execution time, urgency, and frequency, among \nother things.\n\n\nKeep blinking and happy hacking!",
"title": "Tasks and Priority Management"
},
{
"location": "/os/tutorials/tasks_lesson/#core-os-lesson-tasks-and-priority-management",
- "text": "Target Platform: Arduino M0 Pro (or legacy Arduino Zero or Zero Pro, but not Arduino M0) This lesson is designed to teach core OS concepts and strategies encountered when building applications using Mynewt. Specifically, this lesson will cover tasks, simple multitasking, and priority management running on an Arduino M0 Pro.",
+ "text": "Target Platform: Arduino M0 Pro (or legacy Arduino Zero or Zero Pro, but not Arduino M0) This lesson is designed to teach core OS concepts and strategies encountered when \nbuilding applications using Mynewt. Specifically, this lesson will cover tasks, \nsimple multitasking, and priority management running on an Arduino M0 Pro.",
"title": "Core OS Lesson: Tasks and Priority Management"
},
{
"location": "/os/tutorials/tasks_lesson/#prerequisites",
- "text": "Before starting, you should read about Mynewt in the Introduction section and complete the QuickStart guide and the Blinky tutorial. Furthermore, it may be helpful to take a peek at the task documentation for additional insights.",
+ "text": "Before starting, you should read about Mynewt in the Introduction \nsection and complete the QuickStart \nguide and the Blinky tutorial. \nFurthermore, it may be helpful to take a peek at the task documentation \nfor additional insights.",
"title": "Prerequisites"
},
{
@@ -987,32 +987,32 @@
},
{
"location": "/os/tutorials/tasks_lesson/#build-your-application",
- "text": "To save time, we will simply modify the Blinky app as it has the basic task structure already implemented. Follow the Arduino Zero Blinky tutorial to create a new project and build your bootloader and application. Finally, build and load the application to your Arduino to verify that everything is in order. Now let\u2019s get started!",
+ "text": "To save time, we will simply modify the Blinky app. We'll add the Task Management code to\nthe Blinky app. Follow the Arduino Zero Blinky tutorial \nto create a new project and build your bootloader and application. Finally, build and \nload the application to your Arduino to verify that everything is in order. Now let\u2019s get started!",
"title": "Build Your Application"
},
{
"location": "/os/tutorials/tasks_lesson/#create-a-new-task",
- "text": "The purpose of this section is to give an introduction to the important aspects of tasks and how to properly initialize them. First, let\u2019s define a second task called work_task in main.c (located in apps/blinky/src): struct os_task work_task ; A task is represented by the os_task struct which will hold the task\u2019s information (name, state, priority, etc.). A task is made up of two main elements, a task function (also known as a task handler) and a task stack. Next, let\u2019s take a look at what is required to initialize our new task.",
+ "text": "The purpose of this section is to give an introduction to the important aspects of tasks \nand how to properly initialize them. First, let\u2019s define a second task called work_task \nin main.c (located in apps/blinky/src): struct os_task work_task ; A task is represented by the os_task \nstruct which will hold the task\u2019s information (name, state, priority, etc.). A task is made up of two \nmain elements, a task function (also known as a task handler) and a task stack. Next, let\u2019s take a look at what is required to initialize our new task.",
"title": "Create a New Task"
},
{
"location": "/os/tutorials/tasks_lesson/#task-stack",
- "text": "The task stack is an array of type os_stack_t which holds the program stack frames. Mynewt gives us the ability to set the stack size for a task giving the application developer room to optimize memory usage. Since we\u2019re not short on memory, our blinky_stack and work_stack are plenty large for the purpose of this lesson. Notice that the elements in our task stack are of type os_stack_t which are generally 32 bits, making our entire stack 1024 Bytes. #define WORK_STACK_SIZE OS_STACK_ALIGN(256) \n os_stack_t work_stack [ WORK_STACK_SIZE ]; Note: The OS_STACK_ALIGN macro is used to align the stack based on the hardware architecture.",
+ "text": "The task stack is an array of type os_stack_t which holds the program stack frames. Mynewt gives \nus the ability to set the stack size for a task giving the application developer room to optimize \nmemory usage. Since we\u2019re not short on memory, our blinky_stack and work_stack are plenty large \nfor the purpose of this lesson. Notice that the elements in our task stack are of type os_stack_t \nwhich are generally 32 bits, making our entire stack 1024 Bytes. #define WORK_STACK_SIZE OS_STACK_ALIGN(256) \n os_stack_t work_stack [ WORK_STACK_SIZE ]; Note: The OS_STACK_ALIGN macro is used to align the stack based on the hardware architecture.",
"title": "Task Stack"
},
{
"location": "/os/tutorials/tasks_lesson/#task-function",
- "text": "The task function is essentially an infinite loop which waits for some \u201cevent\u201d to wake it up. In our Blinky app the task function, named blinky_task_handler() , is initially called when we call os_start() in main() . In general, the task function is where the majority of work is done by a task. Let\u2019s write a task function for work_task called work_task_handler() : void work_task_handler ( void *arg )\n{\n struct os_task *t ;\n\n g_led_pin = LED_BLINK_PIN ;\n hal_gpio_init_out ( g_led_pin , 1 );\n\n while ( 1 ) {\n t = os_sched_get_current_task ();\n assert ( t- t_func == work_task_handler );\n /* Do work... */ \n }\n} The task function is called when the task is initially put into the running state by the scheduler. We use an infinite loop to ensure that the task function never returns. Our assertion that the current task's handler is the same as our task handler is for ill
ustration purposes only and does not need to be in most task functions.",
+ "text": "The task function is essentially an infinite loop which waits for some \u201cevent\u201d to wake it up. In our \nBlinky app the task function, named blinky_task_handler() , is initially called when we call os_start() \nin main() . In general, the task function is where the majority of work is done by a task. Let\u2019s write \na task function for work_task called work_task_handler() : void work_task_handler ( void *arg )\n{\n struct os_task *t ;\n\n g_led_pin = LED_BLINK_PIN ;\n hal_gpio_init_out ( g_led_pin , 1 );\n\n while ( 1 ) {\n t = os_sched_get_current_task ();\n assert ( t- t_func == work_task_handler );\n /* Do work... */ \n }\n} The task function is called when the task is initially put into the running state by the scheduler. \nWe use an infinite loop to ensure that the task function never returns. Our assertion that the current \ntask's handler is the same as our task handler
is for illustration purposes only and does not need to \nbe in most task functions.",
"title": "Task Function"
},
{
"location": "/os/tutorials/tasks_lesson/#task-priority",
- "text": "As a preemptive, multitasking RTOS, Mynewt decides which tasks to run based on which has a higher priority; the highest priority being 0 and the lowest 255. Thus, before initializing our task, we must choose a priority defined as a macro variable. Let\u2019s set the priority of work_task to 0, because everyone knows that work is more important than blinking. #define WORK_TASK_PRIO (0)",
+ "text": "As a preemptive, multitasking RTOS, Mynewt decides which tasks to run based on which has a higher \npriority; the highest priority being 0 and the lowest 255. Thus, before initializing our task, we \nmust choose a priority defined as a macro variable. Let\u2019s set the priority of work_task to 0, because everyone knows that work is more important than blinking. #define WORK_TASK_PRIO (0)",
"title": "Task Priority"
},
{
"location": "/os/tutorials/tasks_lesson/#initialization",
- "text": "To initialize a new task we use os_task_init() which takes a number of arguments including our new task function, stack, and priority. Much like blinky_task , we\u2019re going to initialize work_task inside init_tasks to keep our main function clean. int init_tasks ( void )\n{\n /* \u2026 */ \n os_task_init ( work_task , work , work_task_handler , NULL ,\n WORK_TASK_PRIO , OS_WAIT_FOREVER , work_stack ,\n WORK_STACK_SIZE );\n\n tasks_initialized = 1 ;\n return 0 ;\n} And that\u2019s it! Now run your application using the newt run command. $ newt run arduino_blinky 0.0.0 When GDB appears press C then Enter to continue and \u2026 wait, why doesn't our LED blink anymore?",
+ "text": "To initialize a new task we use os_task_init() \nwhich takes a number of arguments including our new task function, stack, and priority. Much like blinky_task , \nwe\u2019re going to initialize work_task inside init_tasks to keep our main function clean. int init_tasks ( void )\n{\n /* \u2026 */ \n os_task_init ( work_task , work , work_task_handler , NULL ,\n WORK_TASK_PRIO , OS_WAIT_FOREVER , work_stack ,\n WORK_STACK_SIZE );\n\n tasks_initialized = 1 ;\n return 0 ;\n} And that\u2019s it! Now run your application using the newt run command. $ newt run arduino_blinky 0.0.0 When GDB appears press C then Enter to continue and \u2026 wait, why doesn't our LED blink anymore?",
"title": "Initialization"
},
{
@@ -1022,42 +1022,42 @@
},
{
"location": "/os/tutorials/tasks_lesson/#task-priority-preempting-and-context-switching",
- "text": "A preemptive RTOS is one in which a higher priority task that is ready to run will preempt (i.e. take the place of) the lower priority task which is running . When a lower priority task is preempted by a higher priority task, the lower priority task\u2019s context data (stack pointer, registers, etc.) is saved and the new task is switched in. In our example, work_task has a higher priority than blinky_task and, because it is never put into a sleep state, holds the processor focus on its context. Let\u2019s give work_task a delay and some simulated work to keep it busy. Because the delay is measured in os ticks, the actual number of ticks per second is dependent on the board. Therefore, we multiply OS_TICKS_PER_SEC , which is defined in the MCU, by the number of seconds we wish to delay. void work_task_handler ( void *arg )\n{\n struct os_task *t ;\n\n g_led_pin = LED_BLINK_PIN ;\n hal_gpio_init_out ( g_led_pin , 1 );\n\n
while ( 1 ) {\n t = os_sched_get_current_t :ask ();\n assert ( t- t_func == work_task_handler );\n /* Do work... */ \n int i ;\n for ( i = 0 ; i 1000000 ; ++i ) {\n /* Simulate doing a noticeable amount of work */ \n hal_gpio_set ( g_led_pin );\n }\n os_time_delay ( 3 *OS_TICKS_PER_SECOND );\n }\n} In order to notice the LED changing, modify the time delay in blinky_task_handler() to blink at a higher frequency. os_time_delay ( OS_TICKS_PER_SEC/ 10 ); Before we run the app, let\u2019s predict the behavior. With the newest additions to work_task_handler() , our first action will be to sleep for three seconds. This will allow blinky_task to take over the CPU and blink to its heart\u2019s content. After three seconds, work_task will wake up and be made ready to run , causing it to preempt blinky_task . The LED will then remain lit for a short period while work_task loop
s, then blink again for another three seconds while work_task sleeps. Voila, you should see that our prediction was correct!",
+ "text": "A preemptive RTOS is one in which a higher priority task that is ready to run will preempt (i.e. take the \nplace of) the lower priority task which is running . When a lower priority task is preempted by a higher \npriority task, the lower priority task\u2019s context data (stack pointer, registers, etc.) is saved and the new \ntask is switched in. In our example, work_task has a higher priority than blinky_task and, because it is never put into a sleep state, holds the processor focus on its context. Let\u2019s give work_task a delay and some simulated \nwork to keep it busy. Because the delay is measured in os ticks, the actual number of ticks per second is \ndependent on the board. Therefore, we multiply OS_TICKS_PER_SEC , which is defined in the MCU, by the \nnumber of seconds we wish to delay. void work_task_handler ( void *arg )\n{\n struct os_task *t ;\n\n g_led_pin = LED_BLINK_PIN ;\n hal_gpio_init_out ( g_led_pin ,
1 );\n\n while ( 1 ) {\n t = os_sched_get_current_t :ask ();\n assert ( t- t_func == work_task_handler );\n /* Do work... */ \n int i ;\n for ( i = 0 ; i 1000000 ; ++i ) {\n /* Simulate doing a noticeable amount of work */ \n hal_gpio_set ( g_led_pin );\n }\n os_time_delay ( 3 *OS_TICKS_PER_SECOND );\n }\n} In order to notice the LED changing, modify the time delay in blinky_task_handler() to blink at a higher frequency. os_time_delay ( OS_TICKS_PER_SEC/ 10 ); Before we run the app, let\u2019s predict the behavior. With the newest additions to work_task_handler() , \nour first action will be to sleep for three seconds. This will allow blinky_task to take over the CPU \nand blink to its heart\u2019s content. After three seconds, work_task will wake up and be made ready to run , \ncausing it to preempt blinky_task . The LED will then remain lit for a short period whil
e work_task \nloops, then blink again for another three seconds while work_task sleeps. Voila, you should see that our prediction was correct!",
"title": "Task Priority, Preempting, and Context Switching"
},
{
"location": "/os/tutorials/tasks_lesson/#priority-management-considerations",
- "text": "When projects grow in scope, from blinking LEDs into more sophisticated applications, the number of tasks needed increases alongside complexity. It remains important, then, that each of our tasks is capable of doing its work within a reasonable amount of time. Some tasks, such as the Shell task, execute quickly and require almost instantaneous response. Therefore, the Shell task should be given a high priority. On the other hand, tasks which may be communicating over a network, or processing data, should be given a low priority in order to not hog the CPU. The diagram below showcases the different scheduling patterns we. would expect from swapping blinky and work tasks priorities. In the second case where blinky_task has a higher priority, the \u201cwork\u201d done by work_task would be executed during the millisecond delays in blinky_task , saving us idle time compared to the first case. Note: Defining the same priority for two tasks leads to somewha
t undefined behavior and should be avoided.",
+ "text": "When projects grow in scope, from blinking LEDs into more sophisticated applications, the number of \ntasks needed increases alongside complexity. It remains important, then, that each of our tasks is \ncapable of doing its work within a reasonable amount of time. Some tasks, such as the Shell task, execute quickly and require almost instantaneous response. Therefore, \nthe Shell task should be given a high priority. On the other hand, tasks which may be communicating over \na network, or processing data, should be given a low priority in order to not hog the CPU. The diagram below showcases the different scheduling patterns we. would expect from swapping blinky and \nwork tasks priorities. In the second case where blinky_task has a higher priority, the \u201cwork\u201d done by work_task would be \nexecuted during the millisecond delays in blinky_task , saving us idle time compared to the first case. Note: Defining the same priority for two tasks lead
s to somewhat undefined behavior and should be avoided.",
"title": "Priority Management Considerations"
},
{
"location": "/os/tutorials/tasks_lesson/#comparing-priority-strategies",
- "text": "Instead of stepping through a bunch of changes to our blinky app, clone my task lesson application from github and copy an existing target. Change directory into apps and clone the repository to get our new\nfiles: $ cd apps\n$ git clone https://github.com/bgiori/mynewt_tasks_lesson.git Change directory back to your project root and copy the arduino_blinky target to a new target called task_tgt. $ newt target copy arduino_blinky task_tgt Set a new app location. $ newt target set task_tgt app=apps/mynewt_tasks_lesson Now let\u2019s take a look at our new code. First, notice that we have abandoned blinking, instead choosing to use the console and shell to follow our tasks through execution. Additionally, we have a number of different tasks: Task A ( a_task ): Priority : 3 \u2192 2 Description : Task A is supposed to represent a task which frequently does a small amount of work, such as one which rapidly polls a sensor for
data. Much like blinky_task , Task A will loop 10,000 times then wait 1 millisecond. Priority is changed by timer_task after the first simulation. Task B ( b_task ): Priority : 2 \u2192 3 Description : Task B is supposed to represent a task which does a large amount of work relatively infrequently, such as one which sends/receives data from the cloud. Like work_task, Task B will loop 1,000,000 times then wait 3 seconds. Priority is changed by timer_task after the first simulation. Timer Task ( timer_task ): Priority : 1 Description : With default settings, Timer Task will wait 20 seconds then print the first simulations data for Task A and B. Timer task will then swap A and B\u2019s priorities and restart the simulation. After the second simulation, timer will again print simulation data then compare the two and calculate a final speedup (simulation2 / simulation1). Shell Task : Priority : 0 Description : Task used by Shell behind the scenes to communicate
with the serial port.",
+ "text": "Instead of stepping through a bunch of changes to our blinky app, clone my task lesson application from \ngithub and copy an existing target. Change directory into apps and clone the repository to get our new\nfiles: $ cd apps\n$ git clone https://github.com/bgiori/mynewt_tasks_lesson.git Change directory back to your project root and copy the arduino_blinky target to a new target called task_tgt. $ newt target copy arduino_blinky task_tgt Set a new app location. $ newt target set task_tgt app=apps/mynewt_tasks_lesson Now let\u2019s take a look at our new code. First, notice that we have abandoned blinking, instead choosing t\no use the console and shell \nto follow our tasks through execution. Additionally, we have a number of different tasks: Task A ( a_task ): Priority : 3 \u2192 2 Description : Task A is supposed to represent a task which frequently does a small amount \nof work, such as one which rapidly polls a sen
sor for data. Much like blinky_task , Task A will \nloop 10,000 times then wait 1 millisecond. Priority is changed by timer_task after the first simulation. Task B ( b_task ): Priority : 2 \u2192 3 Description : Task B is supposed to represent a task which does a large amount of work \nrelatively infrequently, such as one which sends/receives data from the cloud. Like work_task, \nTask B will loop 1,000,000 times then wait 3 seconds. Priority is changed by timer_task after \nthe first simulation. Timer Task ( timer_task ): Priority : 1 Description : With default settings, Timer Task will wait 20 seconds then print the first \nsimulations data for Task A and B. Timer task will then swap A and B\u2019s priorities and restart the \nsimulation. After the second simulation, timer will again print simulation data then compare the \ntwo and calculate a final speedup (simulation2 / simulation1). Shell Task : Priority : 0 Description : Task used by Shell behind the
scenes to communicate with the serial port.",
"title": "Comparing Priority Strategies"
},
{
"location": "/os/tutorials/tasks_lesson/#connecting-to-the-serial-console",
- "text": "Before running our new app, we must first connect to the serial console. First make sure the mynewt_arduino_zero repository is set to the develop branch. (Remove once changes have been moved to master). $ cd repos/mynewt_arduino_zero\n$ git checkout develop Open a new terminal window and list your serial connections to find our Arduino. $ ls /dev/tty . * /dev/tty . Bluetooth-Incoming-Port /dev/tty . usbmodem14132 In the same window, connect to the serial port using a serial communication program. In this case I\u2019ll be using mincom as it can scroll through output. $ minicom -D /dev/tty . usbmodem14132 -b 115200 If you see minicom welcome you, you\u2019re ready to move on!",
+ "text": "Before running our new app, we must first connect to the serial console. First make sure the \nmynewt_arduino_zero repository is set to the develop branch. (Remove once changes have been \nmoved to master). $ cd repos/mynewt_arduino_zero\n$ git checkout develop Open a new terminal window and list your serial connections to find our Arduino. $ ls /dev/tty . * /dev/tty . Bluetooth-Incoming-Port /dev/tty . usbmodem14132 In the same window, connect to the serial port using a serial communication program. \nIn this case I\u2019ll be using mincom as it can scroll through output. $ minicom -D /dev/tty . usbmodem14132 -b 115200 If you see minicom welcome you, you\u2019re ready to move on!",
"title": "Connecting to the Serial Console"
},
{
"location": "/os/tutorials/tasks_lesson/#output-analysis",
- "text": "Run our new target, task_tgt, and you should see an output similar to this: Starting First Simulation...\n1: Task B: 0% \n78: Task B: 1% \n155: Task B: 2% \n257: Task B: 3% \n359: Task B: 4% \n461: Task B: 5% snip \n\n========== Timer Expired ==========\n\n Task A \n Priority: 3\n Loop count: 162849\n Cycle count: 16.28\n Run time: 1.40 sec\n\n Task B \n Priority: 2\n Loop count: 1345852\n Cycle count: 1.34\n Run time: 17.0 sec\n\n Total loops: 1508709\n\n20023: Switching priorities and restarting...\n20111: Task A looped\n20113: Task B: 0% \n20191: Task B: 1% \n20297: Task A looped\n20356: Task B: 2% \n20483: Task A looped\n20545: Task B: 3% \n20669: Task A looped\n20734: Task B: 4% \n20855: Task A looped\n20923: Task B: 5% snip \n\n========== Timer Expired ==========\n\n Task A \n Priority: 2\n Loop count: 1080000\n Cycle count: 108.0\n Run time: 9.28 sec\n\n Task B \n Prio
rity: 3\n Loop count: 830356\n Cycle count: 0.83\n Run time: 10.72 sec\n\n Total loops: 1910404\n\n40058:\n\n Final Speedup (Sim2 / Sim1): 1.26 The console output reaffirms our previous prediction and makes both the scheduling differences and subsequent efficiency boost far more apparent. Let\u2019s take a look at scheduling differences before we delve into efficiency. In the first case, where Task B\u2019s priority is higher than that of Task A, we see A get starved by Task B\u2019s long execution time. Starvation occurs when one task hogs the processor, essentially \u201cstarving\u201d other tasks which also need to run. At the end of the first 20 second simulation period, Task A has only run for 1.4 seconds compared to task B\u2019s 17 second running time \u2013 ouch. As explained before, processes which are expected to run for long periods of time (e.g. network communication, data processing) should be given higher priorities in order to combat starvation. In the second
simulation with priorities swapped, we can see Task B only running during the millisecond delays when Task A is sleeping . Although having Task B only run during these delays slows its execution time, we benefit from un-starving Task A and using the processor at a higher efficiency. The bottom line speedup gives us an immediate and clear indication that we have improved our ability to process work (i.e throughput). In our second run, we processed an additional 400,000 loop iterations, equating to a 26% increase in efficiency. On a standard multi-core processor found in every modern PC, a 1.26 speedup would be an ok result to adding multithreading capabilities to a serial program. However, we accomplished this by simply setting priorities on a single core processor \u2013 not bad! NOTE: Usually the the term \u201cspeedup\u201d is used within a parallel programming context and refers to the change in execution time between a serial and parallel program executing over the same probl
em. In this case we\u2019re using the term loosely to illustrate the priority change\u2019s effect on scheduling and throughput in our specific context.",
+ "text": "Run our new target, task_tgt, and you should see an output similar to this: Starting First Simulation...\n1: Task B: 0% \n78: Task B: 1% \n155: Task B: 2% \n257: Task B: 3% \n359: Task B: 4% \n461: Task B: 5% snip \n\n========== Timer Expired ==========\n\n Task A \n Priority: 3\n Loop count: 162849\n Cycle count: 16.28\n Run time: 1.40 sec\n\n Task B \n Priority: 2\n Loop count: 1345852\n Cycle count: 1.34\n Run time: 17.0 sec\n\n Total loops: 1508709\n\n20023: Switching priorities and restarting...\n20111: Task A looped\n20113: Task B: 0% \n20191: Task B: 1% \n20297: Task A looped\n20356: Task B: 2% \n20483: Task A looped\n20545: Task B: 3% \n20669: Task A looped\n20734: Task B: 4% \n20855: Task A looped\n20923: Task B: 5% snip \n\n========== Timer Expired ==========\n\n Task A \n Priority: 2\n Loop count: 1080000\n Cycle count: 108.0\n Run time: 9.28 sec\n\n Task B \n Prio
rity: 3\n Loop count: 830356\n Cycle count: 0.83\n Run time: 10.72 sec\n\n Total loops: 1910404\n\n40058:\n\n Final Speedup (Sim2 / Sim1): 1.26 The console output reaffirms our previous prediction and makes both the scheduling differences \nand subsequent efficiency boost far more apparent. Let\u2019s take a look at scheduling differences \nbefore we delve into efficiency. In the first case, where Task B\u2019s priority is higher than that of Task A, we see A get starved \nby Task B\u2019s long execution time. Starvation occurs when one task hogs the processor, essentially \n\u201cstarving\u201d other tasks which also need to run. At the end of the first 20 second simulation period, \nTask A has only run for 1.4 seconds compared to task B\u2019s 17 second running time \u2013 ouch. As explained \nbefore, processes which are expected to run for long periods of time (e.g. network communication, \ndata processing) should be given higher priorities in order to combat starvation.
In the second simulation with priorities swapped, we can see Task B only running during the \nmillisecond delays when Task A is sleeping . Although having Task B only run during these \ndelays slows its execution time, we benefit from un-starving Task A and using the processor \nat a higher efficiency. The bottom line speedup gives us an immediate and clear indication that we have improved our \nability to process work (i.e throughput). In our second run, we processed an additional 400,000 \nloop iterations, equating to a 26% increase in efficiency. On a standard multi-core processor \nfound in every modern PC, a 1.26 speedup would be an ok result to adding multithreading capabilities \nto a serial program. However, we accomplished this by simply setting priorities on a single core \nprocessor \u2013 not bad! NOTE: Usually the the term \u201cspeedup\u201d is used within a parallel programming context and refers \nto the change in execution time between a serial and parallel progr
am executing over the same \nproblem. In this case we\u2019re using the term loosely to illustrate the priority change\u2019s effect \non scheduling and throughput in our specific context.",
"title": "Output Analysis"
},
{
"location": "/os/tutorials/tasks_lesson/#efficiency-isnt-everything",
- "text": "Using the processor during every OS tick isn\u2019t always the best course of action. If we modify Task A\u2019s delay to a tenth of a millisecond and turn off the console output, we can boost our speedup to 1.44. This, however, reduces our ability to process work from Task B who ends up only completing 18% of its work cycle after the second simulation. That would mean, at that rate, Task B would take over a minute to finish one cycle. Feel free to play around with the testing parameters to study the different changes yourself!",
+ "text": "Using the processor during every OS tick isn\u2019t always the best course of action. If we modify \nTask A\u2019s delay to a tenth of a millisecond and turn off the console output, we can boost our \nspeedup to 1.44. This, however, reduces our ability to process work from Task B who ends up \nonly completing 18% of its work cycle after the second simulation. That would mean, at that \nrate, Task B would take over a minute to finish one cycle. Feel free to play around with the testing parameters to study the different changes yourself!",
"title": "Efficiency Isn\u2019t Everything"
},
{
"location": "/os/tutorials/tasks_lesson/#conclusion",
- "text": "Moving forward, tasks are just the tip of the iceberg. The scheduler , event queues , semaphores , and mutexes also add to tasks functionality, increasing our ability as the developer to control greater numbers of tasks more intricately. For example, when we switch the tasks priority, we have to tell the scheduler that our tasks priorities have changed, allowing us us to use priorities dynamically. When running multiple tasks, logging through either the built-in Logs module (not covered in this lesson) or through the serial console/shell can be very useful for debugging your application. In the end, the way you manage your tasks depends on the context of your application. You should assign priorities based on execution time, urgency, and frequency, among other things. Keep blinking and happy hacking!",
+ "text": "Moving forward, tasks are just the tip of the iceberg. The scheduler , event queues , semaphores , and mutexes also add to tasks functionality, \nincreasing our ability as the developer to control greater numbers of tasks more intricately. For \nexample, when we switch the tasks priority, we have to tell the scheduler that our tasks priorities \nhave changed, allowing us us to use priorities dynamically. When running multiple tasks, logging \nthrough either the built-in Logs module \n(not covered in this lesson) or through the serial console/shell can be very useful for debugging \nyour application. In the end, the way you manage your tasks depends on the context of your \napplication. You should assign priorities based on execution time, urgency, and frequency, among \nother things. Keep blinking and happy hacking!",
"title": "Conclusion"
},
{
"location": "/os/tutorials/wi-fi_on_arduino/",
- "text": "Start Wi-Fi on Arduino Zero\n\n\nThis tutorial walks you through the steps to get your Arduino board on a Wi-Fi network.\n\n\nNote:\n Wi-Fi support is currently available in the \ndevelop\n branch of Mynewt only. It will be merged into \nmaster\n branch when version 0.10 is released.\n\n\nPrerequisites\n\n\nBefore tackling this tutorial, it's best to read about Mynewt in the \nIntroduction\n section of this documentation.\n\n\nEquipment\n\n\nYou will need the following equipment\n\n\n\n\nAn Arduino Zero, Zero Pro or M0 Pro.\n\n\nNote:\n Mynewt has not been tested on Arduino M0 which has no internal debugger support.\n\n\nAn Arduino Wi-Fi Shield 101\n\n\nA computer that can connect to the Arduino board over USB\n\n\nA local Wi-Fi network that the computer is connected to and which the Arduino board can join.\n\n\nA USB cable (Type A to micro B) that can connect the computer to the Arduino (or a USB hub between the computer and the Arduino board)\n\n\nThe Mynewt R
elease\n\n\n\n\nInstall Mynewt and Newt\n\n\n\n\nIf you have not already done so, install Newt as shown in the \nNewt install tutorial\n.\n\n\nIf you installed Newt previously but need to update it, go to the newt git repo directory, pull the latest code from \ndevelop\n branch, and install the updated code.\n\n\n\n\n user@~/dev$ cd $GOPATH/src/mynewt.apache.org/newt\n user@~/dev/go/src/mynewt.apache.org/newt$ git remote -v\n origin https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git (fetch)\n origin https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git (push)\n user@~/dev/go/src/mynewt.apache.org/newt$ git pull origin develop\n remote: Counting objects: 59, done.\n \nsnip\n\n user@~/dev/go/src/mynewt.apache.org/newt$ cd newt\n user@~/dev/go/src/mynewt.apache.org/newt/newt$ go install\n user@~/dev$ cd ~/dev\n\n\n\n\n\n\n\nIf you have not already done so, create a project as shown in the Quick Start guide on how to \nCreate Your First
Project\n. Skip the testing and building the project steps in that tutorial since you will be defining a target for your Arduino board in this tutorial.\n\n\n\n\nLet's say your new project is named \narduinowifi\n. You will henceforth be working in that project directory.\n\n\n\n\nFetch External Packages, Set correct version to download\n\n\nMynewt uses source code provided directly from the chip manufacturer for\nlow level operations. Sometimes this code is licensed only for the specific manufacturer of the chipset and cannot live in the Apache Mynewt repository. That happens to be the case for the Arduino Zero board which uses Atmel SAMD21. Runtime's github repository hosts such external third-party packages and the Newt tool can fetch them.\n\n\nTo fetch the package with MCU support for Atmel SAMD21 for Arduino Zero from the Runtime git repository, you need to add\nthe repository to the \nproject.yml\n file in your base project directory (\narduinowifi\n).\n\n\nuser@~/dev/arduin
owifi$ vi project.yml\n\n\n\n\n\nHere is an example \nproject.yml\n file with the Arduino Zero repository\nadded. The sections with \nmynewt_arduino_zero\n that need to be added to\nyour project file are highlighted.\n\n\nAlso highlighted is the \n0-dev\n version for both the repositories to ensure code is downloaded from the \ndevelop\n branch.\n\n\n$ more project.yml\nproject.name: \nmy_project\n\n\nproject.repositories:\n - apache-mynewt-core\n\n - mynewt_arduino_zero\n\n\nrepository.apache-mynewt-core:\n type: github\n\n vers: 0-dev\n\n user: apache\n repo: incubator-mynewt-core\n\n\nrepository.mynewt_arduino_zero:\n\n type: github\n\n vers: 0-dev\n\n user: runtimeinc\n\n repo: mynewt_arduino_zero\n\n$\n\n\n\n\n\n\n\nOnce you've edited your \nproject.yml\n file, the next step is to install the\nproject dependencies, this can be done with the \nnewt install\n command\n(to see more output, provide the \n-v\n verbose option.):\n\n\n$ newt install\napac
he-mynewt-core\nmynewt_arduino_zero\n$\n\n\n\n\n\n\n\nCreate your bootloader target\n\n\nNext, you need to tell Newt what to build. For the Arduino Zero, we are going to\ngenerate both a bootloader, and an image target.\n\n\nTo generate the bootloader target, you need to specify the following options. The output of the commands (indicating success) have been suppressed for easier readability.\n\n\n$ newt target create arduino_boot\n$ newt target set arduino_boot bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero\n$ newt target set arduino_boot app=@apache-mynewt-core/apps/boot\n$ newt target set arduino_boot build_profile=optimized\n\n\n\n\n\n\n\nIf you have an Arduino Zero Pro or M0 Pro, you have to set the following next:\n\n\n$ newt target set arduino_boot features=arduino_zero_pro\n\n\n\n\n\nIf you have an Arduino Zero, you have to set the following instead:\n\n\n$ newt target set arduino_boot features=arduino_zero\n\n\n\n\n\n\n\nBuild your bootloader\n\n\nOnce you've configured the
bootloader target, the next step is to build the bootloader for your Arduino. You can do this by using the \nnewt build\n command:\n\n\n$ newt build arduino_boot\nCompiling boot.c\nArchiving boot.a\nCompiling fs_cli.c\nCompiling fs_dirent.c\nCompiling fs_file.c\nCompiling fs_mkdir.c\n\nsnip\n\nApp successfully built: ~/dev/arduinowifi/bin/arduino_boot/apps/boot/boot.elf\n\n\n\n\n\nIf this command finishes successfully, you have successfully built the Arduino\nbootloader, and the next step is to build your application for the Arduino\nboard.\n\n\n\n\nBuild your blinky app\n\n\nTo create and download your application, you create another target, this one pointing to the application you want to download to the Arduino board. In this tutorial, we will use the Wi-Fi application that comes in the arduino repository, \napps/winc1500_wifi\n:\n\n\nNote\n: Remember to set features to \narduino_zero\n if your board is Arduino Zero and not a Pro!\n\n\n$ newt target create arduino_wifi\n$ newt
target set arduino_wifi app=@mynewt_arduino_zero/apps/winc1500_wifi\n$ newt target set arduino_wifi bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero\n$ newt target set arduino_wifi build_profile=debug\n\n$ newt target set arduino_wifi features=arduino_zero_pro\n\n\n\n\n\n\n\nYou can now build the target, with \nnewt build\n:\n\n\n$ newt build arduino_wifi\nBuilding target targets/arduino_wifi\nCompiling main.c\nArchiving winc1500_wifi.a\nCompiling fs_cli.c\nCompiling fs_dirent.c\nCompiling fs_file.c\nCompiling fs_mkdir.c\n\nsnip\n\nLinking winc1500_wifi.elf\nApp successfully built: ~/dev/arduinowifi/bin/arduino_wifi/apps/winc1500_wifi/winc1500_wifi.elf\n\n\n\n\n\n Congratulations! \n You have successfully built your Wi-Fi application. Now it's time to load both the bootloader and application onto the target.\n\n\n\n\nC
<TRUNCATED>
[7/7] incubator-mynewt-site git commit: Updated events. Updated event
queue documentation. This closes #126
Posted by ad...@apache.org.
Updated events. Updated event queue documentation. This closes #126
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/db7dea53
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/db7dea53
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/db7dea53
Branch: refs/heads/asf-site
Commit: db7dea53a1cf66079cc88631d04d85ca27d09897
Parents: 0e97d5b
Author: aditihilbert <ad...@runtime.io>
Authored: Thu Nov 17 17:14:25 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Thu Nov 17 17:14:25 2016 -0800
----------------------------------------------------------------------
develop/events/index.html | 16 +-
develop/mkdocs/search_index.json | 196 +++--
.../core_os/event_queue/event_queue/index.html | 99 ++-
.../event_queue/os_eventq_dflt_get/index.html | 807 ++++++++++++++++++
.../event_queue/os_eventq_dflt_set/index.html | 821 ++++++++++++++++++
.../event_queue/os_eventq_get/index.html | 42 +-
.../event_queue/os_eventq_init/index.html | 42 +-
.../event_queue/os_eventq_inited/index.html | 823 +++++++++++++++++++
.../event_queue/os_eventq_put/index.html | 36 +-
.../event_queue/os_eventq_remove/index.html | 36 +-
.../os/core_os/semaphore/semaphore/index.html | 4 +-
.../os/tutorials/repo/create_repo/index.html | 2 +-
develop/os/tutorials/tasks_lesson/index.html | 153 +++-
.../os/tutorials/wi-fi_on_arduino/index.html | 2 +-
develop/sitemap.xml | 26 +-
events/index.html | 16 +-
latest/events/index.html | 16 +-
latest/mkdocs/search_index.json | 196 +++--
.../core_os/event_queue/event_queue/index.html | 99 ++-
.../event_queue/os_eventq_dflt_get/index.html | 807 ++++++++++++++++++
.../event_queue/os_eventq_dflt_set/index.html | 821 ++++++++++++++++++
.../event_queue/os_eventq_get/index.html | 42 +-
.../event_queue/os_eventq_init/index.html | 42 +-
.../event_queue/os_eventq_inited/index.html | 823 +++++++++++++++++++
.../event_queue/os_eventq_put/index.html | 36 +-
.../event_queue/os_eventq_remove/index.html | 36 +-
.../os/core_os/semaphore/semaphore/index.html | 4 +-
latest/os/tutorials/repo/create_repo/index.html | 2 +-
latest/os/tutorials/tasks_lesson/index.html | 153 +++-
latest/os/tutorials/wi-fi_on_arduino/index.html | 2 +-
latest/sitemap.xml | 26 +-
sitemap.xml | 26 +-
v0_9_0/events/index.html | 16 +-
v0_9_0/sitemap.xml | 26 +-
34 files changed, 5924 insertions(+), 370 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/develop/events/index.html
----------------------------------------------------------------------
diff --git a/develop/events/index.html b/develop/events/index.html
index 97aa3d0..ae2da31 100644
--- a/develop/events/index.html
+++ b/develop/events/index.html
@@ -144,17 +144,17 @@
<div class="event">
- <h2>Linaro Connect - Keynote Presentation</h2>
- <p>Time: 16:10 - 16:45, Date: 26 September 2016, 2016</p>
- <p>Grand Ballroom C, JW Marriott Resort and Spa Hotel, Las Vegas, NV</p>
- <p>LAS16-104: Mynewt Technical Overview. Apache Mynewt developers will be available until September 28th to meet and discuss Mynewt OS and associated Newt tool.</p>
+ <h2>CES</h2>
+ <p>5-8 January, 2017</p>
+ <p>Las Vegas, NV</p>
+ <p>Contact runtime.io or email us at dev@mynewt.incubator.apache.org to check out and discuss Apache Mynewt and its many uses.</p>
</div>
<div class="event">
- <h2>ARM TechCon</h2>
- <p>25-27 October, 2016</p>
- <p>Santa Clara Convention Center, Santa Clara, CA, USA</p>
- <p>See Apache Mynewt in action in Booth #805. Watch it enable a variety of functionalities on different boards!</p>
+ <h2>Embedded Systems Conference</h2>
+ <p>6-8 December, 2016</p>
+ <p>San Jose Convention Center, San Jose, CA, USA</p>
+ <p>Meet up to discuss Apache Mynewt.</p>
</div>
</div>
[2/7] incubator-mynewt-site git commit: Updated events. Updated event
queue documentation. This closes #126
Posted by ad...@apache.org.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/latest/os/core_os/event_queue/event_queue/index.html
----------------------------------------------------------------------
diff --git a/latest/os/core_os/event_queue/event_queue/index.html b/latest/os/core_os/event_queue/event_queue/index.html
index 319efa0..0f5f38b 100644
--- a/latest/os/core_os/event_queue/event_queue/index.html
+++ b/latest/os/core_os/event_queue/event_queue/index.html
@@ -306,7 +306,7 @@
<li><a href="
- ../os_eventq_get/
+ ../os_eventq_init/
">Functions</a>
@@ -661,21 +661,25 @@
</div>
<h1 id="event-queues">Event Queues</h1>
-<p>Event queue is a way of serializing events arring to a task. This makes it easy to queue processing to happen inside task's context. This would be done either from an interrupt handler, or from another task.</p>
-<p>Events arrive in a form of a data structure <code>struct os_event</code>.</p>
+<p>Event queue is a way for a task to serialize events sent to it. This makes it easy to process events required to happen inside the task's context. Events may arrive either from an interrupt handler, or from another task.</p>
<h3 id="description">Description</h3>
-<p>Events are in form of a data structure <code>struct os_event</code>, and they are queued to data structure <code>struct os_eventq</code>.</p>
-<p>Queue must be initialized before trying to add events to it. This is done using <code>os_eventq_init()</code>.</p>
-<p>Common way of using event queues is to have a task loop while calling <code>os_eventq_get()</code>, waiting for work to do.
-Other tasks (or interrupts) then call <code>os_eventq_put()</code> to wake it up. Once event has been queued task waiting on that queue is woken up, and will get a pointer to queued event structure.
-Processing task would then act according to event type.</p>
+<p>Events arrive in form the of a data structure <code>struct os_event</code> and
+they are queued to another data structure <code>struct os_eventq</code>.</p>
+<p>The Event Queue must be initialized before trying to add events to
+it. This is done using <code>os_eventq_init()</code>.</p>
+<p>A common way of using event queues is to have a task loop while calling <code>os_eventq_get()</code>,
+waiting for work to do. Other tasks (or interrupts) then call <code>os_eventq_put()</code>
+to wake it up. Once an event has been queued, the task waiting on that queue is woken up. The event dispatching logic is built into each event via a callback function pointer. The task handler can simply pull events
+off the queue and call its callback handler. The processing task would then act according to the event type. </p>
<p>When <code>os_event</code> is queued, it should not be freed until processing task is done with it.</p>
<p>It is assumed that there is only one task consuming events from an event queue. Only one task should be sleeping on a particular <code>os_eventq</code> at a time.</p>
<p>Note that <a href="../../callout/callout/">os_callout</a> subsystem assumes that event queue is used as the wakeup mechanism.</p>
<h3 id="data-structures">Data structures</h3>
-<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">struct</span> <span style="color: #000000">os_event</span> {
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">typedef</span> <span style="color: #A90D91">void</span> <span style="color: #000000">os_event_fn</span>(<span style="color: #A90D91">struct</span> <span style="color: #000000">os_event</span> <span style="color: #000000">*ev</span>);
+
+<span style="color: #A90D91">struct</span> <span style="color: #000000">os_event</span> {
<span style="color: #A90D91">uint8_t</span> <span style="color: #000000">ev_queued</span>;
- <span style="color: #A90D91">uint8_t</span> <span style="color: #000000">ev_type</span>;
+ <span style="color: #000000">os_event_fn</span> <span style="color: #000000">*ev_cb</span>;
<span style="color: #A90D91">void</span> <span style="color: #000000">*ev_arg</span>;
<span style="color: #000000">STAILQ_ENTRY</span>(<span style="color: #000000">os_event</span>) <span style="color: #000000">ev_next</span>;
};
@@ -691,23 +695,56 @@ Processing task would then act according to event type.</p>
</thead>
<tbody>
<tr>
-<td>ev_queued</td>
+<td><code>ev_queued</code></td>
<td>Internal field, which tells whether event is linked into an <em>os_eventq</em> already</td>
</tr>
<tr>
-<td>ev_type</td>
-<td>Type of an event. This should be unique, as it should be used by processing task to figure out what the event means</td>
+<td><code>ev_cb</code></td>
+<td>A callback function pointer that is called when a new event arrives on the queue</td>
</tr>
<tr>
-<td>ev_arg</td>
+<td><code>ev_arg</code></td>
<td>Can be used further as input to task processing this event</td>
</tr>
<tr>
-<td>ev_next</td>
+<td><code>ev_next</code></td>
<td>Linkage attaching this event to an event queue</td>
</tr>
</tbody>
</table>
+<p>With the callback function pointer, the dispatch logic gets built into each event. The task handler simply pulls an event off its queue and blindly calls its callback function. A helper function was added to do just this:
+<code>os_eventq_run()</code>. As an example, the task handler for the bleprph application is below:</p>
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">static</span> <span style="color: #A90D91">void</span>
+<span style="color: #000000">bleprph_task_handler</span>(<span style="color: #A90D91">void</span> <span style="color: #000000">*unused</span>)
+{
+ <span style="color: #A90D91">while</span> (<span style="color: #1C01CE">1</span>) {
+ <span style="color: #000000">os_eventq_run</span>(<span style="color: #000000">&bleprph_evq</span>);
+ }
+}
+</pre></div>
+
+
+<p>The callback associated with an event is specified when the event gets
+initialized. For example, here are some statically-initialized events
+in the NimBLE host:</p>
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">static</span> <span style="color: #A90D91">void</span> <span style="color: #000000">ble_hs_event_tx_notify</span>(<span style="color: #A90D91">struct</span> <span style="color: #000000">os_event</span> <span style="color: #000000">*ev</span>);
+<span style="color: #A90D91">static</span> <span style="color: #A90D91">void</span> <span style="color: #000000">ble_hs_event_reset</span>(<span style="color: #A90D91">struct</span> <span style="color: #000000">os_event</span> <span style="color: #000000">*ev</span>);
+
+<span style="color: #177500">/** OS event - triggers tx of pending notifications and indications. */</span>
+<span style="color: #A90D91">static</span> <span style="color: #A90D91">struct</span> <span style="color: #000000">os_event</span> <span style="color: #000000">ble_hs_ev_tx_notifications</span> <span style="color: #000000">=</span> {
+ .<span style="color: #000000">ev_cb</span> <span style="color: #000000">=</span> <span style="color: #000000">ble_hs_event_tx_notify</span>,
+};
+
+<span style="color: #177500">/** OS event - triggers a full reset. */</span>
+<span style="color: #A90D91">static</span> <span style="color: #A90D91">struct</span> <span style="color: #000000">os_event</span> <span style="color: #000000">ble_hs_ev_reset</span> <span style="color: #000000">=</span> {
+ .<span style="color: #000000">ev_cb</span> <span style="color: #000000">=</span> <span style="color: #000000">ble_hs_event_reset</span>,
+};
+</pre></div>
+
+
+<p>The callback function receives a single parameter: a
+pointer to the event being processed. If the event is allocated
+dynamically, the callback function should free the event. </p>
<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">struct</span> <span style="color: #000000">os_eventq</span> {
<span style="color: #A90D91">struct</span> <span style="color: #000000">os_task</span> <span style="color: #000000">*evq_task</span>;
<span style="color: #000000">STAILQ_HEAD</span>(, <span style="color: #000000">os_event</span>) <span style="color: #000000">evq_list</span>;
@@ -724,11 +761,11 @@ Processing task would then act according to event type.</p>
</thead>
<tbody>
<tr>
-<td>evq_task</td>
+<td><code>evq_task</code></td>
<td>Pointer to task if there is task sleeping on <em>os_eventq_get()</em></td>
</tr>
<tr>
-<td>evq_list</td>
+<td><code>evq_list</code></td>
<td>Queue head for list of events in this queue</td>
</tr>
</tbody>
@@ -744,21 +781,33 @@ Processing task would then act according to event type.</p>
</thead>
<tbody>
<tr>
-<td><a href="../os_eventq_get/">os_eventq_get</a></td>
-<td>Fetches the first event from a queue. Task will sleep until something gets queued.</td>
+<td><a href="../os_eventq_init/"><code>os_eventq_init</code></a></td>
+<td>Initializes the given event queue, making it ready for use.</td>
</tr>
<tr>
-<td><a href="../os_eventq_init/">os_eventq_init</a></td>
-<td>Initializes the given event queue, making it ready for use.</td>
+<td><a href="../os_eventq_inited/"><code>os_eventq_inited</code></a></td>
+<td>Has the event queue been initialized.</td>
+</tr>
+<tr>
+<td><a href="../os_eventq_get/"><code>os_eventq_get</code></a></td>
+<td>Fetches the first event from a queue. Task will sleep until something gets queued.</td>
</tr>
<tr>
-<td><a href="../os_eventq_put/">os_eventq_put</a></td>
+<td><a href="../os_eventq_put/"><code>os_eventq_put</code></a></td>
<td>Queues an event to tail of the event queue.</td>
</tr>
<tr>
-<td><a href="../os_eventq_remove/">os_eventq_remove</a></td>
+<td><a href="../os_eventq_remove/"><code>os_eventq_remove</code></a></td>
<td>Removes an event which has been placed in a queue.</td>
</tr>
+<tr>
+<td><a href="../os_eventq_dflt_set/"><code>os_eventq_dflt_set</code></a></td>
+<td>Set the default event queue.</td>
+</tr>
+<tr>
+<td><a href="../os_eventq_dflt_get/"><code>os_eventq_dflt_get</code></a></td>
+<td>Get the default event queue.</td>
+</tr>
</tbody>
</table>
@@ -778,8 +827,8 @@ Processing task would then act according to event type.</p>
</li>
<li class="pull-right">
- <a href=../os_eventq_get/>
- Next: os_eventq_get
+ <a href=../os_eventq_init/>
+ Next: os_eventq_init
<span class="fa fa-arrow-right"></span>
</a>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/latest/os/core_os/event_queue/os_eventq_dflt_get/index.html
----------------------------------------------------------------------
diff --git a/latest/os/core_os/event_queue/os_eventq_dflt_get/index.html b/latest/os/core_os/event_queue/os_eventq_dflt_get/index.html
new file mode 100644
index 0000000..e0f653a
--- /dev/null
+++ b/latest/os/core_os/event_queue/os_eventq_dflt_get/index.html
@@ -0,0 +1,807 @@
+<!DOCTYPE html>
+<html lang="en">
+ <head>
+ <meta charset="utf-8">
+ <meta http-equiv="X-UA-Compatible" content="IE=edge">
+ <meta name="viewport" content="width=device-width, initial-scale=1.0">
+
+
+ <!-- This is broken by doc revisioning.
+ <link rel="canonical" href="http://mynewt.apache.org/os/core_os/event_queue/os_eventq_dflt_get/"> -->
+ <link rel="shortcut icon" href="../../../../img/favicon.ico">
+
+ <title>os_eventq_dflt_get - Apache Mynewt</title>
+
+ <link href="../../../../css/bootstrap-3.0.3.min.css" rel="stylesheet">
+ <link rel="stylesheet" href="../../../../css/highlight.css">
+ <link href="../../../../css/base.css" rel="stylesheet">
+ <link href="../../../../css/custom.css" rel="stylesheet">
+ <link href="../../../../css/v2.css" rel="stylesheet">
+ <link href="https://fonts.googleapis.com/css?family=Lato" rel="stylesheet">
+ <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css">
+ <link href="../../../../extra.css" rel="stylesheet">
+
+ <!-- HTML5 shim and Respond.js IE8 support of HTML5 elements and media queries -->
+ <!--[if lt IE 9]>
+ <script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
+ <script src="https://oss.maxcdn.com/libs/respond.js/1.3.0/respond.min.js"></script>
+ <![endif]-->
+
+
+ <script>
+ (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+ m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+ })(window,document,'script','//www.google-analytics.com/analytics.js','ga');
+
+ ga('create', 'UA-72162311-1', 'auto');
+ ga('send', 'pageview');
+ </script>
+
+ </head>
+
+
+ <body class="os_eventq_dflt_get">
+
+
+ <div class="container">
+ <div class="row v2-main-banner">
+ <div class="col-xs-12 v2-vcenter">
+ <a href="/"><img class="logo" src="/img/logo.png"></a>
+
+ <h4 class="tagline">An OS to build, deploy and securely manage billions of devices</h4>
+ </div>
+ </div>
+</div>
+
+
+
+
+
+
+
+
+<nav id="navbar" class="navbar navbar-inverse affix-top" data-spy="affix" data-offset-top="150" role="navigation">
+ <div class="container">
+ <!-- Collapsed navigation -->
+ <div class="navbar-header">
+ <!-- Expander button -->
+ <button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse">
+ <span class="sr-only">Toggle navigation</span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ </button>
+
+ </div>
+
+ <!-- Expanded navigation -->
+ <div class="navbar-collapse collapse">
+ <!-- Main navigation -->
+ <ul class="nav navbar-nav navbar-right">
+ <li
+ class=""
+>
+ <a href="/"><i class="fa fa-home" style="font-size: larger;"></i></a>
+ </li>
+ <li
+ class="important"
+>
+ <a href="/quick-start/">Quick Start</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/about/">About</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/talks/">Talks</a>
+ </li>
+ <li
+ class="active"
+>
+ <a href="/latest/os/introduction">Documentation</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/download/">Download</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/community/">Community</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/events/">Events</a>
+ </li>
+ </ul>
+
+ <!-- Search, Navigation and Repo links -->
+ <ul class="nav navbar-nav navbar-right">
+
+ </ul>
+ </div>
+ </div>
+</nav>
+
+
+
+ <div class="container">
+
+ <div class="row">
+ <div class="col-md-3 v2-sidebar sidebar-container"><div id="docSidebar" class="hidden-print" role="complementary">
+ <div class="top">
+ <div role="search">
+ <form id="rtd-search-form" class="wy-form" action="../../../../search.html" method="get">
+ <div class="form-group">
+ <input type="text" name="q" class="form-control" placeholder="Search documentation" />
+ </div>
+ </form>
+ </div>
+ </div>
+ <ul class="toc-nav">
+ <li class="doc-version">
+<select class="form-control" onchange="if (this.value) window.location.href=this.value">
+
+ <option
+ value="/develop/os/introduction"
+ selected="selected"
+ >
+ Version: develop (latest)
+ </option>
+
+ <option
+ value="/v0_9_0/os/introduction"
+
+ >
+ Version: 0.9.0
+ </option>
+
+</select>
+</li>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ <li ><a href="../../../introduction/">Mynewt Documentation</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li ><a href="../../../get_started/get_started/">Basic Setup</a>
+
+
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../../../get_started/vocabulary/">Concepts</a>
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../tutorials/tutorials/">Tutorials</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../os_user_guide/">OS User Guide</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li ><a href="../../mynewt_os/">OS Core</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li><a href="
+ ../../os_init/
+">System-level Functions</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../context_switch/context_switch/">Scheduler</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../time/os_time/">Time</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../task/task/">Tasks</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../event_queue/">Event Queues</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li><a href="
+ ../os_eventq_init/
+">Functions</a>
+
+
+ <ul>
+
+
+
+ <li >
+ <a href="../os_eventq_init/">os_eventq_init</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_inited/">os_eventq_inited</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_get/">os_eventq_get</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_put/">os_eventq_put</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_remove/">os_eventq_remove</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_dflt_set/">os_eventq_dflt_set</a>
+ </li>
+
+
+
+
+
+ <li class="active">
+ <a href="./">os_eventq_dflt_get</a>
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../semaphore/semaphore/">Semaphores</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../mutex/mutex/">Mutexes</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../memory_pool/memory_pool/">Memory Pools</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../heap/heap/">Heap</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+
+
+ ../../mbuf/mbuf/
+
+">Memory Buffers</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../sanity/sanity/">Sanity</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../callout/callout/">Callouts</a>
+
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../porting/port_os/">Porting to your Platform</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/console/console/">Console</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/shell/shell/">Shell</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/split/split/">Split Images</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/bootloader/bootloader/">Bootloader</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+
+
+ ../../../modules/fs/fs/fs/
+
+">File System</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/hal/hal/">Hardware Abstraction Layer</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/testutil/testutil/">Test Utilities</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/imgmgr/imgmgr/">Image Manager</a>
+
+
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../../../modules/baselibc/">Baselibc library</a>
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/elua/elua/">Embedded Lua</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/json/json/">JSON</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/fcb/fcb/">Flash Circular Buffer</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/stats/stats/">Stats</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/logs/logs/">Logs</a>
+
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+ ../../../../network/ble/ble_intro/
+">BLE User Guide</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../../newt/newt_intro/">Newt Tool Guide</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../../newtmgr/overview/">Newt Manager Guide</a>
+
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+ ../../../../faq/how_to_edit_docs/
+">Appendix</a>
+
+
+ </li>
+
+
+
+ </ul>
+</div></div>
+
+ <div class="col-md-9" role="main">
+ <div class="doc-header">
+ <div role="navigation" aria-label="breadcrumbs navigation">
+ <ul class="wy-breadcrumbs pull-right">
+ <li><a href="/latest/os/introduction">Docs</a></li>
+
+
+
+ <li>» <a href="../event_queue/">Event Queues</a></li>
+
+
+
+ <li>» <a href="../os_eventq_init/">Functions</a></li>
+
+
+
+ <li>» os_eventq_dflt_get</li>
+
+
+
+ </ul>
+</div>
+ </div>
+
+ <h2 id="os_eventq_dflt_get"><font color="F2853F" style="font-size:24pt"> os_eventq_dflt_get</font></h2>
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"> <span style="color: #A90D91">struct</span> <span style="color: #000000">os_eventq</span>
+ <span style="color: #000000">*os_eventq_dflt_get</span>(<span style="color: #A90D91">void</span>)
+</pre></div>
+
+
+<p>Get the default event queue that was set</p>
+<h4 id="arguments">Arguments</h4>
+<p>None</p>
+<h4 id="returned-values">Returned values</h4>
+<p><code>struct os_eventq *</code> A pointer to the default event queue, if set. </p>
+<h4 id="notes">Notes</h4>
+<p>None</p>
+<h4 id="example">Example</h4>
+<p><Add text to set up the context for the example here>
+This checks the default event queue and sets it if not already set.</p>
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">struct</span> <span style="color: #000000">os_eventq</span> <span style="color: #000000">g_my_evq</span>;
+
+<span style="color: #A90D91">int</span>
+<span style="color: #000000">event_q_check</span>()
+{
+ <span style="color: #A90D91">if</span>(<span style="color: #000000">os_eventq_dflt_get</span>() <span style="color: #000000">==</span> <span style="color: #A90D91">NULL</span>)
+ {
+ <span style="color: #000000">os_eventq_dflt_set</span>(<span style="color: #000000">g_my_evq</span>);
+ }
+
+}
+</pre></div>
+
+ <div class="row">
+
+
+
+
+<ul class="nav nav-pills" style="margin-bottom: 10px">
+ <li>
+
+ <a href=../os_eventq_dflt_set/>
+ <span class="fa fa-arrow-left"></span>
+ Previous: os_eventq_dflt_set
+ </a>
+
+ </li>
+ <li class="pull-right">
+
+ <a href=../../semaphore/semaphore/>
+ Next: Semaphores
+ <span class="fa fa-arrow-right"></span>
+ </a>
+
+ </li>
+</ul>
+ </div>
+ <footer class="row">
+ <div class="col-xs-12">
+
+ <p class="copyright">Copyright © 2015 The Apache Software Foundation, Licensed under the Apache License, Version 2.0 Apache and the Apache feather logo are trademarks of The Apache Software Foundation.</p>
+
+ </div>
+ <div class="col-xs-12">
+ <div class="logos">
+ <img src="/img/asf_logo_wide_small.png" alt="Apache" title="Apache">
+ <small class="footnote">
+ MyNewt is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the Apache Incubator. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+ </small>
+ <img src="/img/egg-logo2.png" alt="Apache Incubator" title="Apache Incubator">
+ </div>
+ </div>
+</footer>
+ </div>
+ </div>
+
+
+ </div>
+
+ <script src="../../../../js/jquery-1.10.2.min.js"></script>
+ <script src="../../../../js/bootstrap-3.0.3.min.js"></script>
+ <script src="../../../../js/highlight.pack.js"></script>
+ <script src="../../../../js/base.js"></script>
+ <script src="../../../../js/custom.js"></script>
+
+ </body>
+</html>
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/latest/os/core_os/event_queue/os_eventq_dflt_set/index.html
----------------------------------------------------------------------
diff --git a/latest/os/core_os/event_queue/os_eventq_dflt_set/index.html b/latest/os/core_os/event_queue/os_eventq_dflt_set/index.html
new file mode 100644
index 0000000..daab29b
--- /dev/null
+++ b/latest/os/core_os/event_queue/os_eventq_dflt_set/index.html
@@ -0,0 +1,821 @@
+<!DOCTYPE html>
+<html lang="en">
+ <head>
+ <meta charset="utf-8">
+ <meta http-equiv="X-UA-Compatible" content="IE=edge">
+ <meta name="viewport" content="width=device-width, initial-scale=1.0">
+
+
+ <!-- This is broken by doc revisioning.
+ <link rel="canonical" href="http://mynewt.apache.org/os/core_os/event_queue/os_eventq_dflt_set/"> -->
+ <link rel="shortcut icon" href="../../../../img/favicon.ico">
+
+ <title>os_eventq_dflt_set - Apache Mynewt</title>
+
+ <link href="../../../../css/bootstrap-3.0.3.min.css" rel="stylesheet">
+ <link rel="stylesheet" href="../../../../css/highlight.css">
+ <link href="../../../../css/base.css" rel="stylesheet">
+ <link href="../../../../css/custom.css" rel="stylesheet">
+ <link href="../../../../css/v2.css" rel="stylesheet">
+ <link href="https://fonts.googleapis.com/css?family=Lato" rel="stylesheet">
+ <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css">
+ <link href="../../../../extra.css" rel="stylesheet">
+
+ <!-- HTML5 shim and Respond.js IE8 support of HTML5 elements and media queries -->
+ <!--[if lt IE 9]>
+ <script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
+ <script src="https://oss.maxcdn.com/libs/respond.js/1.3.0/respond.min.js"></script>
+ <![endif]-->
+
+
+ <script>
+ (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+ m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+ })(window,document,'script','//www.google-analytics.com/analytics.js','ga');
+
+ ga('create', 'UA-72162311-1', 'auto');
+ ga('send', 'pageview');
+ </script>
+
+ </head>
+
+
+ <body class="os_eventq_dflt_set">
+
+
+ <div class="container">
+ <div class="row v2-main-banner">
+ <div class="col-xs-12 v2-vcenter">
+ <a href="/"><img class="logo" src="/img/logo.png"></a>
+
+ <h4 class="tagline">An OS to build, deploy and securely manage billions of devices</h4>
+ </div>
+ </div>
+</div>
+
+
+
+
+
+
+
+
+<nav id="navbar" class="navbar navbar-inverse affix-top" data-spy="affix" data-offset-top="150" role="navigation">
+ <div class="container">
+ <!-- Collapsed navigation -->
+ <div class="navbar-header">
+ <!-- Expander button -->
+ <button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse">
+ <span class="sr-only">Toggle navigation</span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ </button>
+
+ </div>
+
+ <!-- Expanded navigation -->
+ <div class="navbar-collapse collapse">
+ <!-- Main navigation -->
+ <ul class="nav navbar-nav navbar-right">
+ <li
+ class=""
+>
+ <a href="/"><i class="fa fa-home" style="font-size: larger;"></i></a>
+ </li>
+ <li
+ class="important"
+>
+ <a href="/quick-start/">Quick Start</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/about/">About</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/talks/">Talks</a>
+ </li>
+ <li
+ class="active"
+>
+ <a href="/latest/os/introduction">Documentation</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/download/">Download</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/community/">Community</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/events/">Events</a>
+ </li>
+ </ul>
+
+ <!-- Search, Navigation and Repo links -->
+ <ul class="nav navbar-nav navbar-right">
+
+ </ul>
+ </div>
+ </div>
+</nav>
+
+
+
+ <div class="container">
+
+ <div class="row">
+ <div class="col-md-3 v2-sidebar sidebar-container"><div id="docSidebar" class="hidden-print" role="complementary">
+ <div class="top">
+ <div role="search">
+ <form id="rtd-search-form" class="wy-form" action="../../../../search.html" method="get">
+ <div class="form-group">
+ <input type="text" name="q" class="form-control" placeholder="Search documentation" />
+ </div>
+ </form>
+ </div>
+ </div>
+ <ul class="toc-nav">
+ <li class="doc-version">
+<select class="form-control" onchange="if (this.value) window.location.href=this.value">
+
+ <option
+ value="/develop/os/introduction"
+ selected="selected"
+ >
+ Version: develop (latest)
+ </option>
+
+ <option
+ value="/v0_9_0/os/introduction"
+
+ >
+ Version: 0.9.0
+ </option>
+
+</select>
+</li>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ <li ><a href="../../../introduction/">Mynewt Documentation</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li ><a href="../../../get_started/get_started/">Basic Setup</a>
+
+
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../../../get_started/vocabulary/">Concepts</a>
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../tutorials/tutorials/">Tutorials</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../os_user_guide/">OS User Guide</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li ><a href="../../mynewt_os/">OS Core</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li><a href="
+ ../../os_init/
+">System-level Functions</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../context_switch/context_switch/">Scheduler</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../time/os_time/">Time</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../task/task/">Tasks</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../event_queue/">Event Queues</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li><a href="
+ ../os_eventq_init/
+">Functions</a>
+
+
+ <ul>
+
+
+
+ <li >
+ <a href="../os_eventq_init/">os_eventq_init</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_inited/">os_eventq_inited</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_get/">os_eventq_get</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_put/">os_eventq_put</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_remove/">os_eventq_remove</a>
+ </li>
+
+
+
+
+
+ <li class="active">
+ <a href="./">os_eventq_dflt_set</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_dflt_get/">os_eventq_dflt_get</a>
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../semaphore/semaphore/">Semaphores</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../mutex/mutex/">Mutexes</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../memory_pool/memory_pool/">Memory Pools</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../heap/heap/">Heap</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+
+
+ ../../mbuf/mbuf/
+
+">Memory Buffers</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../sanity/sanity/">Sanity</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../callout/callout/">Callouts</a>
+
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../porting/port_os/">Porting to your Platform</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/console/console/">Console</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/shell/shell/">Shell</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/split/split/">Split Images</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/bootloader/bootloader/">Bootloader</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+
+
+ ../../../modules/fs/fs/fs/
+
+">File System</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/hal/hal/">Hardware Abstraction Layer</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/testutil/testutil/">Test Utilities</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/imgmgr/imgmgr/">Image Manager</a>
+
+
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../../../modules/baselibc/">Baselibc library</a>
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/elua/elua/">Embedded Lua</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/json/json/">JSON</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/fcb/fcb/">Flash Circular Buffer</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/stats/stats/">Stats</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/logs/logs/">Logs</a>
+
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+ ../../../../network/ble/ble_intro/
+">BLE User Guide</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../../newt/newt_intro/">Newt Tool Guide</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../../newtmgr/overview/">Newt Manager Guide</a>
+
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+ ../../../../faq/how_to_edit_docs/
+">Appendix</a>
+
+
+ </li>
+
+
+
+ </ul>
+</div></div>
+
+ <div class="col-md-9" role="main">
+ <div class="doc-header">
+ <div role="navigation" aria-label="breadcrumbs navigation">
+ <ul class="wy-breadcrumbs pull-right">
+ <li><a href="/latest/os/introduction">Docs</a></li>
+
+
+
+ <li>» <a href="../event_queue/">Event Queues</a></li>
+
+
+
+ <li>» <a href="../os_eventq_init/">Functions</a></li>
+
+
+
+ <li>» os_eventq_dflt_set</li>
+
+
+
+ </ul>
+</div>
+ </div>
+
+ <h2 id="os_eventq_dflt_set"><font color="F2853F" style="font-size:24pt"> os_eventq_dflt_set</font></h2>
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"> <span style="color: #A90D91">void</span>
+ <span style="color: #000000">os_eventq_dflt_set</span>(<span style="color: #A90D91">struct</span> <span style="color: #000000">os_eventq</span> <span style="color: #000000">*evq</span>)
+</pre></div>
+
+
+<p>Sets <code>struct os_eventq</code> as the default event queue</p>
+<h4 id="arguments">Arguments</h4>
+<table>
+<thead>
+<tr>
+<th>Arguments</th>
+<th>Description</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td><code>evq</code></td>
+<td>Pointer to default event queue to use</td>
+</tr>
+</tbody>
+</table>
+<h4 id="returned-values">Returned values</h4>
+<p>None</p>
+<h4 id="notes">Notes</h4>
+<p>Usually done at subsystem init time; before OS has been started, and before interrupts generating events have been enabled.</p>
+<h4 id="example">Example</h4>
+<p><Add text to set up the context for the example here>
+This sets the default event queue used by newtmgr task.</p>
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">struct</span> <span style="color: #000000">os_eventq</span> <span style="color: #000000">g_nmgr_evq</span>;
+
+<span style="color: #A90D91">int</span>
+<span style="color: #000000">nmgr_task_init</span>(<span style="color: #A90D91">uint8_t</span> <span style="color: #000000">prio</span>, <span style="color: #A90D91">os_stack_t</span> <span style="color: #000000">*stack_ptr</span>, <span style="color: #A90D91">uint16_t</span> <span style="color: #000000">stack_len</span>)
+{
+ <span style="color: #177500">/* variable declarations here */</span>
+
+ <span style="color: #000000">os_eventq_init</span>(<span style="color: #000000">&g_nmgr_evq</span>);
+ <span style="color: #000000">os_eventq_dflt_set</span>(<span style="color: #000000">&g_nmgr_evq</span>);
+
+ <span style="color: #177500">/* initialization continues here */</span>
+}
+</pre></div>
+
+ <div class="row">
+
+
+
+
+<ul class="nav nav-pills" style="margin-bottom: 10px">
+ <li>
+
+ <a href=../os_eventq_remove/>
+ <span class="fa fa-arrow-left"></span>
+ Previous: os_eventq_remove
+ </a>
+
+ </li>
+ <li class="pull-right">
+
+ <a href=../os_eventq_dflt_get/>
+ Next: os_eventq_dflt_get
+ <span class="fa fa-arrow-right"></span>
+ </a>
+
+ </li>
+</ul>
+ </div>
+ <footer class="row">
+ <div class="col-xs-12">
+
+ <p class="copyright">Copyright © 2015 The Apache Software Foundation, Licensed under the Apache License, Version 2.0 Apache and the Apache feather logo are trademarks of The Apache Software Foundation.</p>
+
+ </div>
+ <div class="col-xs-12">
+ <div class="logos">
+ <img src="/img/asf_logo_wide_small.png" alt="Apache" title="Apache">
+ <small class="footnote">
+ MyNewt is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the Apache Incubator. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+ </small>
+ <img src="/img/egg-logo2.png" alt="Apache Incubator" title="Apache Incubator">
+ </div>
+ </div>
+</footer>
+ </div>
+ </div>
+
+
+ </div>
+
+ <script src="../../../../js/jquery-1.10.2.min.js"></script>
+ <script src="../../../../js/bootstrap-3.0.3.min.js"></script>
+ <script src="../../../../js/highlight.pack.js"></script>
+ <script src="../../../../js/base.js"></script>
+ <script src="../../../../js/custom.js"></script>
+
+ </body>
+</html>
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/latest/os/core_os/event_queue/os_eventq_get/index.html
----------------------------------------------------------------------
diff --git a/latest/os/core_os/event_queue/os_eventq_get/index.html b/latest/os/core_os/event_queue/os_eventq_get/index.html
index afe00de..f0ff3de 100644
--- a/latest/os/core_os/event_queue/os_eventq_get/index.html
+++ b/latest/os/core_os/event_queue/os_eventq_get/index.html
@@ -306,7 +306,7 @@
<li><a href="
- ./
+ ../os_eventq_init/
">Functions</a>
@@ -314,8 +314,8 @@
- <li class="active">
- <a href="./">os_eventq_get</a>
+ <li >
+ <a href="../os_eventq_init/">os_eventq_init</a>
</li>
@@ -323,7 +323,15 @@
<li >
- <a href="../os_eventq_init/">os_eventq_init</a>
+ <a href="../os_eventq_inited/">os_eventq_inited</a>
+ </li>
+
+
+
+
+
+ <li class="active">
+ <a href="./">os_eventq_get</a>
</li>
@@ -344,6 +352,22 @@
+
+
+ <li >
+ <a href="../os_eventq_dflt_set/">os_eventq_dflt_set</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_dflt_get/">os_eventq_dflt_get</a>
+ </li>
+
+
+
</ul>
</li>
@@ -686,7 +710,7 @@
- <li>» Functions</li>
+ <li>» <a href="../os_eventq_init/">Functions</a></li>
@@ -742,16 +766,16 @@
<ul class="nav nav-pills" style="margin-bottom: 10px">
<li>
- <a href=../event_queue/>
+ <a href=../os_eventq_inited/>
<span class="fa fa-arrow-left"></span>
- Previous: Event Queues
+ Previous: os_eventq_inited
</a>
</li>
<li class="pull-right">
- <a href=../os_eventq_init/>
- Next: os_eventq_init
+ <a href=../os_eventq_put/>
+ Next: os_eventq_put
<span class="fa fa-arrow-right"></span>
</a>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/latest/os/core_os/event_queue/os_eventq_init/index.html
----------------------------------------------------------------------
diff --git a/latest/os/core_os/event_queue/os_eventq_init/index.html b/latest/os/core_os/event_queue/os_eventq_init/index.html
index 5bcc3cf..c2cedb1 100644
--- a/latest/os/core_os/event_queue/os_eventq_init/index.html
+++ b/latest/os/core_os/event_queue/os_eventq_init/index.html
@@ -306,7 +306,7 @@
<li><a href="
- ../os_eventq_get/
+ ./
">Functions</a>
@@ -314,16 +314,24 @@
+ <li class="active">
+ <a href="./">os_eventq_init</a>
+ </li>
+
+
+
+
+
<li >
- <a href="../os_eventq_get/">os_eventq_get</a>
+ <a href="../os_eventq_inited/">os_eventq_inited</a>
</li>
- <li class="active">
- <a href="./">os_eventq_init</a>
+ <li >
+ <a href="../os_eventq_get/">os_eventq_get</a>
</li>
@@ -344,6 +352,22 @@
+
+
+ <li >
+ <a href="../os_eventq_dflt_set/">os_eventq_dflt_set</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_dflt_get/">os_eventq_dflt_get</a>
+ </li>
+
+
+
</ul>
</li>
@@ -686,7 +710,7 @@
- <li>» <a href="../os_eventq_get/">Functions</a></li>
+ <li>» Functions</li>
@@ -748,16 +772,16 @@ This initializes event queue used by newtmgr task.</p>
<ul class="nav nav-pills" style="margin-bottom: 10px">
<li>
- <a href=../os_eventq_get/>
+ <a href=../event_queue/>
<span class="fa fa-arrow-left"></span>
- Previous: os_eventq_get
+ Previous: Event Queues
</a>
</li>
<li class="pull-right">
- <a href=../os_eventq_put/>
- Next: os_eventq_put
+ <a href=../os_eventq_inited/>
+ Next: os_eventq_inited
<span class="fa fa-arrow-right"></span>
</a>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/latest/os/core_os/event_queue/os_eventq_inited/index.html
----------------------------------------------------------------------
diff --git a/latest/os/core_os/event_queue/os_eventq_inited/index.html b/latest/os/core_os/event_queue/os_eventq_inited/index.html
new file mode 100644
index 0000000..624bdbb
--- /dev/null
+++ b/latest/os/core_os/event_queue/os_eventq_inited/index.html
@@ -0,0 +1,823 @@
+<!DOCTYPE html>
+<html lang="en">
+ <head>
+ <meta charset="utf-8">
+ <meta http-equiv="X-UA-Compatible" content="IE=edge">
+ <meta name="viewport" content="width=device-width, initial-scale=1.0">
+
+
+ <!-- This is broken by doc revisioning.
+ <link rel="canonical" href="http://mynewt.apache.org/os/core_os/event_queue/os_eventq_inited/"> -->
+ <link rel="shortcut icon" href="../../../../img/favicon.ico">
+
+ <title>os_eventq_inited - Apache Mynewt</title>
+
+ <link href="../../../../css/bootstrap-3.0.3.min.css" rel="stylesheet">
+ <link rel="stylesheet" href="../../../../css/highlight.css">
+ <link href="../../../../css/base.css" rel="stylesheet">
+ <link href="../../../../css/custom.css" rel="stylesheet">
+ <link href="../../../../css/v2.css" rel="stylesheet">
+ <link href="https://fonts.googleapis.com/css?family=Lato" rel="stylesheet">
+ <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css">
+ <link href="../../../../extra.css" rel="stylesheet">
+
+ <!-- HTML5 shim and Respond.js IE8 support of HTML5 elements and media queries -->
+ <!--[if lt IE 9]>
+ <script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
+ <script src="https://oss.maxcdn.com/libs/respond.js/1.3.0/respond.min.js"></script>
+ <![endif]-->
+
+
+ <script>
+ (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+ m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+ })(window,document,'script','//www.google-analytics.com/analytics.js','ga');
+
+ ga('create', 'UA-72162311-1', 'auto');
+ ga('send', 'pageview');
+ </script>
+
+ </head>
+
+
+ <body class="os_eventq_inited">
+
+
+ <div class="container">
+ <div class="row v2-main-banner">
+ <div class="col-xs-12 v2-vcenter">
+ <a href="/"><img class="logo" src="/img/logo.png"></a>
+
+ <h4 class="tagline">An OS to build, deploy and securely manage billions of devices</h4>
+ </div>
+ </div>
+</div>
+
+
+
+
+
+
+
+
+<nav id="navbar" class="navbar navbar-inverse affix-top" data-spy="affix" data-offset-top="150" role="navigation">
+ <div class="container">
+ <!-- Collapsed navigation -->
+ <div class="navbar-header">
+ <!-- Expander button -->
+ <button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse">
+ <span class="sr-only">Toggle navigation</span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ </button>
+
+ </div>
+
+ <!-- Expanded navigation -->
+ <div class="navbar-collapse collapse">
+ <!-- Main navigation -->
+ <ul class="nav navbar-nav navbar-right">
+ <li
+ class=""
+>
+ <a href="/"><i class="fa fa-home" style="font-size: larger;"></i></a>
+ </li>
+ <li
+ class="important"
+>
+ <a href="/quick-start/">Quick Start</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/about/">About</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/talks/">Talks</a>
+ </li>
+ <li
+ class="active"
+>
+ <a href="/latest/os/introduction">Documentation</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/download/">Download</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/community/">Community</a>
+ </li>
+ <li
+ class=""
+>
+ <a href="/events/">Events</a>
+ </li>
+ </ul>
+
+ <!-- Search, Navigation and Repo links -->
+ <ul class="nav navbar-nav navbar-right">
+
+ </ul>
+ </div>
+ </div>
+</nav>
+
+
+
+ <div class="container">
+
+ <div class="row">
+ <div class="col-md-3 v2-sidebar sidebar-container"><div id="docSidebar" class="hidden-print" role="complementary">
+ <div class="top">
+ <div role="search">
+ <form id="rtd-search-form" class="wy-form" action="../../../../search.html" method="get">
+ <div class="form-group">
+ <input type="text" name="q" class="form-control" placeholder="Search documentation" />
+ </div>
+ </form>
+ </div>
+ </div>
+ <ul class="toc-nav">
+ <li class="doc-version">
+<select class="form-control" onchange="if (this.value) window.location.href=this.value">
+
+ <option
+ value="/develop/os/introduction"
+ selected="selected"
+ >
+ Version: develop (latest)
+ </option>
+
+ <option
+ value="/v0_9_0/os/introduction"
+
+ >
+ Version: 0.9.0
+ </option>
+
+</select>
+</li>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ <li ><a href="../../../introduction/">Mynewt Documentation</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li ><a href="../../../get_started/get_started/">Basic Setup</a>
+
+
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../../../get_started/vocabulary/">Concepts</a>
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../tutorials/tutorials/">Tutorials</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../os_user_guide/">OS User Guide</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li ><a href="../../mynewt_os/">OS Core</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li><a href="
+ ../../os_init/
+">System-level Functions</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../context_switch/context_switch/">Scheduler</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../time/os_time/">Time</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../task/task/">Tasks</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../event_queue/">Event Queues</a>
+
+
+ <ul>
+
+
+
+
+
+
+
+ <li><a href="
+ ../os_eventq_init/
+">Functions</a>
+
+
+ <ul>
+
+
+
+ <li >
+ <a href="../os_eventq_init/">os_eventq_init</a>
+ </li>
+
+
+
+
+
+ <li class="active">
+ <a href="./">os_eventq_inited</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_get/">os_eventq_get</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_put/">os_eventq_put</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_remove/">os_eventq_remove</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_dflt_set/">os_eventq_dflt_set</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_dflt_get/">os_eventq_dflt_get</a>
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../semaphore/semaphore/">Semaphores</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../mutex/mutex/">Mutexes</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../memory_pool/memory_pool/">Memory Pools</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../heap/heap/">Heap</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+
+
+ ../../mbuf/mbuf/
+
+">Memory Buffers</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../sanity/sanity/">Sanity</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../callout/callout/">Callouts</a>
+
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../porting/port_os/">Porting to your Platform</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/console/console/">Console</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/shell/shell/">Shell</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/split/split/">Split Images</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/bootloader/bootloader/">Bootloader</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+
+
+ ../../../modules/fs/fs/fs/
+
+">File System</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/hal/hal/">Hardware Abstraction Layer</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/testutil/testutil/">Test Utilities</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/imgmgr/imgmgr/">Image Manager</a>
+
+
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../../../modules/baselibc/">Baselibc library</a>
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/elua/elua/">Embedded Lua</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/json/json/">JSON</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/fcb/fcb/">Flash Circular Buffer</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/stats/stats/">Stats</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../modules/logs/logs/">Logs</a>
+
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+ ../../../../network/ble/ble_intro/
+">BLE User Guide</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../../newt/newt_intro/">Newt Tool Guide</a>
+
+
+ </li>
+
+
+
+
+
+
+
+ <li ><a href="../../../../newtmgr/overview/">Newt Manager Guide</a>
+
+
+ </li>
+
+
+
+ </ul>
+
+ </li>
+
+
+
+
+
+
+
+ <li><a href="
+ ../../../../faq/how_to_edit_docs/
+">Appendix</a>
+
+
+ </li>
+
+
+
+ </ul>
+</div></div>
+
+ <div class="col-md-9" role="main">
+ <div class="doc-header">
+ <div role="navigation" aria-label="breadcrumbs navigation">
+ <ul class="wy-breadcrumbs pull-right">
+ <li><a href="/latest/os/introduction">Docs</a></li>
+
+
+
+ <li>» <a href="../event_queue/">Event Queues</a></li>
+
+
+
+ <li>» <a href="../os_eventq_init/">Functions</a></li>
+
+
+
+ <li>» os_eventq_inited</li>
+
+
+
+ </ul>
+</div>
+ </div>
+
+ <h2 id="os_eventq_inited"><font color="F2853F" style="font-size:24pt"> os_eventq_inited</font></h2>
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"> <span style="color: #A90D91">int</span>
+ <span style="color: #000000">os_eventq_inited</span>(<span style="color: #A90D91">const</span> <span style="color: #A90D91">struct</span> <span style="color: #000000">os_eventq</span> <span style="color: #000000">*evq</span>)
+</pre></div>
+
+
+<p>Check if event queue <code>const struct os_eventq</code> is ready for use.</p>
+<h4 id="arguments">Arguments</h4>
+<table>
+<thead>
+<tr>
+<th>Arguments</th>
+<th>Description</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td><code>evq</code></td>
+<td>Pointer to event queue to check</td>
+</tr>
+</tbody>
+</table>
+<h4 id="returned-values">Returned values</h4>
+<p><code>0</code> if event queue is ready</p>
+<h4 id="notes">Notes</h4>
+<p>If an event queue was properly initialized (and the proper checks were done at initialization)
+this check is not needed prior to using an event queue.</p>
+<h4 id="example">Example</h4>
+<p><Add text to set up the context for the example here>
+This checks an event queue before using it.</p>
+<div class="codehilite" style="background: #ffffff"><pre style="line-height: 125%"><span style="color: #A90D91">struct</span> <span style="color: #000000">os_eventq</span> <span style="color: #000000">g_my_evq</span>;
+
+<span style="color: #A90D91">int</span>
+<span style="color: #000000">my_task_init</span>(<span style="color: #A90D91">uint8_t</span> <span style="color: #000000">prio</span>, <span style="color: #A90D91">os_stack_t</span> <span style="color: #000000">*stack_ptr</span>, <span style="color: #A90D91">uint16_t</span> <span style="color: #000000">stack_len</span>)
+{
+ <span style="color: #177500">/* variable declarations here */</span>
+
+ <span style="color: #A90D91">if</span>(<span style="color: #000000">os_eventq_inited</span>(<span style="color: #000000">&g_my_evq</span>))
+ {
+ <span style="color: #177500">/* deal with the event queue */</span>
+ };
+
+}
+</pre></div>
+
+ <div class="row">
+
+
+
+
+<ul class="nav nav-pills" style="margin-bottom: 10px">
+ <li>
+
+ <a href=../os_eventq_init/>
+ <span class="fa fa-arrow-left"></span>
+ Previous: os_eventq_init
+ </a>
+
+ </li>
+ <li class="pull-right">
+
+ <a href=../os_eventq_get/>
+ Next: os_eventq_get
+ <span class="fa fa-arrow-right"></span>
+ </a>
+
+ </li>
+</ul>
+ </div>
+ <footer class="row">
+ <div class="col-xs-12">
+
+ <p class="copyright">Copyright © 2015 The Apache Software Foundation, Licensed under the Apache License, Version 2.0 Apache and the Apache feather logo are trademarks of The Apache Software Foundation.</p>
+
+ </div>
+ <div class="col-xs-12">
+ <div class="logos">
+ <img src="/img/asf_logo_wide_small.png" alt="Apache" title="Apache">
+ <small class="footnote">
+ MyNewt is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the Apache Incubator. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+ </small>
+ <img src="/img/egg-logo2.png" alt="Apache Incubator" title="Apache Incubator">
+ </div>
+ </div>
+</footer>
+ </div>
+ </div>
+
+
+ </div>
+
+ <script src="../../../../js/jquery-1.10.2.min.js"></script>
+ <script src="../../../../js/bootstrap-3.0.3.min.js"></script>
+ <script src="../../../../js/highlight.pack.js"></script>
+ <script src="../../../../js/base.js"></script>
+ <script src="../../../../js/custom.js"></script>
+
+ </body>
+</html>
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/latest/os/core_os/event_queue/os_eventq_put/index.html
----------------------------------------------------------------------
diff --git a/latest/os/core_os/event_queue/os_eventq_put/index.html b/latest/os/core_os/event_queue/os_eventq_put/index.html
index 30ca8e9..874f34b 100644
--- a/latest/os/core_os/event_queue/os_eventq_put/index.html
+++ b/latest/os/core_os/event_queue/os_eventq_put/index.html
@@ -306,7 +306,7 @@
<li><a href="
- ../os_eventq_get/
+ ../os_eventq_init/
">Functions</a>
@@ -315,7 +315,7 @@
<li >
- <a href="../os_eventq_get/">os_eventq_get</a>
+ <a href="../os_eventq_init/">os_eventq_init</a>
</li>
@@ -323,7 +323,15 @@
<li >
- <a href="../os_eventq_init/">os_eventq_init</a>
+ <a href="../os_eventq_inited/">os_eventq_inited</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_get/">os_eventq_get</a>
</li>
@@ -344,6 +352,22 @@
+
+
+ <li >
+ <a href="../os_eventq_dflt_set/">os_eventq_dflt_set</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_dflt_get/">os_eventq_dflt_get</a>
+ </li>
+
+
+
</ul>
</li>
@@ -686,7 +710,7 @@
- <li>» <a href="../os_eventq_get/">Functions</a></li>
+ <li>» <a href="../os_eventq_init/">Functions</a></li>
@@ -752,9 +776,9 @@ This is used to pass info about an event to a task handling it.</p>
<ul class="nav nav-pills" style="margin-bottom: 10px">
<li>
- <a href=../os_eventq_init/>
+ <a href=../os_eventq_get/>
<span class="fa fa-arrow-left"></span>
- Previous: os_eventq_init
+ Previous: os_eventq_get
</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/latest/os/core_os/event_queue/os_eventq_remove/index.html
----------------------------------------------------------------------
diff --git a/latest/os/core_os/event_queue/os_eventq_remove/index.html b/latest/os/core_os/event_queue/os_eventq_remove/index.html
index 02ecc21..bba647e 100644
--- a/latest/os/core_os/event_queue/os_eventq_remove/index.html
+++ b/latest/os/core_os/event_queue/os_eventq_remove/index.html
@@ -306,7 +306,7 @@
<li><a href="
- ../os_eventq_get/
+ ../os_eventq_init/
">Functions</a>
@@ -315,7 +315,7 @@
<li >
- <a href="../os_eventq_get/">os_eventq_get</a>
+ <a href="../os_eventq_init/">os_eventq_init</a>
</li>
@@ -323,7 +323,15 @@
<li >
- <a href="../os_eventq_init/">os_eventq_init</a>
+ <a href="../os_eventq_inited/">os_eventq_inited</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_get/">os_eventq_get</a>
</li>
@@ -344,6 +352,22 @@
+
+
+ <li >
+ <a href="../os_eventq_dflt_set/">os_eventq_dflt_set</a>
+ </li>
+
+
+
+
+
+ <li >
+ <a href="../os_eventq_dflt_get/">os_eventq_dflt_get</a>
+ </li>
+
+
+
</ul>
</li>
@@ -686,7 +710,7 @@
- <li>» <a href="../os_eventq_get/">Functions</a></li>
+ <li>» <a href="../os_eventq_init/">Functions</a></li>
@@ -751,8 +775,8 @@ This is from <code>os_callout_stop()</code>. User wants to stop a callout from g
</li>
<li class="pull-right">
- <a href=../../semaphore/semaphore/>
- Next: Semaphores
+ <a href=../os_eventq_dflt_set/>
+ Next: os_eventq_dflt_set
<span class="fa fa-arrow-right"></span>
</a>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/latest/os/core_os/semaphore/semaphore/index.html
----------------------------------------------------------------------
diff --git a/latest/os/core_os/semaphore/semaphore/index.html b/latest/os/core_os/semaphore/semaphore/index.html
index 06c734a..0562fa4 100644
--- a/latest/os/core_os/semaphore/semaphore/index.html
+++ b/latest/os/core_os/semaphore/semaphore/index.html
@@ -732,9 +732,9 @@
<ul class="nav nav-pills" style="margin-bottom: 10px">
<li>
- <a href=../../event_queue/os_eventq_remove/>
+ <a href=../../event_queue/os_eventq_dflt_get/>
<span class="fa fa-arrow-left"></span>
- Previous: os_eventq_remove
+ Previous: os_eventq_dflt_get
</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/latest/os/tutorials/repo/create_repo/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/repo/create_repo/index.html b/latest/os/tutorials/repo/create_repo/index.html
index af2e1f6..5bf9757 100644
--- a/latest/os/tutorials/repo/create_repo/index.html
+++ b/latest/os/tutorials/repo/create_repo/index.html
@@ -503,7 +503,7 @@ repo.versions:
<p>It contains the following:</p>
<ul>
<li><strong>repo.name</strong> The external name that is used to include the library in
-your <code>project.yml</code> file. This is the name you in include in the <code>project.repositories</code>
+your <code>project.yml</code> file. This is the name you include in the <code>project.repositories</code>
variable when adding this repository to your project.</li>
<li><strong>repo.versions</strong> A description of what versions to give the user depending
on the settings in their <code>project.yml</code> file. See below for a thorough description
[3/7] incubator-mynewt-site git commit: Updated events. Updated event
queue documentation. This closes #126
Posted by ad...@apache.org.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/db7dea53/latest/mkdocs/search_index.json
----------------------------------------------------------------------
diff --git a/latest/mkdocs/search_index.json b/latest/mkdocs/search_index.json
index c1bb107..8cbfaeb 100644
--- a/latest/mkdocs/search_index.json
+++ b/latest/mkdocs/search_index.json
@@ -932,7 +932,7 @@
},
{
"location": "/os/tutorials/repo/create_repo/",
- "text": "Create a Repo out of a Project\n\n\nIn order to create a repository out of a project, all you need to do is create a \n\nrepository.yml\n file, and check it into the master branch of your project.\n\n\nNOTE:\n Currently only github source control service is supported by our \npackage management system, but support for plain git is planned for a future\nversion.\n\n\nThe \nrepository.yml\n defines all versions of the repository and the corresponding \nsource control tags that these versions correspond to. As an example, if the \n\nrepository.yml\n file has the following content, it means there is one version \nof the apache-mynewt-core operating system available, which is \n0.0.0\n (implying we \nhaven't released yet!). Such a version number corresponds to the \"develop\" branch \nin this repository. \n0-latest\n would also resolved to this same \n0.0.0\n version. \nThe next section explains the versioning system a bit more.\n\n\n$ more repository.yml\nrepo.name
: apache-mynewt-core\nrepo.versions:\n \n0.0.0\n: \ndevelop\n\n \n0-latest\n: \n0.0.0\n\n\n\n\n\n\n\n\nWhere should the repository.yml file be?\n\n\nThe \nrepository.yml\n file lives only in the master branch of the git\nrepository. \nNewt\n will always fetch this file from the master branch and then\nuse that to resolve the actual branch required depending on the version\nspecified in the project. \nSpecial care should be taken to ensure that this\nfile exists only in the master branch.\n\n\nHere is the \nrepository.yml\n file from a certain snapshot of apache-Mynewt-core:\n\n\nrepo.name: apache-mynewt-core\nrepo.versions:\n \n0.7.9\n: \nMynewt_0_8_0_b2_tag\n\n \n0-latest\n: \n0.7.9\n\n \n0.8-latest\n: \n0.7.9\n\n\n\n\n\n\n\n\nIt contains the following:\n\n\n\n\nrepo.name\n The external name that is used to include the library in \nyour \nproject.yml\n file. This is the name you in include in the \nproject.repositories\n \nvariable when adding this repository t
o your project.\n\n\nrepo.versions\n A description of what versions to give the user depending \non the settings in their \nproject.yml\n file. See below for a thorough description\non versioning. Its a flexible mapping between version numbers and git branches.\n\n\n\n\n\n\nRepo Version Specification\n\n\nThe version field argument for a repo has the following format:\n\n\nmajor_num\n.\nminor_num\n.\nrevision_num\n\n\n\n\n\n\nor\n\n\nmajor_num\n.\nminor_num\n-\nstability string\n\n\n\n\n\n\nor \n\n\nmajor_num\n-\nstability string\n\n\n\n\n\n\n\n\nThe stability string can be one of 3 pre-defined stability values.\n\n\n\n\nstable\n -- A stable release version of the repository\n\n\ndev\n -- A development version from the repository\n\n\nlatest\n -- The latest from the repository\n\n\n\n\nIn your \nproject.yml\n file you can specify different combinations of \nthe version number and stability value. For example:\n\n\n\n\n0-latest\n -- The latest version with major number 0\n\
n\n1.2-stable\n -- The latest stable version with major and minor number 1.2\n\n\n1.2-dev\n -- The development version from 1.2\n\n\n1.1.1\n -- a specific version 1.1.1\n\n\n\n\nYou \ncannot\n specify a stability string with a fully numbered version, e.g.\n\n\n1.2.8-stable\n\n\n\n\n\n\n\nRepo Version Resolution\n\n\nA \nrepository.yml\n file contains information to match this version request\ninto a git branch to fetch for your project.\n\n\nIt's up to you as the repository maintainer to map these to actual github branches \nof the repository. For example, let's say in a fictitious repository the \nfollowing are defined.\n\n\nrepo.versions:\n \n0.8.0\n: \nxxx_branch_0_8_0\n\n \n1.0.0\n: \nxxx_branch_1_0_0\n\n \n1.0.2\n: \nxxx_branch_1_0_2\n\n \n1.1.1\n: \nxxx_branch_1_1_0\n\n \n1.1.2\n: \nxxx_branch_1_1_2\n\n \n1.2.0\n: \nxxx_branch_1_2_0\n\n \n1.2.1\n: \nxxx_branch_1_2_1\n\n \n1.2-dev\n: \n1.2.1\n\n \n1-dev\n: \n1.2-dev\n\n \n1.2-stab
le\n: \n1.2.0\n\n \n0-latest\n: \n0.8.0\n\n \n1-latest\n: \n1-dev\n\n ....\n\n\n\n\n\nWhen the \nproject.yml\n file asks for \n1.2-stable\n it will be resolved to version\n\n1.2.0\n which in turn will resolve to a specific branch \nxxx_branch_1_2_0\n.\n\nThis is the branch that \nnewt\n will then fetch into the project with that \nproject.yml\n file.\n\n\n\n\nDependencies on other repos\n\n\nRepositories can also have dependencies on other repositories. These \ndependencies should be listed out on a per-tag basis. So, for example, \nif apache-mynewt-core were to depend on sterlys-little-repo, you might \nhave the following directives in the repository.yml:\n\n\ndevelop.repositories:\n sterlys-little-repo:\n type: github\n vers: 0.8-latest\n user: sterlinghughes\n repo: sterlys-little-repo\n\n\n\n\n\n\n\nThis would tell Newt that for anything that resolves to the develop \nbranch, this repository requires the sterlys-little-repo repository. \
n\n\nDependencies are resolved circularly by the newt tool, and every \ndependent repository is placed as a sibling in the repos directory. \nCurrently, if two repositories have the same name, they will conflict \nand bad things will happen.\n\n\nWhen a repository is installed to the repos/ directory, the current \nversion of that repository is written to the \nproject.state\n file. The \nproject state file contains the currently installed version of any given \nrepository. This way, the current set of repositories can be recreated \nfrom the \nproject.state\n file reliably, whereas the \nproject.yml\n file can \nhave higher level directives (i.e. include 0.8-stable.)\n\n\nResolving dependencies\n\n\nAt the moment, all dependencies must match, otherwise newt will provide \nan error. As an example, if you have a set of dependencies such that:\n\n\napache-mynewt-core depends on sterlys-little-repo 0.6-stable\napache-mynewt-core depends on sterlys-big-repo 0.5.1\nsterlys-big-repo-0.
5.1 depends on sterlys-little-repo 0.6.2\n\n\n\n\n\n\n\nwhere 0.6-stable is 0.6.3, the newt tool will try and resolve the dependency to \nsterlys-little-repo. It will notice that there are two conflicting \nversions of the same repository, and not perform installation.\n\n\nIn the future Newt will be smarter about loading in all dependencies, \nand then looking to satisfy those dependencies to the best match of all \npotential options.",
+ "text": "Create a Repo out of a Project\n\n\nIn order to create a repository out of a project, all you need to do is create a \n\nrepository.yml\n file, and check it into the master branch of your project.\n\n\nNOTE:\n Currently only github source control service is supported by our \npackage management system, but support for plain git is planned for a future\nversion.\n\n\nThe \nrepository.yml\n defines all versions of the repository and the corresponding \nsource control tags that these versions correspond to. As an example, if the \n\nrepository.yml\n file has the following content, it means there is one version \nof the apache-mynewt-core operating system available, which is \n0.0.0\n (implying we \nhaven't released yet!). Such a version number corresponds to the \"develop\" branch \nin this repository. \n0-latest\n would also resolved to this same \n0.0.0\n version. \nThe next section explains the versioning system a bit more.\n\n\n$ more repository.yml\nrepo.name
: apache-mynewt-core\nrepo.versions:\n \n0.0.0\n: \ndevelop\n\n \n0-latest\n: \n0.0.0\n\n\n\n\n\n\n\n\nWhere should the repository.yml file be?\n\n\nThe \nrepository.yml\n file lives only in the master branch of the git\nrepository. \nNewt\n will always fetch this file from the master branch and then\nuse that to resolve the actual branch required depending on the version\nspecified in the project. \nSpecial care should be taken to ensure that this\nfile exists only in the master branch.\n\n\nHere is the \nrepository.yml\n file from a certain snapshot of apache-Mynewt-core:\n\n\nrepo.name: apache-mynewt-core\nrepo.versions:\n \n0.7.9\n: \nMynewt_0_8_0_b2_tag\n\n \n0-latest\n: \n0.7.9\n\n \n0.8-latest\n: \n0.7.9\n\n\n\n\n\n\n\n\nIt contains the following:\n\n\n\n\nrepo.name\n The external name that is used to include the library in \nyour \nproject.yml\n file. This is the name you include in the \nproject.repositories\n \nvariable when adding this repository to y
our project.\n\n\nrepo.versions\n A description of what versions to give the user depending \non the settings in their \nproject.yml\n file. See below for a thorough description\non versioning. Its a flexible mapping between version numbers and git branches.\n\n\n\n\n\n\nRepo Version Specification\n\n\nThe version field argument for a repo has the following format:\n\n\nmajor_num\n.\nminor_num\n.\nrevision_num\n\n\n\n\n\n\nor\n\n\nmajor_num\n.\nminor_num\n-\nstability string\n\n\n\n\n\n\nor \n\n\nmajor_num\n-\nstability string\n\n\n\n\n\n\n\n\nThe stability string can be one of 3 pre-defined stability values.\n\n\n\n\nstable\n -- A stable release version of the repository\n\n\ndev\n -- A development version from the repository\n\n\nlatest\n -- The latest from the repository\n\n\n\n\nIn your \nproject.yml\n file you can specify different combinations of \nthe version number and stability value. For example:\n\n\n\n\n0-latest\n -- The latest version with major number 0\n\n\n
1.2-stable\n -- The latest stable version with major and minor number 1.2\n\n\n1.2-dev\n -- The development version from 1.2\n\n\n1.1.1\n -- a specific version 1.1.1\n\n\n\n\nYou \ncannot\n specify a stability string with a fully numbered version, e.g.\n\n\n1.2.8-stable\n\n\n\n\n\n\n\nRepo Version Resolution\n\n\nA \nrepository.yml\n file contains information to match this version request\ninto a git branch to fetch for your project.\n\n\nIt's up to you as the repository maintainer to map these to actual github branches \nof the repository. For example, let's say in a fictitious repository the \nfollowing are defined.\n\n\nrepo.versions:\n \n0.8.0\n: \nxxx_branch_0_8_0\n\n \n1.0.0\n: \nxxx_branch_1_0_0\n\n \n1.0.2\n: \nxxx_branch_1_0_2\n\n \n1.1.1\n: \nxxx_branch_1_1_0\n\n \n1.1.2\n: \nxxx_branch_1_1_2\n\n \n1.2.0\n: \nxxx_branch_1_2_0\n\n \n1.2.1\n: \nxxx_branch_1_2_1\n\n \n1.2-dev\n: \n1.2.1\n\n \n1-dev\n: \n1.2-dev\n\n \n1.2-stable\
n: \n1.2.0\n\n \n0-latest\n: \n0.8.0\n\n \n1-latest\n: \n1-dev\n\n ....\n\n\n\n\n\nWhen the \nproject.yml\n file asks for \n1.2-stable\n it will be resolved to version\n\n1.2.0\n which in turn will resolve to a specific branch \nxxx_branch_1_2_0\n.\n\nThis is the branch that \nnewt\n will then fetch into the project with that \nproject.yml\n file.\n\n\n\n\nDependencies on other repos\n\n\nRepositories can also have dependencies on other repositories. These \ndependencies should be listed out on a per-tag basis. So, for example, \nif apache-mynewt-core were to depend on sterlys-little-repo, you might \nhave the following directives in the repository.yml:\n\n\ndevelop.repositories:\n sterlys-little-repo:\n type: github\n vers: 0.8-latest\n user: sterlinghughes\n repo: sterlys-little-repo\n\n\n\n\n\n\n\nThis would tell Newt that for anything that resolves to the develop \nbranch, this repository requires the sterlys-little-repo repository. \n\n
\nDependencies are resolved circularly by the newt tool, and every \ndependent repository is placed as a sibling in the repos directory. \nCurrently, if two repositories have the same name, they will conflict \nand bad things will happen.\n\n\nWhen a repository is installed to the repos/ directory, the current \nversion of that repository is written to the \nproject.state\n file. The \nproject state file contains the currently installed version of any given \nrepository. This way, the current set of repositories can be recreated \nfrom the \nproject.state\n file reliably, whereas the \nproject.yml\n file can \nhave higher level directives (i.e. include 0.8-stable.)\n\n\nResolving dependencies\n\n\nAt the moment, all dependencies must match, otherwise newt will provide \nan error. As an example, if you have a set of dependencies such that:\n\n\napache-mynewt-core depends on sterlys-little-repo 0.6-stable\napache-mynewt-core depends on sterlys-big-repo 0.5.1\nsterlys-big-repo-0.5.1
depends on sterlys-little-repo 0.6.2\n\n\n\n\n\n\n\nwhere 0.6-stable is 0.6.3, the newt tool will try and resolve the dependency to \nsterlys-little-repo. It will notice that there are two conflicting \nversions of the same repository, and not perform installation.\n\n\nIn the future Newt will be smarter about loading in all dependencies, \nand then looking to satisfy those dependencies to the best match of all \npotential options.",
"title": "Turn project into a repo"
},
{
@@ -942,7 +942,7 @@
},
{
"location": "/os/tutorials/repo/create_repo/#where-should-the-repositoryyml-file-be",
- "text": "The repository.yml file lives only in the master branch of the git\nrepository. Newt will always fetch this file from the master branch and then\nuse that to resolve the actual branch required depending on the version\nspecified in the project. Special care should be taken to ensure that this\nfile exists only in the master branch. Here is the repository.yml file from a certain snapshot of apache-Mynewt-core: repo.name: apache-mynewt-core\nrepo.versions:\n 0.7.9 : Mynewt_0_8_0_b2_tag \n 0-latest : 0.7.9 \n 0.8-latest : 0.7.9 It contains the following: repo.name The external name that is used to include the library in \nyour project.yml file. This is the name you in include in the project.repositories \nvariable when adding this repository to your project. repo.versions A description of what versions to give the user depending \non the settings in their project.yml file. See below for a thorough description\non versionin
g. Its a flexible mapping between version numbers and git branches.",
+ "text": "The repository.yml file lives only in the master branch of the git\nrepository. Newt will always fetch this file from the master branch and then\nuse that to resolve the actual branch required depending on the version\nspecified in the project. Special care should be taken to ensure that this\nfile exists only in the master branch. Here is the repository.yml file from a certain snapshot of apache-Mynewt-core: repo.name: apache-mynewt-core\nrepo.versions:\n 0.7.9 : Mynewt_0_8_0_b2_tag \n 0-latest : 0.7.9 \n 0.8-latest : 0.7.9 It contains the following: repo.name The external name that is used to include the library in \nyour project.yml file. This is the name you include in the project.repositories \nvariable when adding this repository to your project. repo.versions A description of what versions to give the user depending \non the settings in their project.yml file. See below for a thorough description\non versioning.
Its a flexible mapping between version numbers and git branches.",
"title": "Where should the repository.yml file be?"
},
{
@@ -967,17 +967,17 @@
},
{
"location": "/os/tutorials/tasks_lesson/",
- "text": "Core OS Lesson: Tasks and Priority Management\n\n\nTarget Platform: Arduino M0 Pro\n (or legacy Arduino Zero or Zero Pro, but not Arduino M0)\n\n\nThis lesson is designed to teach core OS concepts and strategies encountered when building applications using Mynewt. Specifically, this lesson will cover tasks, simple multitasking, and priority management running on an Arduino M0 Pro.\n\n\nPrerequisites\n\n\nBefore starting, you should read about Mynewt in the \nIntroduction\n section and complete the \nQuickStart\n guide and the \nBlinky\n tutorial. Furthermore, it may be helpful to take a peek at the \ntask documentation\n for additional insights.\n\n\nEquipment\n\n\nYou will need the following equipment:\n\n\n\n\nArduino M0 Pro (or legacy Arduino Zero or Zero Pro, but not Arduino M0)\n\n\nComputer with Mynewt installed\n\n\nUSB to Micro USB Cable\n\n\n\n\nBuild Your Application\n\n\nTo save time, we will simply modify the Blinky app as it has the basic task struc
ture already implemented. Follow the \nArduino Zero Blinky tutorial\n to create a new project and build your bootloader and application. Finally, build and load the application to your Arduino to verify that everything is in order. Now let\u2019s get started!\n\n\nCreate a New Task\n\n\nThe purpose of this section is to give an introduction to the important aspects of tasks and how to properly initialize them. First, let\u2019s define a second task called \nwork_task\n in main.c (located in apps/blinky/src):\n\n\nstruct\n \nos_task\n \nwork_task\n;\n\n\n\n\n\nA task is represented by the \nos_task\n struct which will hold the task\u2019s information (name, state, priority, etc.). A task is made up of two main elements, a task function (also known as a task handler) and a task stack.\n\n\nNext, let\u2019s take a look at what is required to initialize our new task.\n\n\nTask Stack\n\n\nThe task stack is an array of type \nos_stack_t\n which holds the program stack frames. Mynewt give
s us the ability to set the stack size for a task giving the application developer room to optimize memory usage. Since we\u2019re not short on memory, our \nblinky_stack\n and \nwork_stack\n are plenty large for the purpose of this lesson. Notice that the elements in our task stack are of type \nos_stack_t\n which are generally 32 bits, making our entire stack 1024 Bytes.\n\n\n \n#define WORK_STACK_SIZE OS_STACK_ALIGN(256)\n\n \nos_stack_t\n \nwork_stack\n[\nWORK_STACK_SIZE\n];\n\n\n\n\n\nNote: The \nOS_STACK_ALIGN\n macro is used to align the stack based on the hardware architecture.\n\n\nTask Function\n\n\nThe task function is essentially an infinite loop which waits for some \u201cevent\u201d to wake it up. In our Blinky app the task function, named \nblinky_task_handler()\n, is initially called when we call \nos_start()\n in \nmain()\n. In general, the task function is where the majority of work is done by a task. Let\u2019s write a task function for \nwork_task\n called \nwo
rk_task_handler()\n:\n\n\nvoid\n\n\nwork_task_handler\n(\nvoid\n \n*arg\n)\n{\n \nstruct\n \nos_task\n \n*t\n;\n\n \ng_led_pin\n \n=\n \nLED_BLINK_PIN\n;\n \nhal_gpio_init_out\n(\ng_led_pin\n, \n1\n);\n\n \nwhile\n (\n1\n) {\n \nt\n \n=\n \nos_sched_get_current_task\n();\n \nassert\n(\nt-\nt_func\n \n==\n \nwork_task_handler\n);\n \n/* Do work... */\n\n }\n}\n\n\n\n\n\nThe task function is called when the task is initially put into the \nrunning\n state by the scheduler. We use an infinite loop to ensure that the task function never returns. Our assertion that the current task's handler is the same as our task handler is for illustration purposes only and does not need to be in most task functions.\n\n\nTask Priority\n\n\nAs a preemptive, multitasking RTOS, Mynewt decides which tasks to run based on which has a higher priority; the highest priority being 0 and the lowest 255. Thus, before initializing our task, we must choose a priority defined as
a macro variable.\n\n\nLet\u2019s set the priority of \nwork_task\n to 0, because everyone knows that work is more important than blinking.\n\n\n \n#define WORK_TASK_PRIO (0)\n\n\n\n\n\n\nInitialization\n\n\nTo initialize a new task we use \nos_task_init()\n which takes a number of arguments including our new task function, stack, and priority. Much like \nblinky_task\n, we\u2019re going to initialize \nwork_task\n inside \ninit_tasks\n to keep our main function clean.\n\n\nint\n\n\ninit_tasks\n(\nvoid\n)\n{\n \n/* \u2026 */\n\n \nos_task_init\n(\nwork_task\n, \nwork\n, \nwork_task_handler\n, \nNULL\n,\n \nWORK_TASK_PRIO\n, \nOS_WAIT_FOREVER\n, \nwork_stack\n,\n \nWORK_STACK_SIZE\n);\n\n \ntasks_initialized\n \n=\n \n1\n;\n \nreturn\n \n0\n;\n}\n\n\n\n\n\nAnd that\u2019s it! Now run your application using the newt run command.\n\n\n$ newt run arduino_blinky 0.0.0\n\n\n\n\n\nWhen GDB appears press C then Enter to continue and \u2026 \nwait, why doe
sn't our LED blink anymore?\n\n\nReview\n\n\nBefore we run our new app, let\u2019s review what we need in order to create a task. This is a general case for a new task called mytask:\n\n\n1)\n Define a new task, task stack, and priority:\n\n\n/* My Task */\n\n\nstruct\n \nos_task\n \nmytask\n\n\n/* My Task Stack */\n\n\n#define MYTASK_STACK_SIZE OS_STACK_ALIGN(256)\n\n\nos_stack_t\n \nmytask_stack\n[\nMYTASK_STACK_SIZE\n];\n\n/* My Task Priority */\n\n\n#define MYTASK_PRIO (0)\n\n\n\n\n\n\n2)\n Define task function:\n\n\nvoid\n \n\nmytask_handler\n(\nvoid\n \n*arg\n)\n{\n \nwhile\n (\n1\n) {\n \n/* ... */\n\n }\n}\n\n\n\n\n\n3)\n Initialize task before calling \nos_start()\n:\n\n\nos_task_init\n(\nmytask\n, \nmytask\n, \nmytask_handler\n, \nNULL\n, \n \nMYTASK_PRIO\n, \nOS_WAIT_FOREVER\n, \nmytask_stack\n,\n \nMYTASK_STACK_SIZE\n);\n\n\n\n\n\nTask Priority, Preempting, and Context Switching\n\n\nA preemptive RTOS is one in which a higher priority task
that is \nready to run\n will preempt (i.e. take the place of) the lower priority task which is \nrunning\n. When a lower priority task is preempted by a higher priority task, the lower priority task\u2019s context data (stack pointer, registers, etc.) is saved and the new task is switched in.\n\n\nIn our example, \nwork_task\n has a higher priority than \nblinky_task\n and, because it is never put into a \nsleep\n state, holds the processor focus on its context. Let\u2019s give \nwork_task\n a delay and some simulated work to keep it busy. Because the delay is measured in os ticks, the actual number of ticks per second is dependent on the board. Therefore, we multiply \nOS_TICKS_PER_SEC\n, which is defined in the MCU, by the number of seconds we wish to delay.\n\n\nvoid\n\n\nwork_task_handler\n(\nvoid\n \n*arg\n)\n{\n \nstruct\n \nos_task\n \n*t\n;\n\n \ng_led_pin\n \n=\n \nLED_BLINK_PIN\n;\n \nhal_gpio_init_out\n(\ng_led_pin\n, \n1\n);\n\n \nwhile\n (\n1\n) {\n
\nt\n \n=\n \nos_sched_get_current_t\n:ask\n();\n \nassert\n(\nt-\nt_func\n \n==\n \nwork_task_handler\n);\n \n/* Do work... */\n\n \nint\n \ni\n;\n \nfor\n(\ni\n \n=\n \n0\n; \ni\n \n \n1000000\n; \n++i\n) {\n \n/* Simulate doing a noticeable amount of work */\n\n \nhal_gpio_set\n(\ng_led_pin\n);\n }\n \nos_time_delay\n(\n3\n*OS_TICKS_PER_SECOND\n);\n }\n}\n\n\n\n\n\nIn order to notice the LED changing, modify the time delay in \nblinky_task_handler()\n to blink at a higher frequency.\n\n\nos_time_delay\n(\nOS_TICKS_PER_SEC/\n10\n);\n\n\n\n\n\nBefore we run the app, let\u2019s predict the behavior. With the newest additions to \nwork_task_handler()\n, our first action will be to sleep for three seconds. This will allow \nblinky_task\n to take over the CPU and blink to its heart\u2019s content. After three seconds, \nwork_task\n will wake up and be made \nready to run\n, causing it to preempt \nblinky_task\n. The LED
will then remain lit for a short period while \nwork_task\n loops, then blink again for another three seconds while \nwork_task\n sleeps. \n\n\nVoila, you should see that our prediction was correct! \n\n\nPriority Management Considerations\n\n\nWhen projects grow in scope, from blinking LEDs into more sophisticated applications, the number of tasks needed increases alongside complexity. It remains important, then, that each of our tasks is capable of doing its work within a reasonable amount of time.\n\n\nSome tasks, such as the Shell task, execute quickly and require almost instantaneous response. Therefore, the Shell task should be given a high priority. On the other hand, tasks which may be communicating over a network, or processing data, should be given a low priority in order to not hog the CPU.\n\n\nThe diagram below showcases the different scheduling patterns we. would expect from swapping blinky and work tasks priorities.\n\n\n\n\nIn the second case where \nblinky_task\n h
as a higher priority, the \u201cwork\u201d done by \nwork_task\n would be executed during the millisecond delays in \nblinky_task\n, saving us idle time compared to the first case.\n\n\nNote:\n Defining the same priority for two tasks leads to somewhat undefined behavior and should be avoided.\n\n\nComparing Priority Strategies\n\n\nInstead of stepping through a bunch of changes to our blinky app, clone my task lesson application from github and copy an existing target.\n\n\nChange directory into apps and clone the repository to get our new\nfiles:\n\n\n$ cd apps\n$ git clone https://github.com/bgiori/mynewt_tasks_lesson.git\n\n\n\n\n\nChange directory back to your project root and copy the arduino_blinky target to a new target called task_tgt.\n\n\n$\n \nnewt\n \ntarget\n \ncopy\n \narduino_blinky\n \ntask_tgt\n\n\n\n\n\n\nSet a new app location.\n\n\n$\n \nnewt\n \ntarget\n \nset\n \ntask_tgt\n \napp=apps/mynewt_tasks_lesson\n\n\n\n\n\n\nNow let\u2019s take a look at our new code
. First, notice that we have abandoned blinking, instead choosing to use the \nconsole\n and \nshell\n to follow our tasks through execution.\n\n\nAdditionally, we have a number of different tasks:\n\n\n\n\n\n\nTask A\n (\na_task\n):\n\n\n\n\nPriority\n: 3 \u2192 2\n\n\nDescription\n: Task A is supposed to represent a task which frequently does a small amount of work, such as one which rapidly polls a sensor for data. Much like \nblinky_task\n, Task A will loop 10,000 times then wait 1 millisecond. Priority is changed by \ntimer_task\n after the first simulation.\n\n\n\n\n\n\n\n\nTask B\n (\nb_task\n):\n\n\n\n\nPriority\n: 2 \u2192 3\n\n\nDescription\n: Task B is supposed to represent a task which does a large amount of work relatively infrequently, such as one which sends/receives data from the cloud. Like work_task, Task B will loop 1,000,000 times then wait 3 seconds. Priority is changed by timer_task after the first simulation.\n\n\n\n\n\n\n\n\nTimer Task\n (\ntimer_task\n):\n\n
\n\n\nPriority\n: 1\n\n\nDescription\n: With default settings, Timer Task will wait 20 seconds then print the first simulations data for Task A and B. Timer task will then swap A and B\u2019s priorities and restart the simulation. After the second simulation, timer will again print simulation data then compare the two and calculate a final speedup (simulation2 / simulation1).\n\n\n\n\n\n\n\n\nShell Task\n:\n\n\n\n\nPriority\n: 0\n\n\nDescription\n: Task used by Shell behind the scenes to communicate with the serial port.\n\n\n\n\n\n\n\n\nConnecting to the Serial Console\n\n\nBefore running our new app, we must first connect to the serial console. First make sure the mynewt_arduino_zero repository is set to the develop branch. (Remove once changes have been moved to master). \n\n\n$ cd repos/mynewt_arduino_zero\n$ git checkout develop\n\n\n\n\n\nOpen a new terminal window and list your serial connections to find our Arduino.\n\n\n$\n \nls\n \n/dev/tty\n.\n*\n\n\n\n/dev/tty\n.\nBlueto
oth-Incoming-Port\n \n/dev/tty\n.\nusbmodem14132\n\n\n\n\n\n\nIn the same window, connect to the serial port using a serial communication program. In this case I\u2019ll be using mincom as it can scroll through output.\n\n\n$\n \nminicom\n \n-D\n \n/dev/tty\n.\nusbmodem14132\n \n-b\n \n115200\n\n\n\n\n\n\nIf you see minicom welcome you, you\u2019re ready to move on!\n\n\nOutput Analysis\n\n\nRun our new target, task_tgt, and you should see an output similar to this:\n\n\nStarting First Simulation...\n1: Task B: 0% \n78: Task B: 1% \n155: Task B: 2% \n257: Task B: 3% \n359: Task B: 4% \n461: Task B: 5% \n\n\nsnip\n\n\n========== Timer Expired ==========\n\n \n Task A \n\n Priority: 3\n Loop count: 162849\n Cycle count: 16.28\n Run time: 1.40 sec\n\n \n Task B \n\n Priority: 2\n Loop count: 1345852\n Cycle count: 1.34\n Run time: 17.0 sec\n\n Total loops: 1508709\n\n20023: Switching priorities and restarting...\n20111: Task A looped\n20113: Task
B: 0% \n20191: Task B: 1% \n20297: Task A looped\n20356: Task B: 2% \n20483: Task A looped\n20545: Task B: 3% \n20669: Task A looped\n20734: Task B: 4% \n20855: Task A looped\n20923: Task B: 5% \n\n\nsnip\n\n\n========== Timer Expired ==========\n\n \n Task A \n\n Priority: 2\n Loop count: 1080000\n Cycle count: 108.0\n Run time: 9.28 sec\n\n \n Task B \n\n Priority: 3\n Loop count: 830356\n Cycle count: 0.83\n Run time: 10.72 sec\n\n Total loops: 1910404\n\n40058:\n\n Final Speedup (Sim2 / Sim1): 1.26\n\n\n\n\n\nThe console output reaffirms our previous prediction and makes both the scheduling differences and subsequent efficiency boost far more apparent. Let\u2019s take a look at scheduling differences before we delve into efficiency.\n\n\nIn the first case, where Task B\u2019s priority is higher than that of Task A, we see A get starved by Task B\u2019s long execution time. \nStarvation\n occurs when one task hogs the processor, essentially \u
201cstarving\u201d other tasks which also need to run. At the end of the first 20 second simulation period, Task A has only run for 1.4 seconds compared to task B\u2019s 17 second running time \u2013 ouch. As explained before, processes which are expected to run for long periods of time (e.g. network communication, data processing) should be given higher priorities in order to combat starvation.\n\n\nIn the second simulation with priorities swapped, we can see Task B only running during the millisecond delays when Task A is \nsleeping\n. Although having Task B only run during these delays slows its execution time, we benefit from un-starving Task A and using the processor at a higher efficiency.\n\n\nThe bottom line speedup gives us an immediate and clear indication that we have improved our ability to process work (i.e throughput). In our second run, we processed an additional 400,000 loop iterations, equating to a 26% increase in efficiency. On a standard multi-core processor foun
d in every modern PC, a 1.26 speedup would be an ok result to adding multithreading capabilities to a serial program. However, we accomplished this by simply setting priorities on a single core processor \u2013 not bad!\n\n\nNOTE: Usually the the term \u201cspeedup\u201d is used within a parallel programming context and refers to the change in execution time between a serial and parallel program executing over the same problem. In this case we\u2019re using the term loosely to illustrate the priority change\u2019s effect on scheduling and throughput in our specific context.\n\n\nEfficiency Isn\u2019t Everything\n\n\nUsing the processor during every OS tick isn\u2019t always the best course of action. If we modify Task A\u2019s delay to a tenth of a millisecond and turn off the console output, we can boost our speedup to 1.44. This, however, reduces our ability to process work from Task B who ends up only completing 18% of its work cycle after the second simulation. That would mean,
at that rate, Task B would take over a minute to finish one cycle.\n\n\nFeel free to play around with the testing parameters to study the different changes yourself!\n\n\nConclusion\n\n\nMoving forward, tasks are just the tip of the iceberg. The \nscheduler\n, \nevent queues\n, \nsemaphores\n, and \nmutexes\n also add to tasks functionality, increasing our ability as the developer to control greater numbers of tasks more intricately. For example, when we switch the tasks priority, we have to tell the scheduler that our tasks priorities have changed, allowing us us to use priorities dynamically. When running multiple tasks, logging through either the built-in \nLogs\n module (not covered in this lesson) or through the serial console/shell can be very useful for debugging your application. In the end, the way you manage your tasks depends on the context of your application. You should assign priorities based on execution time, urgency, and frequency, among other things.\n\n\nKeep blin
king and happy hacking!",
+ "text": "Core OS Lesson: Tasks and Priority Management\n\n\nTarget Platform: Arduino M0 Pro\n (or legacy Arduino Zero or Zero Pro, but not Arduino M0)\n\n\nThis lesson is designed to teach core OS concepts and strategies encountered when \nbuilding applications using Mynewt. Specifically, this lesson will cover tasks, \nsimple multitasking, and priority management running on an Arduino M0 Pro.\n\n\nPrerequisites\n\n\nBefore starting, you should read about Mynewt in the \nIntroduction\n \nsection and complete the \nQuickStart\n \nguide and the \nBlinky\n tutorial. \nFurthermore, it may be helpful to take a peek at the \ntask documentation\n \nfor additional insights.\n\n\nEquipment\n\n\nYou will need the following equipment:\n\n\n\n\nArduino M0 Pro (or legacy Arduino Zero or Zero Pro, but not Arduino M0)\n\n\nComputer with Mynewt installed\n\n\nUSB to Micro USB Cable\n\n\n\n\nBuild Your Application\n\n\nTo save time, we will simply modify the Blinky app. We'll add the Tas
k Management code to\nthe Blinky app. Follow the \nArduino Zero Blinky tutorial\n \nto create a new project and build your bootloader and application. Finally, build and \nload the application to your Arduino to verify that everything is in order. Now let\u2019s get started!\n\n\nCreate a New Task\n\n\nThe purpose of this section is to give an introduction to the important aspects of tasks \nand how to properly initialize them. First, let\u2019s define a second task called \nwork_task\n \nin main.c (located in apps/blinky/src):\n\n\nstruct\n \nos_task\n \nwork_task\n;\n\n\n\n\n\nA task is represented by the \nos_task\n\nstruct which will hold the task\u2019s information (name, state, priority, etc.). A task is made up of two \nmain elements, a task function (also known as a task handler) and a task stack.\n\n\nNext, let\u2019s take a look at what is required to initialize our new task.\n\n\nTask Stack\n\n\nThe task stack is an array of type \nos_stack_t\n which holds the program sta
ck frames. Mynewt gives \nus the ability to set the stack size for a task giving the application developer room to optimize \nmemory usage. Since we\u2019re not short on memory, our \nblinky_stack\n and \nwork_stack\n are plenty large \nfor the purpose of this lesson. Notice that the elements in our task stack are of type \nos_stack_t\n \nwhich are generally 32 bits, making our entire stack 1024 Bytes.\n\n\n \n#define WORK_STACK_SIZE OS_STACK_ALIGN(256)\n\n \nos_stack_t\n \nwork_stack\n[\nWORK_STACK_SIZE\n];\n\n\n\n\n\nNote: The \nOS_STACK_ALIGN\n macro is used to align the stack based on the hardware architecture.\n\n\nTask Function\n\n\nThe task function is essentially an infinite loop which waits for some \u201cevent\u201d to wake it up. In our \nBlinky app the task function, named \nblinky_task_handler()\n, is initially called when we call \nos_start()\n \nin \nmain()\n. In general, the task function is where the majority of work is done by a task. Let\u2019s write \na task fu
nction for \nwork_task\n called \nwork_task_handler()\n:\n\n\nvoid\n\n\nwork_task_handler\n(\nvoid\n \n*arg\n)\n{\n \nstruct\n \nos_task\n \n*t\n;\n\n \ng_led_pin\n \n=\n \nLED_BLINK_PIN\n;\n \nhal_gpio_init_out\n(\ng_led_pin\n, \n1\n);\n\n \nwhile\n (\n1\n) {\n \nt\n \n=\n \nos_sched_get_current_task\n();\n \nassert\n(\nt-\nt_func\n \n==\n \nwork_task_handler\n);\n \n/* Do work... */\n\n }\n}\n\n\n\n\n\nThe task function is called when the task is initially put into the \nrunning\n state by the scheduler. \nWe use an infinite loop to ensure that the task function never returns. Our assertion that the current \ntask's handler is the same as our task handler is for illustration purposes only and does not need to \nbe in most task functions.\n\n\nTask Priority\n\n\nAs a preemptive, multitasking RTOS, Mynewt decides which tasks to run based on which has a higher \npriority; the highest priority being 0 and the lowest 255. Thus, before initializing ou
r task, we \nmust choose a priority defined as a macro variable.\n\n\nLet\u2019s set the priority of \nwork_task\n to 0, because everyone knows that work is more important than blinking.\n\n\n \n#define WORK_TASK_PRIO (0)\n\n\n\n\n\n\nInitialization\n\n\nTo initialize a new task we use \nos_task_init()\n \nwhich takes a number of arguments including our new task function, stack, and priority. Much like \nblinky_task\n, \nwe\u2019re going to initialize \nwork_task\n inside \ninit_tasks\n to keep our main function clean.\n\n\nint\n\n\ninit_tasks\n(\nvoid\n)\n{\n \n/* \u2026 */\n\n \nos_task_init\n(\nwork_task\n, \nwork\n, \nwork_task_handler\n, \nNULL\n,\n \nWORK_TASK_PRIO\n, \nOS_WAIT_FOREVER\n, \nwork_stack\n,\n \nWORK_STACK_SIZE\n);\n\n \ntasks_initialized\n \n=\n \n1\n;\n \nreturn\n \n0\n;\n}\n\n\n\n\n\nAnd that\u2019s it! Now run your application using the newt run command.\n\n\n$ newt run arduino_blinky 0.0.0\n\n\n\n\n\nWhen GDB appears press C
then Enter to continue and \u2026 \nwait, why doesn't our LED blink anymore?\n\n\nReview\n\n\nBefore we run our new app, let\u2019s review what we need in order to create a task. This is a general case for a new task called mytask:\n\n\n1)\n Define a new task, task stack, and priority:\n\n\n/* My Task */\n\n\nstruct\n \nos_task\n \nmytask\n\n\n/* My Task Stack */\n\n\n#define MYTASK_STACK_SIZE OS_STACK_ALIGN(256)\n\n\nos_stack_t\n \nmytask_stack\n[\nMYTASK_STACK_SIZE\n];\n\n/* My Task Priority */\n\n\n#define MYTASK_PRIO (0)\n\n\n\n\n\n\n2)\n Define task function:\n\n\nvoid\n \n\nmytask_handler\n(\nvoid\n \n*arg\n)\n{\n \nwhile\n (\n1\n) {\n \n/* ... */\n\n }\n}\n\n\n\n\n\n3)\n Initialize task before calling \nos_start()\n:\n\n\nos_task_init\n(\nmytask\n, \nmytask\n, \nmytask_handler\n, \nNULL\n, \n \nMYTASK_PRIO\n, \nOS_WAIT_FOREVER\n, \nmytask_stack\n,\n \nMYTASK_STACK_SIZE\n);\n\n\n\n\n\nTask Priority, Preempting, and Context Switching\n\n\nA preem
ptive RTOS is one in which a higher priority task that is \nready to run\n will preempt (i.e. take the \nplace of) the lower priority task which is \nrunning\n. When a lower priority task is preempted by a higher \npriority task, the lower priority task\u2019s context data (stack pointer, registers, etc.) is saved and the new \ntask is switched in.\n\n\nIn our example, \nwork_task\n has a higher priority than \nblinky_task\n and, because it is never put into a \n\nsleep\n state, holds the processor focus on its context. Let\u2019s give \nwork_task\n a delay and some simulated \nwork to keep it busy. Because the delay is measured in os ticks, the actual number of ticks per second is \ndependent on the board. Therefore, we multiply \nOS_TICKS_PER_SEC\n, which is defined in the MCU, by the \nnumber of seconds we wish to delay.\n\n\nvoid\n\n\nwork_task_handler\n(\nvoid\n \n*arg\n)\n{\n \nstruct\n \nos_task\n \n*t\n;\n\n \ng_led_pin\n \n=\n \nLED_BLINK_PIN\n;\n \nhal_gpio_init_o
ut\n(\ng_led_pin\n, \n1\n);\n\n \nwhile\n (\n1\n) {\n \nt\n \n=\n \nos_sched_get_current_t\n:ask\n();\n \nassert\n(\nt-\nt_func\n \n==\n \nwork_task_handler\n);\n \n/* Do work... */\n\n \nint\n \ni\n;\n \nfor\n(\ni\n \n=\n \n0\n; \ni\n \n \n1000000\n; \n++i\n) {\n \n/* Simulate doing a noticeable amount of work */\n\n \nhal_gpio_set\n(\ng_led_pin\n);\n }\n \nos_time_delay\n(\n3\n*OS_TICKS_PER_SECOND\n);\n }\n}\n\n\n\n\n\nIn order to notice the LED changing, modify the time delay in \nblinky_task_handler()\n to blink at a higher frequency.\n\n\nos_time_delay\n(\nOS_TICKS_PER_SEC/\n10\n);\n\n\n\n\n\nBefore we run the app, let\u2019s predict the behavior. With the newest additions to \nwork_task_handler()\n, \nour first action will be to sleep for three seconds. This will allow \nblinky_task\n to take over the CPU \nand blink to its heart\u2019s content. After three seconds, \nwork_task\n will wake up and be m
ade \nready to run\n, \ncausing it to preempt \nblinky_task\n. The LED will then remain lit for a short period while \nwork_task\n \nloops, then blink again for another three seconds while \nwork_task\n sleeps. \n\n\nVoila, you should see that our prediction was correct! \n\n\nPriority Management Considerations\n\n\nWhen projects grow in scope, from blinking LEDs into more sophisticated applications, the number of \ntasks needed increases alongside complexity. It remains important, then, that each of our tasks is \ncapable of doing its work within a reasonable amount of time.\n\n\nSome tasks, such as the Shell task, execute quickly and require almost instantaneous response. Therefore, \nthe Shell task should be given a high priority. On the other hand, tasks which may be communicating over \na network, or processing data, should be given a low priority in order to not hog the CPU.\n\n\nThe diagram below showcases the different scheduling patterns we. would expect from swapping blink
y and \nwork tasks priorities.\n\n\n\n\nIn the second case where \nblinky_task\n has a higher priority, the \u201cwork\u201d done by \nwork_task\n would be \nexecuted during the millisecond delays in \nblinky_task\n, saving us idle time compared to the first case.\n\n\nNote:\n Defining the same priority for two tasks leads to somewhat undefined behavior and should be avoided.\n\n\nComparing Priority Strategies\n\n\nInstead of stepping through a bunch of changes to our blinky app, clone my task lesson application from \ngithub and copy an existing target.\n\n\nChange directory into apps and clone the repository to get our new\nfiles:\n\n\n$ cd apps\n$ git clone https://github.com/bgiori/mynewt_tasks_lesson.git\n\n\n\n\n\nChange directory back to your project root and copy the arduino_blinky target to a new target called task_tgt.\n\n\n$\n \nnewt\n \ntarget\n \ncopy\n \narduino_blinky\n \ntask_tgt\n\n\n\n\n\n\nSet a new app location.\n\n\n$\n \nnewt\n \ntarget\n \nset\n \ntask_tgt\n
\napp=apps/mynewt_tasks_lesson\n\n\n\n\n\n\nNow let\u2019s take a look at our new code. First, notice that we have abandoned blinking, instead choosing t\no use the \nconsole\n and \nshell\n \nto follow our tasks through execution.\n\n\nAdditionally, we have a number of different tasks:\n\n\n\n\n\n\nTask A\n (\na_task\n):\n\n\n\n\nPriority\n: 3 \u2192 2\n\n\nDescription\n: Task A is supposed to represent a task which frequently does a small amount \nof work, such as one which rapidly polls a sensor for data. Much like \nblinky_task\n, Task A will \nloop 10,000 times then wait 1 millisecond. Priority is changed by \ntimer_task\n after the first simulation.\n\n\n\n\n\n\n\n\nTask B\n (\nb_task\n):\n\n\n\n\nPriority\n: 2 \u2192 3\n\n\nDescription\n: Task B is supposed to represent a task which does a large amount of work \nrelatively infrequently, such as one which sends/receives data from the cloud. Like work_task, \nTask B will loop 1,000,000 times then wait 3 seconds. Priority is cha
nged by timer_task after \nthe first simulation.\n\n\n\n\n\n\n\n\nTimer Task\n (\ntimer_task\n):\n\n\n\n\nPriority\n: 1\n\n\nDescription\n: With default settings, Timer Task will wait 20 seconds then print the first \nsimulations data for Task A and B. Timer task will then swap A and B\u2019s priorities and restart the \nsimulation. After the second simulation, timer will again print simulation data then compare the \ntwo and calculate a final speedup (simulation2 / simulation1).\n\n\n\n\n\n\n\n\nShell Task\n:\n\n\n\n\nPriority\n: 0\n\n\nDescription\n: Task used by Shell behind the scenes to communicate with the serial port.\n\n\n\n\n\n\n\n\nConnecting to the Serial Console\n\n\nBefore running our new app, we must first connect to the serial console. First make sure the \nmynewt_arduino_zero repository is set to the develop branch. (Remove once changes have been \nmoved to master). \n\n\n$ cd repos/mynewt_arduino_zero\n$ git checkout develop\n\n\n\n\n\nOpen a new terminal window and
list your serial connections to find our Arduino.\n\n\n$\n \nls\n \n/dev/tty\n.\n*\n\n\n\n/dev/tty\n.\nBluetooth-Incoming-Port\n \n/dev/tty\n.\nusbmodem14132\n\n\n\n\n\n\nIn the same window, connect to the serial port using a serial communication program. \nIn this case I\u2019ll be using mincom as it can scroll through output.\n\n\n$\n \nminicom\n \n-D\n \n/dev/tty\n.\nusbmodem14132\n \n-b\n \n115200\n\n\n\n\n\n\nIf you see minicom welcome you, you\u2019re ready to move on!\n\n\nOutput Analysis\n\n\nRun our new target, task_tgt, and you should see an output similar to this:\n\n\nStarting First Simulation...\n1: Task B: 0% \n78: Task B: 1% \n155: Task B: 2% \n257: Task B: 3% \n359: Task B: 4% \n461: Task B: 5% \n\n\nsnip\n\n\n========== Timer Expired ==========\n\n \n Task A \n\n Priority: 3\n Loop count: 162849\n Cycle count: 16.28\n Run time: 1.40 sec\n\n \n Task B \n\n Priority: 2\n Loop count: 1345852\n Cycle count: 1.34\n Run time: 17.0 sec\n\n
Total loops: 1508709\n\n20023: Switching priorities and restarting...\n20111: Task A looped\n20113: Task B: 0% \n20191: Task B: 1% \n20297: Task A looped\n20356: Task B: 2% \n20483: Task A looped\n20545: Task B: 3% \n20669: Task A looped\n20734: Task B: 4% \n20855: Task A looped\n20923: Task B: 5% \n\n\nsnip\n\n\n========== Timer Expired ==========\n\n \n Task A \n\n Priority: 2\n Loop count: 1080000\n Cycle count: 108.0\n Run time: 9.28 sec\n\n \n Task B \n\n Priority: 3\n Loop count: 830356\n Cycle count: 0.83\n Run time: 10.72 sec\n\n Total loops: 1910404\n\n40058:\n\n Final Speedup (Sim2 / Sim1): 1.26\n\n\n\n\n\nThe console output reaffirms our previous prediction and makes both the scheduling differences \nand subsequent efficiency boost far more apparent. Let\u2019s take a look at scheduling differences \nbefore we delve into efficiency.\n\n\nIn the first case, where Task B\u2019s priority is higher than that of Task A, we see A get
starved \nby Task B\u2019s long execution time. \nStarvation\n occurs when one task hogs the processor, essentially \n\u201cstarving\u201d other tasks which also need to run. At the end of the first 20 second simulation period, \nTask A has only run for 1.4 seconds compared to task B\u2019s 17 second running time \u2013 ouch. As explained \nbefore, processes which are expected to run for long periods of time (e.g. network communication, \ndata processing) should be given higher priorities in order to combat starvation.\n\n\nIn the second simulation with priorities swapped, we can see Task B only running during the \nmillisecond delays when Task A is \nsleeping\n. Although having Task B only run during these \ndelays slows its execution time, we benefit from un-starving Task A and using the processor \nat a higher efficiency.\n\n\nThe bottom line speedup gives us an immediate and clear indication that we have improved our \nability to process work (i.e throughput). In our second run,
we processed an additional 400,000 \nloop iterations, equating to a 26% increase in efficiency. On a standard multi-core processor \nfound in every modern PC, a 1.26 speedup would be an ok result to adding multithreading capabilities \nto a serial program. However, we accomplished this by simply setting priorities on a single core \nprocessor \u2013 not bad!\n\n\nNOTE: Usually the the term \u201cspeedup\u201d is used within a parallel programming context and refers \nto the change in execution time between a serial and parallel program executing over the same \nproblem. In this case we\u2019re using the term loosely to illustrate the priority change\u2019s effect \non scheduling and throughput in our specific context.\n\n\nEfficiency Isn\u2019t Everything\n\n\nUsing the processor during every OS tick isn\u2019t always the best course of action. If we modify \nTask A\u2019s delay to a tenth of a millisecond and turn off the console output, we can boost our \nspeedup to 1.44. This, h
owever, reduces our ability to process work from Task B who ends up \nonly completing 18% of its work cycle after the second simulation. That would mean, at that \nrate, Task B would take over a minute to finish one cycle.\n\n\nFeel free to play around with the testing parameters to study the different changes yourself!\n\n\nConclusion\n\n\nMoving forward, tasks are just the tip of the iceberg. The \nscheduler\n, \n\nevent queues\n, \n\nsemaphores\n, and \n\nmutexes\n also add to tasks functionality, \nincreasing our ability as the developer to control greater numbers of tasks more intricately. For \nexample, when we switch the tasks priority, we have to tell the scheduler that our tasks priorities \nhave changed, allowing us us to use priorities dynamically. When running multiple tasks, logging \nthrough either the built-in \nLogs\n module \n(not covered in this lesson) or through the serial console/shell can be very useful for debugging \nyour application. In the end, the way you
manage your tasks depends on the context of your \napplication. You should assign priorities based on execution time, urgency, and frequency, among \nother things.\n\n\nKeep blinking and happy hacking!",
"title": "Tasks and Priority Management"
},
{
"location": "/os/tutorials/tasks_lesson/#core-os-lesson-tasks-and-priority-management",
- "text": "Target Platform: Arduino M0 Pro (or legacy Arduino Zero or Zero Pro, but not Arduino M0) This lesson is designed to teach core OS concepts and strategies encountered when building applications using Mynewt. Specifically, this lesson will cover tasks, simple multitasking, and priority management running on an Arduino M0 Pro.",
+ "text": "Target Platform: Arduino M0 Pro (or legacy Arduino Zero or Zero Pro, but not Arduino M0) This lesson is designed to teach core OS concepts and strategies encountered when \nbuilding applications using Mynewt. Specifically, this lesson will cover tasks, \nsimple multitasking, and priority management running on an Arduino M0 Pro.",
"title": "Core OS Lesson: Tasks and Priority Management"
},
{
"location": "/os/tutorials/tasks_lesson/#prerequisites",
- "text": "Before starting, you should read about Mynewt in the Introduction section and complete the QuickStart guide and the Blinky tutorial. Furthermore, it may be helpful to take a peek at the task documentation for additional insights.",
+ "text": "Before starting, you should read about Mynewt in the Introduction \nsection and complete the QuickStart \nguide and the Blinky tutorial. \nFurthermore, it may be helpful to take a peek at the task documentation \nfor additional insights.",
"title": "Prerequisites"
},
{
@@ -987,32 +987,32 @@
},
{
"location": "/os/tutorials/tasks_lesson/#build-your-application",
- "text": "To save time, we will simply modify the Blinky app as it has the basic task structure already implemented. Follow the Arduino Zero Blinky tutorial to create a new project and build your bootloader and application. Finally, build and load the application to your Arduino to verify that everything is in order. Now let\u2019s get started!",
+ "text": "To save time, we will simply modify the Blinky app. We'll add the Task Management code to\nthe Blinky app. Follow the Arduino Zero Blinky tutorial \nto create a new project and build your bootloader and application. Finally, build and \nload the application to your Arduino to verify that everything is in order. Now let\u2019s get started!",
"title": "Build Your Application"
},
{
"location": "/os/tutorials/tasks_lesson/#create-a-new-task",
- "text": "The purpose of this section is to give an introduction to the important aspects of tasks and how to properly initialize them. First, let\u2019s define a second task called work_task in main.c (located in apps/blinky/src): struct os_task work_task ; A task is represented by the os_task struct which will hold the task\u2019s information (name, state, priority, etc.). A task is made up of two main elements, a task function (also known as a task handler) and a task stack. Next, let\u2019s take a look at what is required to initialize our new task.",
+ "text": "The purpose of this section is to give an introduction to the important aspects of tasks \nand how to properly initialize them. First, let\u2019s define a second task called work_task \nin main.c (located in apps/blinky/src): struct os_task work_task ; A task is represented by the os_task \nstruct which will hold the task\u2019s information (name, state, priority, etc.). A task is made up of two \nmain elements, a task function (also known as a task handler) and a task stack. Next, let\u2019s take a look at what is required to initialize our new task.",
"title": "Create a New Task"
},
{
"location": "/os/tutorials/tasks_lesson/#task-stack",
- "text": "The task stack is an array of type os_stack_t which holds the program stack frames. Mynewt gives us the ability to set the stack size for a task giving the application developer room to optimize memory usage. Since we\u2019re not short on memory, our blinky_stack and work_stack are plenty large for the purpose of this lesson. Notice that the elements in our task stack are of type os_stack_t which are generally 32 bits, making our entire stack 1024 Bytes. #define WORK_STACK_SIZE OS_STACK_ALIGN(256) \n os_stack_t work_stack [ WORK_STACK_SIZE ]; Note: The OS_STACK_ALIGN macro is used to align the stack based on the hardware architecture.",
+ "text": "The task stack is an array of type os_stack_t which holds the program stack frames. Mynewt gives \nus the ability to set the stack size for a task giving the application developer room to optimize \nmemory usage. Since we\u2019re not short on memory, our blinky_stack and work_stack are plenty large \nfor the purpose of this lesson. Notice that the elements in our task stack are of type os_stack_t \nwhich are generally 32 bits, making our entire stack 1024 Bytes. #define WORK_STACK_SIZE OS_STACK_ALIGN(256) \n os_stack_t work_stack [ WORK_STACK_SIZE ]; Note: The OS_STACK_ALIGN macro is used to align the stack based on the hardware architecture.",
"title": "Task Stack"
},
{
"location": "/os/tutorials/tasks_lesson/#task-function",
- "text": "The task function is essentially an infinite loop which waits for some \u201cevent\u201d to wake it up. In our Blinky app the task function, named blinky_task_handler() , is initially called when we call os_start() in main() . In general, the task function is where the majority of work is done by a task. Let\u2019s write a task function for work_task called work_task_handler() : void work_task_handler ( void *arg )\n{\n struct os_task *t ;\n\n g_led_pin = LED_BLINK_PIN ;\n hal_gpio_init_out ( g_led_pin , 1 );\n\n while ( 1 ) {\n t = os_sched_get_current_task ();\n assert ( t- t_func == work_task_handler );\n /* Do work... */ \n }\n} The task function is called when the task is initially put into the running state by the scheduler. We use an infinite loop to ensure that the task function never returns. Our assertion that the current task's handler is the same as our task handler is for ill
ustration purposes only and does not need to be in most task functions.",
+ "text": "The task function is essentially an infinite loop which waits for some \u201cevent\u201d to wake it up. In our \nBlinky app the task function, named blinky_task_handler() , is initially called when we call os_start() \nin main() . In general, the task function is where the majority of work is done by a task. Let\u2019s write \na task function for work_task called work_task_handler() : void work_task_handler ( void *arg )\n{\n struct os_task *t ;\n\n g_led_pin = LED_BLINK_PIN ;\n hal_gpio_init_out ( g_led_pin , 1 );\n\n while ( 1 ) {\n t = os_sched_get_current_task ();\n assert ( t- t_func == work_task_handler );\n /* Do work... */ \n }\n} The task function is called when the task is initially put into the running state by the scheduler. \nWe use an infinite loop to ensure that the task function never returns. Our assertion that the current \ntask's handler is the same as our task handler
is for illustration purposes only and does not need to \nbe in most task functions.",
"title": "Task Function"
},
{
"location": "/os/tutorials/tasks_lesson/#task-priority",
- "text": "As a preemptive, multitasking RTOS, Mynewt decides which tasks to run based on which has a higher priority; the highest priority being 0 and the lowest 255. Thus, before initializing our task, we must choose a priority defined as a macro variable. Let\u2019s set the priority of work_task to 0, because everyone knows that work is more important than blinking. #define WORK_TASK_PRIO (0)",
+ "text": "As a preemptive, multitasking RTOS, Mynewt decides which tasks to run based on which has a higher \npriority; the highest priority being 0 and the lowest 255. Thus, before initializing our task, we \nmust choose a priority defined as a macro variable. Let\u2019s set the priority of work_task to 0, because everyone knows that work is more important than blinking. #define WORK_TASK_PRIO (0)",
"title": "Task Priority"
},
{
"location": "/os/tutorials/tasks_lesson/#initialization",
- "text": "To initialize a new task we use os_task_init() which takes a number of arguments including our new task function, stack, and priority. Much like blinky_task , we\u2019re going to initialize work_task inside init_tasks to keep our main function clean. int init_tasks ( void )\n{\n /* \u2026 */ \n os_task_init ( work_task , work , work_task_handler , NULL ,\n WORK_TASK_PRIO , OS_WAIT_FOREVER , work_stack ,\n WORK_STACK_SIZE );\n\n tasks_initialized = 1 ;\n return 0 ;\n} And that\u2019s it! Now run your application using the newt run command. $ newt run arduino_blinky 0.0.0 When GDB appears press C then Enter to continue and \u2026 wait, why doesn't our LED blink anymore?",
+ "text": "To initialize a new task we use os_task_init() \nwhich takes a number of arguments including our new task function, stack, and priority. Much like blinky_task , \nwe\u2019re going to initialize work_task inside init_tasks to keep our main function clean. int init_tasks ( void )\n{\n /* \u2026 */ \n os_task_init ( work_task , work , work_task_handler , NULL ,\n WORK_TASK_PRIO , OS_WAIT_FOREVER , work_stack ,\n WORK_STACK_SIZE );\n\n tasks_initialized = 1 ;\n return 0 ;\n} And that\u2019s it! Now run your application using the newt run command. $ newt run arduino_blinky 0.0.0 When GDB appears press C then Enter to continue and \u2026 wait, why doesn't our LED blink anymore?",
"title": "Initialization"
},
{
@@ -1022,42 +1022,42 @@
},
{
"location": "/os/tutorials/tasks_lesson/#task-priority-preempting-and-context-switching",
- "text": "A preemptive RTOS is one in which a higher priority task that is ready to run will preempt (i.e. take the place of) the lower priority task which is running . When a lower priority task is preempted by a higher priority task, the lower priority task\u2019s context data (stack pointer, registers, etc.) is saved and the new task is switched in. In our example, work_task has a higher priority than blinky_task and, because it is never put into a sleep state, holds the processor focus on its context. Let\u2019s give work_task a delay and some simulated work to keep it busy. Because the delay is measured in os ticks, the actual number of ticks per second is dependent on the board. Therefore, we multiply OS_TICKS_PER_SEC , which is defined in the MCU, by the number of seconds we wish to delay. void work_task_handler ( void *arg )\n{\n struct os_task *t ;\n\n g_led_pin = LED_BLINK_PIN ;\n hal_gpio_init_out ( g_led_pin , 1 );\n\n
while ( 1 ) {\n t = os_sched_get_current_t :ask ();\n assert ( t- t_func == work_task_handler );\n /* Do work... */ \n int i ;\n for ( i = 0 ; i 1000000 ; ++i ) {\n /* Simulate doing a noticeable amount of work */ \n hal_gpio_set ( g_led_pin );\n }\n os_time_delay ( 3 *OS_TICKS_PER_SECOND );\n }\n} In order to notice the LED changing, modify the time delay in blinky_task_handler() to blink at a higher frequency. os_time_delay ( OS_TICKS_PER_SEC/ 10 ); Before we run the app, let\u2019s predict the behavior. With the newest additions to work_task_handler() , our first action will be to sleep for three seconds. This will allow blinky_task to take over the CPU and blink to its heart\u2019s content. After three seconds, work_task will wake up and be made ready to run , causing it to preempt blinky_task . The LED will then remain lit for a short period while work_task loop
s, then blink again for another three seconds while work_task sleeps. Voila, you should see that our prediction was correct!",
+ "text": "A preemptive RTOS is one in which a higher priority task that is ready to run will preempt (i.e. take the \nplace of) the lower priority task which is running . When a lower priority task is preempted by a higher \npriority task, the lower priority task\u2019s context data (stack pointer, registers, etc.) is saved and the new \ntask is switched in. In our example, work_task has a higher priority than blinky_task and, because it is never put into a sleep state, holds the processor focus on its context. Let\u2019s give work_task a delay and some simulated \nwork to keep it busy. Because the delay is measured in os ticks, the actual number of ticks per second is \ndependent on the board. Therefore, we multiply OS_TICKS_PER_SEC , which is defined in the MCU, by the \nnumber of seconds we wish to delay. void work_task_handler ( void *arg )\n{\n struct os_task *t ;\n\n g_led_pin = LED_BLINK_PIN ;\n hal_gpio_init_out ( g_led_pin ,
1 );\n\n while ( 1 ) {\n t = os_sched_get_current_t :ask ();\n assert ( t- t_func == work_task_handler );\n /* Do work... */ \n int i ;\n for ( i = 0 ; i 1000000 ; ++i ) {\n /* Simulate doing a noticeable amount of work */ \n hal_gpio_set ( g_led_pin );\n }\n os_time_delay ( 3 *OS_TICKS_PER_SECOND );\n }\n} In order to notice the LED changing, modify the time delay in blinky_task_handler() to blink at a higher frequency. os_time_delay ( OS_TICKS_PER_SEC/ 10 ); Before we run the app, let\u2019s predict the behavior. With the newest additions to work_task_handler() , \nour first action will be to sleep for three seconds. This will allow blinky_task to take over the CPU \nand blink to its heart\u2019s content. After three seconds, work_task will wake up and be made ready to run , \ncausing it to preempt blinky_task . The LED will then remain lit for a short period whil
e work_task \nloops, then blink again for another three seconds while work_task sleeps. Voila, you should see that our prediction was correct!",
"title": "Task Priority, Preempting, and Context Switching"
},
{
"location": "/os/tutorials/tasks_lesson/#priority-management-considerations",
- "text": "When projects grow in scope, from blinking LEDs into more sophisticated applications, the number of tasks needed increases alongside complexity. It remains important, then, that each of our tasks is capable of doing its work within a reasonable amount of time. Some tasks, such as the Shell task, execute quickly and require almost instantaneous response. Therefore, the Shell task should be given a high priority. On the other hand, tasks which may be communicating over a network, or processing data, should be given a low priority in order to not hog the CPU. The diagram below showcases the different scheduling patterns we. would expect from swapping blinky and work tasks priorities. In the second case where blinky_task has a higher priority, the \u201cwork\u201d done by work_task would be executed during the millisecond delays in blinky_task , saving us idle time compared to the first case. Note: Defining the same priority for two tasks leads to somewha
t undefined behavior and should be avoided.",
+ "text": "When projects grow in scope, from blinking LEDs into more sophisticated applications, the number of \ntasks needed increases alongside complexity. It remains important, then, that each of our tasks is \ncapable of doing its work within a reasonable amount of time. Some tasks, such as the Shell task, execute quickly and require almost instantaneous response. Therefore, \nthe Shell task should be given a high priority. On the other hand, tasks which may be communicating over \na network, or processing data, should be given a low priority in order to not hog the CPU. The diagram below showcases the different scheduling patterns we. would expect from swapping blinky and \nwork tasks priorities. In the second case where blinky_task has a higher priority, the \u201cwork\u201d done by work_task would be \nexecuted during the millisecond delays in blinky_task , saving us idle time compared to the first case. Note: Defining the same priority for two tasks lead
s to somewhat undefined behavior and should be avoided.",
"title": "Priority Management Considerations"
},
{
"location": "/os/tutorials/tasks_lesson/#comparing-priority-strategies",
- "text": "Instead of stepping through a bunch of changes to our blinky app, clone my task lesson application from github and copy an existing target. Change directory into apps and clone the repository to get our new\nfiles: $ cd apps\n$ git clone https://github.com/bgiori/mynewt_tasks_lesson.git Change directory back to your project root and copy the arduino_blinky target to a new target called task_tgt. $ newt target copy arduino_blinky task_tgt Set a new app location. $ newt target set task_tgt app=apps/mynewt_tasks_lesson Now let\u2019s take a look at our new code. First, notice that we have abandoned blinking, instead choosing to use the console and shell to follow our tasks through execution. Additionally, we have a number of different tasks: Task A ( a_task ): Priority : 3 \u2192 2 Description : Task A is supposed to represent a task which frequently does a small amount of work, such as one which rapidly polls a sensor for
data. Much like blinky_task , Task A will loop 10,000 times then wait 1 millisecond. Priority is changed by timer_task after the first simulation. Task B ( b_task ): Priority : 2 \u2192 3 Description : Task B is supposed to represent a task which does a large amount of work relatively infrequently, such as one which sends/receives data from the cloud. Like work_task, Task B will loop 1,000,000 times then wait 3 seconds. Priority is changed by timer_task after the first simulation. Timer Task ( timer_task ): Priority : 1 Description : With default settings, Timer Task will wait 20 seconds then print the first simulations data for Task A and B. Timer task will then swap A and B\u2019s priorities and restart the simulation. After the second simulation, timer will again print simulation data then compare the two and calculate a final speedup (simulation2 / simulation1). Shell Task : Priority : 0 Description : Task used by Shell behind the scenes to communicate
with the serial port.",
+ "text": "Instead of stepping through a bunch of changes to our blinky app, clone my task lesson application from \ngithub and copy an existing target. Change directory into apps and clone the repository to get our new\nfiles: $ cd apps\n$ git clone https://github.com/bgiori/mynewt_tasks_lesson.git Change directory back to your project root and copy the arduino_blinky target to a new target called task_tgt. $ newt target copy arduino_blinky task_tgt Set a new app location. $ newt target set task_tgt app=apps/mynewt_tasks_lesson Now let\u2019s take a look at our new code. First, notice that we have abandoned blinking, instead choosing t\no use the console and shell \nto follow our tasks through execution. Additionally, we have a number of different tasks: Task A ( a_task ): Priority : 3 \u2192 2 Description : Task A is supposed to represent a task which frequently does a small amount \nof work, such as one which rapidly polls a sen
sor for data. Much like blinky_task , Task A will \nloop 10,000 times then wait 1 millisecond. Priority is changed by timer_task after the first simulation. Task B ( b_task ): Priority : 2 \u2192 3 Description : Task B is supposed to represent a task which does a large amount of work \nrelatively infrequently, such as one which sends/receives data from the cloud. Like work_task, \nTask B will loop 1,000,000 times then wait 3 seconds. Priority is changed by timer_task after \nthe first simulation. Timer Task ( timer_task ): Priority : 1 Description : With default settings, Timer Task will wait 20 seconds then print the first \nsimulations data for Task A and B. Timer task will then swap A and B\u2019s priorities and restart the \nsimulation. After the second simulation, timer will again print simulation data then compare the \ntwo and calculate a final speedup (simulation2 / simulation1). Shell Task : Priority : 0 Description : Task used by Shell behind the
scenes to communicate with the serial port.",
"title": "Comparing Priority Strategies"
},
{
"location": "/os/tutorials/tasks_lesson/#connecting-to-the-serial-console",
- "text": "Before running our new app, we must first connect to the serial console. First make sure the mynewt_arduino_zero repository is set to the develop branch. (Remove once changes have been moved to master). $ cd repos/mynewt_arduino_zero\n$ git checkout develop Open a new terminal window and list your serial connections to find our Arduino. $ ls /dev/tty . * /dev/tty . Bluetooth-Incoming-Port /dev/tty . usbmodem14132 In the same window, connect to the serial port using a serial communication program. In this case I\u2019ll be using mincom as it can scroll through output. $ minicom -D /dev/tty . usbmodem14132 -b 115200 If you see minicom welcome you, you\u2019re ready to move on!",
+ "text": "Before running our new app, we must first connect to the serial console. First make sure the \nmynewt_arduino_zero repository is set to the develop branch. (Remove once changes have been \nmoved to master). $ cd repos/mynewt_arduino_zero\n$ git checkout develop Open a new terminal window and list your serial connections to find our Arduino. $ ls /dev/tty . * /dev/tty . Bluetooth-Incoming-Port /dev/tty . usbmodem14132 In the same window, connect to the serial port using a serial communication program. \nIn this case I\u2019ll be using mincom as it can scroll through output. $ minicom -D /dev/tty . usbmodem14132 -b 115200 If you see minicom welcome you, you\u2019re ready to move on!",
"title": "Connecting to the Serial Console"
},
{
"location": "/os/tutorials/tasks_lesson/#output-analysis",
- "text": "Run our new target, task_tgt, and you should see an output similar to this: Starting First Simulation...\n1: Task B: 0% \n78: Task B: 1% \n155: Task B: 2% \n257: Task B: 3% \n359: Task B: 4% \n461: Task B: 5% snip \n\n========== Timer Expired ==========\n\n Task A \n Priority: 3\n Loop count: 162849\n Cycle count: 16.28\n Run time: 1.40 sec\n\n Task B \n Priority: 2\n Loop count: 1345852\n Cycle count: 1.34\n Run time: 17.0 sec\n\n Total loops: 1508709\n\n20023: Switching priorities and restarting...\n20111: Task A looped\n20113: Task B: 0% \n20191: Task B: 1% \n20297: Task A looped\n20356: Task B: 2% \n20483: Task A looped\n20545: Task B: 3% \n20669: Task A looped\n20734: Task B: 4% \n20855: Task A looped\n20923: Task B: 5% snip \n\n========== Timer Expired ==========\n\n Task A \n Priority: 2\n Loop count: 1080000\n Cycle count: 108.0\n Run time: 9.28 sec\n\n Task B \n Prio
rity: 3\n Loop count: 830356\n Cycle count: 0.83\n Run time: 10.72 sec\n\n Total loops: 1910404\n\n40058:\n\n Final Speedup (Sim2 / Sim1): 1.26 The console output reaffirms our previous prediction and makes both the scheduling differences and subsequent efficiency boost far more apparent. Let\u2019s take a look at scheduling differences before we delve into efficiency. In the first case, where Task B\u2019s priority is higher than that of Task A, we see A get starved by Task B\u2019s long execution time. Starvation occurs when one task hogs the processor, essentially \u201cstarving\u201d other tasks which also need to run. At the end of the first 20 second simulation period, Task A has only run for 1.4 seconds compared to task B\u2019s 17 second running time \u2013 ouch. As explained before, processes which are expected to run for long periods of time (e.g. network communication, data processing) should be given higher priorities in order to combat starvation. In the second
simulation with priorities swapped, we can see Task B only running during the millisecond delays when Task A is sleeping . Although having Task B only run during these delays slows its execution time, we benefit from un-starving Task A and using the processor at a higher efficiency. The bottom line speedup gives us an immediate and clear indication that we have improved our ability to process work (i.e throughput). In our second run, we processed an additional 400,000 loop iterations, equating to a 26% increase in efficiency. On a standard multi-core processor found in every modern PC, a 1.26 speedup would be an ok result to adding multithreading capabilities to a serial program. However, we accomplished this by simply setting priorities on a single core processor \u2013 not bad! NOTE: Usually the the term \u201cspeedup\u201d is used within a parallel programming context and refers to the change in execution time between a serial and parallel program executing over the same probl
em. In this case we\u2019re using the term loosely to illustrate the priority change\u2019s effect on scheduling and throughput in our specific context.",
+ "text": "Run our new target, task_tgt, and you should see an output similar to this: Starting First Simulation...\n1: Task B: 0% \n78: Task B: 1% \n155: Task B: 2% \n257: Task B: 3% \n359: Task B: 4% \n461: Task B: 5% snip \n\n========== Timer Expired ==========\n\n Task A \n Priority: 3\n Loop count: 162849\n Cycle count: 16.28\n Run time: 1.40 sec\n\n Task B \n Priority: 2\n Loop count: 1345852\n Cycle count: 1.34\n Run time: 17.0 sec\n\n Total loops: 1508709\n\n20023: Switching priorities and restarting...\n20111: Task A looped\n20113: Task B: 0% \n20191: Task B: 1% \n20297: Task A looped\n20356: Task B: 2% \n20483: Task A looped\n20545: Task B: 3% \n20669: Task A looped\n20734: Task B: 4% \n20855: Task A looped\n20923: Task B: 5% snip \n\n========== Timer Expired ==========\n\n Task A \n Priority: 2\n Loop count: 1080000\n Cycle count: 108.0\n Run time: 9.28 sec\n\n Task B \n Prio
rity: 3\n Loop count: 830356\n Cycle count: 0.83\n Run time: 10.72 sec\n\n Total loops: 1910404\n\n40058:\n\n Final Speedup (Sim2 / Sim1): 1.26 The console output reaffirms our previous prediction and makes both the scheduling differences \nand subsequent efficiency boost far more apparent. Let\u2019s take a look at scheduling differences \nbefore we delve into efficiency. In the first case, where Task B\u2019s priority is higher than that of Task A, we see A get starved \nby Task B\u2019s long execution time. Starvation occurs when one task hogs the processor, essentially \n\u201cstarving\u201d other tasks which also need to run. At the end of the first 20 second simulation period, \nTask A has only run for 1.4 seconds compared to task B\u2019s 17 second running time \u2013 ouch. As explained \nbefore, processes which are expected to run for long periods of time (e.g. network communication, \ndata processing) should be given higher priorities in order to combat starvation.
In the second simulation with priorities swapped, we can see Task B only running during the \nmillisecond delays when Task A is sleeping . Although having Task B only run during these \ndelays slows its execution time, we benefit from un-starving Task A and using the processor \nat a higher efficiency. The bottom line speedup gives us an immediate and clear indication that we have improved our \nability to process work (i.e throughput). In our second run, we processed an additional 400,000 \nloop iterations, equating to a 26% increase in efficiency. On a standard multi-core processor \nfound in every modern PC, a 1.26 speedup would be an ok result to adding multithreading capabilities \nto a serial program. However, we accomplished this by simply setting priorities on a single core \nprocessor \u2013 not bad! NOTE: Usually the the term \u201cspeedup\u201d is used within a parallel programming context and refers \nto the change in execution time between a serial and parallel progr
am executing over the same \nproblem. In this case we\u2019re using the term loosely to illustrate the priority change\u2019s effect \non scheduling and throughput in our specific context.",
"title": "Output Analysis"
},
{
"location": "/os/tutorials/tasks_lesson/#efficiency-isnt-everything",
- "text": "Using the processor during every OS tick isn\u2019t always the best course of action. If we modify Task A\u2019s delay to a tenth of a millisecond and turn off the console output, we can boost our speedup to 1.44. This, however, reduces our ability to process work from Task B who ends up only completing 18% of its work cycle after the second simulation. That would mean, at that rate, Task B would take over a minute to finish one cycle. Feel free to play around with the testing parameters to study the different changes yourself!",
+ "text": "Using the processor during every OS tick isn\u2019t always the best course of action. If we modify \nTask A\u2019s delay to a tenth of a millisecond and turn off the console output, we can boost our \nspeedup to 1.44. This, however, reduces our ability to process work from Task B who ends up \nonly completing 18% of its work cycle after the second simulation. That would mean, at that \nrate, Task B would take over a minute to finish one cycle. Feel free to play around with the testing parameters to study the different changes yourself!",
"title": "Efficiency Isn\u2019t Everything"
},
{
"location": "/os/tutorials/tasks_lesson/#conclusion",
- "text": "Moving forward, tasks are just the tip of the iceberg. The scheduler , event queues , semaphores , and mutexes also add to tasks functionality, increasing our ability as the developer to control greater numbers of tasks more intricately. For example, when we switch the tasks priority, we have to tell the scheduler that our tasks priorities have changed, allowing us us to use priorities dynamically. When running multiple tasks, logging through either the built-in Logs module (not covered in this lesson) or through the serial console/shell can be very useful for debugging your application. In the end, the way you manage your tasks depends on the context of your application. You should assign priorities based on execution time, urgency, and frequency, among other things. Keep blinking and happy hacking!",
+ "text": "Moving forward, tasks are just the tip of the iceberg. The scheduler , event queues , semaphores , and mutexes also add to tasks functionality, \nincreasing our ability as the developer to control greater numbers of tasks more intricately. For \nexample, when we switch the tasks priority, we have to tell the scheduler that our tasks priorities \nhave changed, allowing us us to use priorities dynamically. When running multiple tasks, logging \nthrough either the built-in Logs module \n(not covered in this lesson) or through the serial console/shell can be very useful for debugging \nyour application. In the end, the way you manage your tasks depends on the context of your \napplication. You should assign priorities based on execution time, urgency, and frequency, among \nother things. Keep blinking and happy hacking!",
"title": "Conclusion"
},
{
"location": "/os/tutorials/wi-fi_on_arduino/",
- "text": "Start Wi-Fi on Arduino Zero\n\n\nThis tutorial walks you through the steps to get your Arduino board on a Wi-Fi network.\n\n\nNote:\n Wi-Fi support is currently available in the \ndevelop\n branch of Mynewt only. It will be merged into \nmaster\n branch when version 0.10 is released.\n\n\nPrerequisites\n\n\nBefore tackling this tutorial, it's best to read about Mynewt in the \nIntroduction\n section of this documentation.\n\n\nEquipment\n\n\nYou will need the following equipment\n\n\n\n\nAn Arduino Zero, Zero Pro or M0 Pro.\n\n\nNote:\n Mynewt has not been tested on Arduino M0 which has no internal debugger support.\n\n\nAn Arduino Wi-Fi Shield 101\n\n\nA computer that can connect to the Arduino board over USB\n\n\nA local Wi-Fi network that the computer is connected to and which the Arduino board can join.\n\n\nA USB cable (Type A to micro B) that can connect the computer to the Arduino (or a USB hub between the computer and the Arduino board)\n\n\nThe Mynewt R
elease\n\n\n\n\nInstall Mynewt and Newt\n\n\n\n\nIf you have not already done so, install Newt as shown in the \nNewt install tutorial\n.\n\n\nIf you installed Newt previously but need to update it, go to the newt git repo directory, pull the latest code from \ndevelop\n branch, and install the updated code.\n\n\n\n\n user@~/dev$ cd $GOPATH/src/mynewt.apache.org/newt\n user@~/dev/go/src/mynewt.apache.org/newt$ git remote -v\n origin https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git (fetch)\n origin https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git (push)\n user@~/dev/go/src/mynewt.apache.org/newt$ git pull origin develop\n remote: Counting objects: 59, done.\n \nsnip\n\n user@~/dev/go/src/mynewt.apache.org/newt$ cd newt\n user@~/dev/go/src/mynewt.apache.org/newt/newt$ go install\n user@~/dev$ cd ~/dev\n\n\n\n\n\n\n\nIf you have not already done so, create a project as shown in the Quick Start guide on how to \nCreate Your First
Project\n. Skip the testing and building the project steps in that tutorial since you will be defining a target for your Arduino board in this tutorial.\n\n\n\n\nLet's say your new project is named \narduinowifi\n. You will henceforth be working in that project directory.\n\n\n\n\nFetch External Packages, Set correct version to download\n\n\nMynewt uses source code provided directly from the chip manufacturer for\nlow level operations. Sometimes this code is licensed only for the specific manufacturer of the chipset and cannot live in the Apache Mynewt repository. That happens to be the case for the Arduino Zero board which uses Atmel SAMD21. Runtime's github repository hosts such external third-party packages and the Newt tool can fetch them.\n\n\nTo fetch the package with MCU support for Atmel SAMD21 for Arduino Zero from the Runtime git repository, you need to add\nthe repository to the \nproject.yml\n file in your base project directory (\narduinowifi\n).\n\n\nuser@~/dev/arduin
owifi$ vi project.yml\n\n\n\n\n\nHere is an example \nproject.yml\n file with the Arduino Zero repository\nadded. The sections with \nmynewt_arduino_zero\n that need to be added to\nyour project file are highlighted.\n\n\nAlso highlighted is the \n0-dev\n version for both the repositories to ensure code is downloaded from the \ndevelop\n branch.\n\n\n$ more project.yml\nproject.name: \nmy_project\n\n\nproject.repositories:\n - apache-mynewt-core\n\n - mynewt_arduino_zero\n\n\nrepository.apache-mynewt-core:\n type: github\n\n vers: 0-dev\n\n user: apache\n repo: incubator-mynewt-core\n\n\nrepository.mynewt_arduino_zero:\n\n type: github\n\n vers: 0-dev\n\n user: runtimeinc\n\n repo: mynewt_arduino_zero\n\n$\n\n\n\n\n\n\n\nOnce you've edited your \nproject.yml\n file, the next step is to install the\nproject dependencies, this can be done with the \nnewt install\n command\n(to see more output, provide the \n-v\n verbose option.):\n\n\n$ newt install\napac
he-mynewt-core\nmynewt_arduino_zero\n$\n\n\n\n\n\n\n\nCreate your bootloader target\n\n\nNext, you need to tell Newt what to build. For the Arduino Zero, we are going to\ngenerate both a bootloader, and an image target.\n\n\nTo generate the bootloader target, you need to specify the following options. The output of the commands (indicating success) have been suppressed for easier readability.\n\n\n$ newt target create arduino_boot\n$ newt target set arduino_boot bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero\n$ newt target set arduino_boot app=@apache-mynewt-core/apps/boot\n$ newt target set arduino_boot build_profile=optimized\n\n\n\n\n\n\n\nIf you have an Arduino Zero Pro or M0 Pro, you have to set the following next:\n\n\n$ newt target set arduino_boot features=arduino_zero_pro\n\n\n\n\n\nIf you have an Arduino Zero, you have to set the following instead:\n\n\n$ newt target set arduino_boot features=arduino_zero\n\n\n\n\n\n\n\nBuild your bootloader\n\n\nOnce you've configured the
bootloader target, the next step is to build the bootloader for your Arduino. You can do this by using the \nnewt build\n command:\n\n\n$ newt build arduino_boot\nCompiling boot.c\nArchiving boot.a\nCompiling fs_cli.c\nCompiling fs_dirent.c\nCompiling fs_file.c\nCompiling fs_mkdir.c\n\nsnip\n\nApp successfully built: ~/dev/arduinowifi/bin/arduino_boot/apps/boot/boot.elf\n\n\n\n\n\nIf this command finishes successfully, you have successfully built the Arduino\nbootloader, and the next step is to build your application for the Arduino\nboard.\n\n\n\n\nBuild your blinky app\n\n\nTo create and download your application, you create another target, this one pointing to the application you want to download to the Arduino board. In this tutorial, we will use the Wi-Fi application that comes in the arduino repository, \napps/winc1500_wifi\n:\n\n\nNote\n: Remember to set features to \narduino_zero\n if your board is Arduino Zero and not a Pro!\n\n\n$ newt target create arduino_wifi\n$ newt
target set arduino_wifi app=@mynewt_arduino_zero/apps/winc1500_wifi\n$ newt target set arduino_wifi bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero\n$ newt target set arduino_wifi build_profile=debug\n\n$ newt target set arduino_wifi features=arduino_zero_pro\n\n\n\n\n\n\n\nYou can now build the target, with \nnewt build\n:\n\n\n$ newt build arduino_wifi\nBuilding target targets/arduino_wifi\nCompiling main.c\nArchiving winc1500_wifi.a\nCompiling fs_cli.c\nCompiling fs_dirent.c\nCompiling fs_file.c\nCompiling fs_mkdir.c\n\nsnip\n\nLinking winc1500_wifi.elf\nApp successfully built: ~/dev/arduinowifi/bin/arduino_wifi/apps/winc1500_wifi/winc1500_wifi.elf\n\n\n\n\n\n Congratulations! \n You have successfully built your Wi-Fi application. Now it's time to load both the bootloader and application onto the target.\n\n\n\n\nConnec
<TRUNCATED>