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 2015/11/07 02:09:53 UTC
[3/4] incubator-mynewt-site git commit: add subcription details,
change blinky instructions for flash download
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/60d6afb2/site/chapter1/project1/index.html
----------------------------------------------------------------------
diff --git a/site/chapter1/project1/index.html b/site/chapter1/project1/index.html
index 4b00714..fe52246 100644
--- a/site/chapter1/project1/index.html
+++ b/site/chapter1/project1/index.html
@@ -188,7 +188,7 @@
<h3 id="objective">Objective<a class="headerlink" href="#objective" title="Permanent link">¶</a></h3>
<p>We will show you how you can use eggs from a nest on Mynewt to make an LED on a target board blink. We will call it <strong> Project Blinky</strong>. The goals of this tutorial are threefold:</p>
<ol>
-<li>First, you will learn how to set up your environment to be ready to use the various eggs that you will download from Mynewt. </li>
+<li>First, you will learn how to set up your environment to be ready to use Mynewt OS and newt tool. </li>
<li>Second, we will walk you through a download of eggs for building and testing <a href="#building-test-code-on-simulator">on a simulated target</a> on a non-Windows machine.</li>
<li>Third, you will download eggs and use tools to create a runtime image for a board to <a href="#making-an-led-blink">make its LED blink</a>. </li>
</ol>
@@ -246,10 +246,10 @@ $ export GOPATH=`pwd`
$ vi ~/.bash_profile</p>
</li>
<li>
-<p>The next step is to set up the repository for the package building tool "newt" on your local machine. First create the appropriate directory for it and then clone the newt tool repository from github.com into this newly created directory. Check the installation.</p>
+<p>The next step is to set up the repository for the package building tool "newt" on your local machine. First create the appropriate directory for it and then clone the newt tool repository from the online apache repository (or its github.com mirror) into this newly created directory. Check the installation.</p>
<pre><code>$ mkdir -p $GOPATH/src/github.com/mynewt
$ cd $GOPATH/src/github.com/mynewt
-$ git clone https://github.com/mynewt/newt.git
+$ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git newt
$ ls
newt
$ cd newt
@@ -426,10 +426,10 @@ $ export GOPATH=$PWD
</code></pre>
</li>
<li>
-<p>Set up the repository for the package building tool "newt" on your local machine. First create the appropriate directory for it and then clone the newt tool repository from github.com into this newly created directory. Check the contents of the directory.</p>
+<p>Set up the repository for the package building tool "newt" on your local machine. First create the appropriate directory for it and then clone the newt tool repository from the online apache repository (or its github.com mirror) into this newly created directory. Check the contents of the directory.</p>
<pre><code>$ mkdir -p $GOPATH/src/github.com/mynewt
$ cd $GOPATH/src/github.com/mynewt
-$ git clone https://github.com/mynewt/newt.git
+$ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git newt
$ ls
newt
$ cd newt
@@ -632,10 +632,10 @@ $ cd dev\go
</code></pre>
</li>
<li>
-<p>Set up the repository for the package building tool "newt" on your local machine. First create the appropriate directory for it and then clone the newt tool repository from github.com into this newly created directory. Check the contents of the directory.</p>
+<p>Set up the repository for the package building tool "newt" on your local machine. First create the appropriate directory for it and then clone the newt tool repository from the online apache repository (or its github.com mirror) into this newly created directory. Check the contents of the directory.</p>
<pre><code>$ mkdir %GOPATH%\src\github.com\mynewt
$ cd %GOPATH%\src\github.com\mynewt
-$ git clone https://github.com/mynewt/newt.git
+$ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git newt
$ ls
newt
$ cd newt
@@ -720,26 +720,26 @@ Use "newt help [command]" for more information about a command.
</li>
</ul>
<h4 id="proceed-to-the-building-test-code-on-simulator-on-windows-machine-section">Proceed to the <a href="#building-test-code-on-simulator">Building test code on simulator on Windows machine</a> section.<a class="headerlink" href="#proceed-to-the-building-test-code-on-simulator-on-windows-machine-section" title="Permanent link">¶</a></h4>
-<p>Note: Currently, the simulator cannot be run in the Windows machine. We are working on it. In the meantime proceed to the <a href="#making-an-led-blink">Making an LED blink</a> on the Olimex hardware directly.</p>
+<p>Note: Currently, the simulator cannot be run in the Windows machine. We are still working on it. So you will go ahead and <a href="#making-an-led-blink">make an LED blink</a> on the Olimex hardware directly. </p>
+<p>However, before you skip to the hardware target, you still need to build your first nest as outlined in step 1 in the <a href="#building-test-code-on-simulator">Building test code on simulator</a>.</p>
<h3 id="building-test-code-on-simulator">Building test code on simulator<a class="headerlink" href="#building-test-code-on-simulator" title="Permanent link">¶</a></h3>
-<p>Note: Currently, the simulator cannot be run in the Windows machine. We are working on it. If you are on a Windows machine proceed to the <a href="#making-an-led-blink">Making an LED blink</a> on the Olimex hardware directly.</p>
+<p>Note: Currently, the simulator cannot be run in the Windows machine. We are working on it. If you are on a Windows machine, do step 1 below and then proceed to the <a href="#making-an-led-blink">Making an LED blink</a> on the Olimex hardware directly.</p>
<ol>
<li>
-<p>First, you have to create a repository for the project i.e. build your first nest! Go to ~/dev and clone the larva repository from github. The URL used below is the HTTPS clone URL from the github.com repository for the Newt Operating System. </p>
+<p>First, you have to create a repository for the project i.e. build your first nest! Go to ~/dev and clone the larva repository from the apache git repository into a local directory named <code>larva</code>.</p>
<p>Substitute DOS commands for Unix commands as necessary in the following steps if your machine is running Windows. The newt tool commands do not change.</p>
<pre><code>$ cd ~/dev
-$ git clone https://github.com/mynewt/larva.git
+$ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva
$ ls
go larva
$ cd larva
$ ls
-LICENSE hw project
-README.md libs repo.yml
-compiler pkg setup-remotes.sh
+LICENSE clutch.yml hw nest.yml project
+README.md compiler libs net scripts
</code></pre>
</li>
<li>
-<p>You will now create a new project using the newt tool. You can either use the compiled binary <code>newt</code> or run the newt.go program using <code>$newt</code> (assuming you have stored the command in a variable in your .bash_profile or .bashrc). When you do a <code>newt target show</code> or <code>$newt target show</code> it should list all the projects you have created so far. </p>
+<p>You will now create a new target using the newt tool. You can either use the compiled binary <code>newt</code> or run the newt.go program using <code>$newt</code> (assuming you have stored the command in a variable in your .bash_profile or .bashrc). When you do a <code>newt target show</code> or <code>$newt target show</code> it should list all the projects you have created so far. </p>
<pre><code>$ newt target create sim_test
Creating target sim_test
Target sim_test sucessfully created!
@@ -833,7 +833,7 @@ Successfully run!
<p>Substitute DOS commands for Unix commands as necessary in the following steps if your machine is running Windows. The newt tool commands do not change.</p>
</li>
<li>
-<p>Again, you first have to create a repository for the project. Go to the ~dev/larva directory and build out a second project inside larva. The project name is "blinky", in keeping with the objective. Starting with the target name, you have to specify the different aspects of the project to build the right package for the board. In this case that means setting the architecture (arch), compiler, board support package (bsp), project, and compiler mode.</p>
+<p>You first have to create a repository for the project. Go to the ~dev/larva directory and build out a second project inside larva. The project name is "blinky", in keeping with the objective. Starting with the target name, you have to specify the different aspects of the project to pull the appropriate eggs and build the right package for the board. In this case that means setting the architecture (arch), compiler, board support package (bsp), project, and compiler mode.</p>
<pre><code>$ newt target create blinky
Creating target blinky
Target blinky sucessfully created!
@@ -858,8 +858,13 @@ blinky
</code></pre>
</li>
<li>
-<p>Now you have to build the image package. Once built, you can find the executable "blinky.elf" in the project directory at ~/dev/larva/project/blinky/bin/blink. It's a good idea to take a little time to understand the directory structure.</p>
-<pre><code>$ newt target build blinky
+<p>Now you have to build the image. The linker script within the <code>hw/bsp/olimex_stm32-e407_devboard</code> egg builds an image for flash memory by default. Therefore, you need to switch that script with <code>run_from_sram.ld</code> in order to get the egg to produce an image for SRAM. <font color="red"> We are working on making it easier to specify where the executable will be run from for a particular project and automatically choose the correct linker scripts and generate the appropriate image. It will be specified as a project identity e.g. bootloader, RAM, flash (default) and the target will build accordingly. </font>. </p>
+<p>Once the target is built, you can find the executable "blinky.elf" in the project directory at ~/dev/larva/project/blinky/bin/blinky. It's a good idea to take a little time to understand the directory structure.</p>
+<pre><code>$ cd ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard
+$ diff olimex_stm32-e407_devboard.ld run_from_sram.ld
+$ cp run_from_sram.ld olimex_stm32-e407_devboard.ld
+$ cd ~/dev/larva/project/blinky/bin/blinky
+$ newt target build blinky
Building target blinky (project = blinky)
Compiling case.c
Compiling suite.c
@@ -1061,7 +1066,7 @@ Reading symbols from C:/dev/larva/project/blinky/bin/blinky/blinky.elf...done.
<p>You will have to reset the board once the image is uploaded to it.</p>
<ol>
<li>
-<p>By now you know that you have to build a new package. First, the olimex_stm32-e407_devboard.ld linker script which was previously the same as run_from_sram.ld will now need the contents of run_from_flash.ld. Then the target has to be rebuilt. You will simply replace the blinky project contents with the eggs needed to boot from flash instead of creating a new nest.</p>
+<p>By now you know that you have to build a new package that will run from flash. First, the olimex_stm32-e407_devboard.ld linker script which was previously made the same as run_from_sram.ld will now need the contents of run_from_flash.ld. Then the target has to be rebuilt. </p>
<pre><code>$ cd ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard
$ diff olimex_stm32-e407_devboard.ld run_from_sram.ld
$ cp run_from_flash.ld olimex_stm32-e407_devboard.ld
@@ -1070,102 +1075,65 @@ $ newt target build blinky
</code></pre>
</li>
<li>
-<p>Go to the openocd directory under blink and use OpenOCD to open up a session with the board as done while booting from SRAM.</p>
-<pre><code>$ cd ~/dev/larva/project/blinky/bin/blinky/openocd
-$ openocd -f olimex-arm-usb-tiny-h-ftdi.cfg -f ocd-8888.cfg -f stm32f4x.cfg -c "reset halt"
+<p>Go to the project directory and download the image to flash ... in a flash! </p>
+<pre><code>$ cd ~/dev/larva/project/blinky/bin/blinky
+$ newt target download blinky
+Downloading with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_download.sh
+</code></pre>
+</li>
+<li>
+<p>The LED should be blinking!</p>
+</li>
+<li>
+<p>But wait...let's double check that it is indeed booting from flash and making the LED blink from the image in flash. Pull the USB cable off the Olimex JTAG adaptor. The debug connection to the JTAG port is now severed. Next power off the Olimex board by pulling out the USB cable from the board. Wait for a couple of seconds and plug the USB cable back to the board. </p>
+<p>The LED light will start blinking again. Success!</p>
+<p>Note #1: If you want to download the image to flash and a gdb session opened up, use <code>newt target debug blinky</code> instead of <code>newt target download blinky</code>.</p>
+<pre><code>$ newt target debug blinky
+Debugging with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_debug.sh blinky
+Debugging ~/dev/larva/project/blinky/bin/blinky/blinky.elf
+GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
+Copyright (C) 2014 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law. Type "show copying"
+and "show warranty" for details.
+This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
+Type "show configuration" for configuration details.
+For bug reporting instructions, please see:
+<http://www.gnu.org/software/gdb/bugs/>.
+Find the GDB manual and other documentation resources online at:
+<http://www.gnu.org/software/gdb/documentation/>.
+For help, type "help".
+Type "apropos word" to search for commands related to "word"...
+Reading symbols from /Users/aditihilbert/dev/larva/project/blinky/bin/blinky/blinky.elf...done.
Open On-Chip Debugger 0.8.0 (2015-09-22-18:21)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 1000 kHz
-adapter_nsrst_assert_width: 500
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
+Warn : target name is deprecated use: 'cortex_m'
+DEPRECATED! use 'cortex_m' not 'cortex_m3'
cortex_m reset_config sysresetreq
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
-target state: halted
-target halted due to debug-request, current mode: Thread
-xPSR: 0x01000000 pc: 0x0800408c psp: 0x20003c60
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
-xPSR: 0x01000000 pc: 0x0800053c msp: 0x10010000
-</code></pre>
-</li>
-<li>
-<p>Run the GNU debugger for ARM in a different window. Specifying the script gdb-8888.cfg tells it what image to load. You should now have a (gdb) prompt inside the debugger.</p>
-<pre><code>$ cd ~/dev/larva/project/blinky/bin/blinky/openocd
-$ arm-none-eabi-gdb -x gdb-8888.cfg
-GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
-Copyright (C) 2014 Free Software Foundation, Inc.
-License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
-This is free software: you are free to change and redistribute it.
-There is NO WARRANTY, to the extent permitted by law. Type "show copying"
-and "show warranty" for details.
-This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
-Type "show configuration" for configuration details.
-For bug reporting instructions, please see:
-<http://www.gnu.org/software/gdb/bugs/>.
-Find the GDB manual and other documentation resources online at:
-<http://www.gnu.org/software/gdb/documentation/>.
-For help, type "help".
-Type "apropos word" to search for commands related to "word".
-
-*** Set target charset ASCII
-
-*** Connecting to OpenOCD over port #8888 ***
-0x20000580 in ?? ()
-
-*** loading nic.out.elf ***
-Loading section .text, size 0x65d4 lma 0x20000000
-Loading section .ARM.extab, size 0x24 lma 0x200065d4
-Loading section .ARM.exidx, size 0xd8 lma 0x200065f8
-Loading section .data, size 0x8f8 lma 0x200066d0
-Start address 0x20000580, load size 28616
-Transfer rate: 78 KB/sec, 2861 bytes/write.
+xPSR: 0x01000000 pc: 0x08000250 msp: 0x10010000
+Info : accepting 'gdb' connection from 3333
+Info : device id = 0x10036413
+Info : flash size = 1024kbytes
+Reset_Handler () at startup_STM32F40x.s:199
+199 ldr r1, =__etext
(gdb)
</code></pre>
-</li>
-<li>
-<p>From within gdb check the registers. Set the msp register to the value expected. Finally, hit <code>c</code> to continue... and your green LED should blink!</p>
-<pre><code>(gdb) info reg all
- r0 0x0 0
- r1 0x0 0
- r2 0x0 0
- r3 0x0 0
- r4 0x0 0
- r5 0x0 0
- r6 0x0 0
- r7 0x0 0
- r8 0x0 0
- r9 0x0 0
- r10 0x0 0
- r11 0x0 0
- r12 0x0 0
- sp 0x10010000 0x10010000
- lr 0xffffffff -1
- pc 0x20000580 0x20000580 <Reset_Handler>
- xPSR 0x1000000 16777216
- msp 0x10010000 0x10010000
- psp 0x0 0x0
- primask 0x0 0
- basepri 0x0 0
- faultmask 0x0 0
- control 0x0 0
- (gdb) set $msp=0x10010000
- (gdb) c
- Continuing.
-</code></pre>
-</li>
-<li>
-<p>The LED should be blinking! But wait...let's double check that it is indeed booting from flash and making the LED blink from the image in flash. Pull the USB cable off the Olimex JTAG adaptor. The debug connection to the JTAG port is now severed. Next power off the Olimex board by pulling out the USB cable from the board. Wait for a couple of seconds and plug the USB cable back to the board. </p>
-<p>The LED light will start blinking again. Success!</p>
-<p>Note: If you want to erase the flash and load the image again you may use the following commands from within gdb. <code>flash erase 0 0 x</code> tells it to erase sectors 0 through x. When you ask it to display (in hex notation) the contents of the sector starting at location 'lma' you should therefore see all f's. The memory location 0x8000000 is the start or origin of the flash memory contents and is specified in the olimex_stm32-e407_devboard.ld linker script. The flash memory locations is specific to the processor.</p>
+<p>Note #2: If you want to erase the flash and load the image again you may use the following commands from within gdb. <code>flash erase_sector 0 0 x</code> tells it to erase sectors 0 through x. When you ask it to display (in hex notation) the contents of the sector starting at location 'lma' you should therefore see all f's. The memory location 0x8000000 is the start or origin of the flash memory contents and is specified in the olimex_stm32-e407_devboard.ld linker script. The flash memory locations is specific to the processor.</p>
<pre><code>(gdb) monitor flash erase_sector 0 0 4
erased sectors 0 through 4 on flash bank 0 in 2.296712s
(gdb) x/32wx 0x8000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/60d6afb2/site/chapter3/newt_tool_reference/index.html
----------------------------------------------------------------------
diff --git a/site/chapter3/newt_tool_reference/index.html b/site/chapter3/newt_tool_reference/index.html
index 27c707a..9a174f9 100644
--- a/site/chapter3/newt_tool_reference/index.html
+++ b/site/chapter3/newt_tool_reference/index.html
@@ -495,6 +495,8 @@ build Build target
test Test target
export Export target
import Import target
+download Download image to target
+debug Download image to target and start an openocd/gdb session
</code></pre>
<p>Flags:</p>
<pre><code>-h, --help=false: help for target
@@ -554,6 +556,14 @@ import Import target
<td>size</td>
<td>Outputs the RAM and flash consumption by the components of the specified target <code>input1</code></td>
</tr>
+<tr>
+<td>download</td>
+<td>Downloads the binary executable <code><target-name>.elf.bin</code>to the board.</td>
+</tr>
+<tr>
+<td>debug</td>
+<td>Downloads the binary executable <code><target-name>.elf.bin</code>to the board and starts up the openocd/gdb combination session. gdb takes over the terminal.</td>
+</tr>
</tbody>
</table>
<p>Command-specific flags</p>
@@ -663,6 +673,16 @@ import Import target
<td>newt target size blink_nordic</td>
<td>Inspects and lists the RAM and Flash memory use by each component (object files and libraries) of the target.</td>
</tr>
+<tr>
+<td>download</td>
+<td>newt target -v -lVERBOSE download blinky</td>
+<td>Downloads <code>blinky.elf.bin</code>to the hardware in verbose mode with logging turned on at VERBOSE level.</td>
+</tr>
+<tr>
+<td>debug</td>
+<td>newt target debug blinky</td>
+<td>Downloads <code>blinky.elf.bin</code>to the hardware, opens up a gdb session with <code>blinky.elf</code>in the terminal, and halts for further input in gdb.</td>
+</tr>
</tbody>
</table>
<p>Example content for <code>in_targets.txt</code> file used for importing targets <code>test3</code> and <code>test4</code>. </p>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/60d6afb2/site/index.html
----------------------------------------------------------------------
diff --git a/site/index.html b/site/index.html
index 5d358c8..59342a5 100644
--- a/site/index.html
+++ b/site/index.html
@@ -167,12 +167,12 @@
<div class="col-md-9" role="main">
<h2 id="objective-of-mynewt">Objective of Mynewt<a class="headerlink" href="#objective-of-mynewt" title="Permanent link">¶</a></h2>
-<p>Mynewt is an open source initiative to build a stack of modularized control, networking, and monitoring software for embedded devices. The modular implementation allows the user the flexibility to mix and match hardware components and customize the software stack depending on the feature and performance requirements of the particular application he or she has in mind.</p>
+<p>Mynewt is an open source initiative to build a stack of modularized control, networking, and monitoring software for embedded devices. The modular implementation allows the user the flexibility to mix and match hardware components and software stack depending on the feature and performance requirements of the particular application he or she has in mind.</p>
<p>The world of Mynewt, therefore, has three primary collaborative goals:</p>
<ul>
<li>Build a modularized real-time operating system for a rich set of hardware components</li>
-<li>Offer a suite of software for efficient and secure two-way communications with an embedded device</li>
-<li>Develop method and tools necessary to create an optimized execution environment for the selected software on the desired hardware</li>
+<li>Offer a suite of open-source software for efficient and secure two-way communications with an embedded device</li>
+<li>Develop method and tools necessary to build an optimized executable image on the desired hardware</li>
</ul>
<p>The chapter organization is outlined below. Each Chapter has one or more tutorials for hands-on experience with the material in each chapter. </p>
<ul>
@@ -180,7 +180,7 @@
<p><a href="chapter1/newt_concepts/">Chapter 1: Getting Started</a> introduces some key terms in this initiative and includes a tutorial for a quick project to show how to work with some of the products.</p>
</li>
<li>
-<p><a href="chapter2/vocabulary/">Chapter 2: Getting Acclimatized</a> delves deeper into the concepts crucial to the software development effort. </p>
+<p><a href="chapter2/vocabulary/">Chapter 2: Getting Acclimated</a> delves deeper into the concepts crucial to the software development effort. </p>
</li>
<li>
<p><a href="chapter3/newt_ops/">Chapter 3: Newt Tool Reference</a> describes the command structure and details all the available commands to help you with your project. </p>
@@ -232,5 +232,5 @@
<!--
MkDocs version : 0.14.0
-Build Date UTC : 2015-10-31 00:04:33.840487
+Build Date UTC : 2015-11-07 01:05:43.549138
-->