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/01/06 23:24:04 UTC
[06/16] incubator-mynewt-site git commit: still trying to fix the
website rendering issues
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/cc59f9a2/mkdocs/search_index.json
----------------------------------------------------------------------
diff --git a/mkdocs/search_index.json b/mkdocs/search_index.json
deleted file mode 100644
index 93dc03b..0000000
--- a/mkdocs/search_index.json
+++ /dev/null
@@ -1,684 +0,0 @@
-{
- "docs": [
- {
- "location": "/",
- "text": "Apache Mynewt is an open source initiative to build a stack of modularized control, networking, and monitoring software for embedded devices like wearables, lightbulbs, locks, and doorbells. At the core is a real-time operating system that is designed to work on a variety of microcontrollers. The Apache project includes the Newt tool to help you build and distribute embedded projects using Mynewt OS. 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.",
- "title": "Home"
- },
- {
- "location": "/documentation/",
- "text": "Apache Mynewt Documentation Organization\n\n\nThe chapter organization is outlined below. Each chapter will include one or more tutorials for hands-on experience with the material in each chapter.",
- "title": "Documentation"
- },
- {
- "location": "/documentation/#apache-mynewt-documentation-organization",
- "text": "The chapter organization is outlined below. Each chapter will include one or more tutorials for hands-on experience with the material in each chapter.",
- "title": "Apache Mynewt Documentation Organization"
- },
- {
- "location": "/download/",
- "text": "For general information on using Git at Apache, go to https://git-wip-us.apache.org.\n\n\nIf you are not a committer, follow the proposed non-committer workflow to share your work. The direct link to the proposed workflow is https://git-wip-us.apache.org/docs/workflow.html.\n\n\nTo clone the Apache Mynewt OS development repository:\n\n\nNon Committers\n\n\n$ git clone http://git/wip/us.apache.org/repos/asf/incubator-mynewt-larva.git\n\n\n\nCommitters\n\n\n$ git clone https://git/wip/us.apache.org/repos/asf/incubator-mynewt-larva.git",
- "title": "Download"
- },
- {
- "location": "/community/",
- "text": "Community\n\n\nMailing Lists\n\n\nTo subscribe to a mailing list pertaining to Apache Mynewt, you simply send an email to a special subscription address. To subscribe to the dev list, send an email to \ndev-subscribe@mynewt.incubator.apache.org\n.\n\n\nThe following mailing lists can be used to get help with Apache MyNewt.",
- "title": "Community"
- },
- {
- "location": "/community/#community",
- "text": "",
- "title": "Community"
- },
- {
- "location": "/community/#mailing-lists",
- "text": "To subscribe to a mailing list pertaining to Apache Mynewt, you simply send an email to a special subscription address. To subscribe to the dev list, send an email to dev-subscribe@mynewt.incubator.apache.org . The following mailing lists can be used to get help with Apache MyNewt.",
- "title": "Mailing Lists"
- },
- {
- "location": "/events/",
- "text": "Events\n\n\nPlease take a look at our upcoming events! We hope to see you there.",
- "title": "Events"
- },
- {
- "location": "/events/#events",
- "text": "Please take a look at our upcoming events! We hope to see you there.",
- "title": "Events"
- },
- {
- "location": "/get_started/newt_concepts/",
- "text": "Newt Concepts\n\n\nThis page introduces the basic terms you will need to find your way around the Mynewt ecosystem.\n\n\nBasic components in the ecosystem\n\n\n\n\n\n\nNewtOS is an open-source RTOS (Real Time Operating System) that works on a variety of hardware. The goal is to develop a pre-emptive, multitasking OS that is highly modular, making it possible to mix and match components to enable desired features and capabilities on multiple hardware architectures. Examples of components being worked on are the Core RTOS, a flash file system, utility functions, a variety of board support packages, packages of microcontrollers etc.\n\n\n\n\n\n\nNetwork protocol stacks such as Bluetooth Low Energy, and more\n\n\n\n\n\n\nNewt Tool helps you mix the specific packages for the combination of hardware and low-level embedded architecture features of the user's choice and generate the corresponding run-time image based on the NewtOS. It provides the infrastructure to mana
ge and build for different CPU architectures, memory units, board support packages etc., allowing a user to formulate the contents according to the low-level features needed by his or her project.\n\n\n\n\n\n\nTerminology\n\n\nA Mynewt user starts with a project in mind that defines the application or utility that he or she wants to implement on an embedded device. Making an LED blink on an electronics prototyping board is a common starter project. Enabling a BLE (Bluetooth Low Energy) peripheral mode on a development board is a more complex project. Specifying a project requires naming it, at the very least, and then adding the desired properties or attributes. In order to actualize a project, it needs to be applied to a target which is essentially a combination of some specified hardware and the execution environment. \n\n\nIn the mynewt lifecycle, a project grows in a nest. A nest may house multiple projects. The nest is, therefore, a repository where various component packages f
or one or more projects reside. Each package is an egg (naturally!). However, in the world of Mynewt an egg may consist of other eggs! For example, the starter project Blinky is an egg consisting of several constituent eggs that enable core features. The egg form is suitable for elemental units of code as it explicitly exposes characteristics such as dependencies, versions, capabilities, requirements etc., thus making assembling appropriate components for a project and building an image for it easy to follow, modular, and robust.\n\n\nA nest can be given any name. For example, you will see a nest named \"tadpole\" in Mynewt (\nhttps://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-tadpole.git\n). It contains all the core libraries of the operating system for the native platform which currently supports compilation on Mac OS X. The core libraries are contained in the form of eggs where an egg is a basic unit of implementation of any aspect of the RTOS. The eggs are distributed in
the following directory structure inside the nest:\n\n\n\n\nlibs: contains the two eggs \nos\n and \ntestutil\n\n\nhw: contains three eggs - (i) \nhal\n which has the abstraction layer (HAL) API definitions that all BSP and MCU implementations must support, (ii) \n/mcu/native\n which in an MCU implementation for the native platform (a simulator, in this case), and (iii) \nbsp/native\n which is a BSP implementation for the native platform \n\n\ncompiler: contains the \nsim\n egg which bundles the compiler specifications for the native platform.\n\n\n\n\nLet's explore this sample nest a bit further. The \nlibs/os\n egg contains code for scheduler, process/thread/memory management, semaphores etc. It is the core RTOS which ports to all supported chip platforms.The \nlibs/testutil\n egg contains code for testing packages on hardware or simulated environment. The \nhw/hal\n egg contains header files that provide abstraction for physical hardware components such as GPIO (general purpose
input/output), network adapters, timers, and UARTs. This \nhw/hal\n egg is an MCU peripheral abstraction designed to make it easy to port to different MCUs (microcontrollers). The \nhw/mcu/native\n egg contains code for microcontroller operations on the native platform. The \nhw/bsp/native\n egg contains the board support package for the native platform. And finally, the sixth egg \nsim\n contains the compiler specifications such as path and flags. Currently the compilation is supported on Mac OS X.\n\n\nYou can see another nest in the mynewt ecosystem called the \"larva\". It was spawned from the skeletal \"tadpole\" nest using the newt tool. Spawning is easy - \n$ newt create nest \nyour_nest_name\n. \"larva\" is the developer's test repository containing all sorts of eggs being written and incubated, including ones to enhance the core operating system which should eventually make their way into the \"tadpole\" nest. There is a \nhatch_tadpole\n script to update the \"tadpole\" ne
st when the core OS related eggs in \"larva\" are ready.\n\n\nThere is a third nest named \"newt\" that contains all the eggs needed to support the build and release process of mynewt software. In the future, there will also be pre-built nests for certain common hardware devices to enable a user to quickly get started with a project.\n\n\nA Mynewt contributor\n\n\nA contributor can choose to work on any area(s) of the Mynewt endeavor that appeals to him or her. Hence, you can work on one or more eggs or an entire nest. You can create your own nest (master) or create a branch in an existing nest. For now, Runtime contributors will review any new areas of support that you may wish to introduce e.g. a new board support package (BSP) or a new network protocol. \n\n\nA contributer role necessarily implies he or she is a Mynewt user (see below) of some or all of the products developed.\n\n\nA Mynewt user\n\n\nAn application developer is interested only in using software available in this
ecosystem to build a top level build artifact. He or she may either:\n\n\n\n\nUse a pre-built nest, or\n\n\nSpawn a new nest using the newt tool for a target where a target is a custom combination of supported hardware components\n\n\n\n\nIn either case, the user would use the newt tool to create and set the target in the chosen nest. The newt tool would then be used to build out the target profile which would determine which eggs to choose. Finally, the user would use the newt tool to generate a run-time image that can be run on the device.",
- "title": "Newt Concepts"
- },
- {
- "location": "/get_started/newt_concepts/#newt-concepts",
- "text": "This page introduces the basic terms you will need to find your way around the Mynewt ecosystem. Basic components in the ecosystem NewtOS is an open-source RTOS (Real Time Operating System) that works on a variety of hardware. The goal is to develop a pre-emptive, multitasking OS that is highly modular, making it possible to mix and match components to enable desired features and capabilities on multiple hardware architectures. Examples of components being worked on are the Core RTOS, a flash file system, utility functions, a variety of board support packages, packages of microcontrollers etc. Network protocol stacks such as Bluetooth Low Energy, and more Newt Tool helps you mix the specific packages for the combination of hardware and low-level embedded architecture features of the user's choice and generate the corresponding run-time image based on the NewtOS. It provides the infrastructure to manage and build for different CPU architectures, memory
units, board support packages etc., allowing a user to formulate the contents according to the low-level features needed by his or her project. Terminology A Mynewt user starts with a project in mind that defines the application or utility that he or she wants to implement on an embedded device. Making an LED blink on an electronics prototyping board is a common starter project. Enabling a BLE (Bluetooth Low Energy) peripheral mode on a development board is a more complex project. Specifying a project requires naming it, at the very least, and then adding the desired properties or attributes. In order to actualize a project, it needs to be applied to a target which is essentially a combination of some specified hardware and the execution environment. In the mynewt lifecycle, a project grows in a nest. A nest may house multiple projects. The nest is, therefore, a repository where various component packages for one or more projects reside. Each package is an egg (naturally!). Ho
wever, in the world of Mynewt an egg may consist of other eggs! For example, the starter project Blinky is an egg consisting of several constituent eggs that enable core features. The egg form is suitable for elemental units of code as it explicitly exposes characteristics such as dependencies, versions, capabilities, requirements etc., thus making assembling appropriate components for a project and building an image for it easy to follow, modular, and robust. A nest can be given any name. For example, you will see a nest named \"tadpole\" in Mynewt ( https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-tadpole.git ). It contains all the core libraries of the operating system for the native platform which currently supports compilation on Mac OS X. The core libraries are contained in the form of eggs where an egg is a basic unit of implementation of any aspect of the RTOS. The eggs are distributed in the following directory structure inside the nest: libs: contains the two
eggs os and testutil hw: contains three eggs - (i) hal which has the abstraction layer (HAL) API definitions that all BSP and MCU implementations must support, (ii) /mcu/native which in an MCU implementation for the native platform (a simulator, in this case), and (iii) bsp/native which is a BSP implementation for the native platform compiler: contains the sim egg which bundles the compiler specifications for the native platform. Let's explore this sample nest a bit further. The libs/os egg contains code for scheduler, process/thread/memory management, semaphores etc. It is the core RTOS which ports to all supported chip platforms.The libs/testutil egg contains code for testing packages on hardware or simulated environment. The hw/hal egg contains header files that provide abstraction for physical hardware components such as GPIO (general purpose input/output), network adapters, timers, and UARTs. This hw/hal egg is an MCU peripheral abstraction designed to m
ake it easy to port to different MCUs (microcontrollers). The hw/mcu/native egg contains code for microcontroller operations on the native platform. The hw/bsp/native egg contains the board support package for the native platform. And finally, the sixth egg sim contains the compiler specifications such as path and flags. Currently the compilation is supported on Mac OS X. You can see another nest in the mynewt ecosystem called the \"larva\". It was spawned from the skeletal \"tadpole\" nest using the newt tool. Spawning is easy - $ newt create nest your_nest_name . \"larva\" is the developer's test repository containing all sorts of eggs being written and incubated, including ones to enhance the core operating system which should eventually make their way into the \"tadpole\" nest. There is a hatch_tadpole script to update the \"tadpole\" nest when the core OS related eggs in \"larva\" are ready. There is a third nest named \"newt\" that contains all the eggs needed to s
upport the build and release process of mynewt software. In the future, there will also be pre-built nests for certain common hardware devices to enable a user to quickly get started with a project. A Mynewt contributor A contributor can choose to work on any area(s) of the Mynewt endeavor that appeals to him or her. Hence, you can work on one or more eggs or an entire nest. You can create your own nest (master) or create a branch in an existing nest. For now, Runtime contributors will review any new areas of support that you may wish to introduce e.g. a new board support package (BSP) or a new network protocol. A contributer role necessarily implies he or she is a Mynewt user (see below) of some or all of the products developed. A Mynewt user An application developer is interested only in using software available in this ecosystem to build a top level build artifact. He or she may either: Use a pre-built nest, or Spawn a new nest using the newt tool for a target where a ta
rget is a custom combination of supported hardware components In either case, the user would use the newt tool to create and set the target in the chosen nest. The newt tool would then be used to build out the target profile which would determine which eggs to choose. Finally, the user would use the newt tool to generate a run-time image that can be run on the device.",
- "title": "Newt Concepts"
- },
- {
- "location": "/get_started/project1/",
- "text": "Blinky, the First Project\n\n\nObjective\n\n\nWe 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 \n Project Blinky\n. The goals of this tutorial are threefold:\n\n\n\n\nFirst, you will learn how to set up your environment to be ready to use Mynewt OS and newt tool. \n\n\nSecond, we will walk you through a download of eggs for building and testing \non a simulated target\n.\n\n\nThird, you will download eggs and use tools to create a runtime image for a board to make its LED blink. You have two choices here - you can \ndownload an image to SRAM\n or you can \ndownload it to flash\n.\n\n\n\n\n Time Requirement\n: Allow yourself a couple of hours for this project if you are relatively new to embedded systems and playing with development boards. Those jumpers can be pesky!\n\n\nWhat you need\n\n\n\n\nSTM32-E407 development board from Olimex. You can order it from \nhttp://www.mouser.com\n, \nhttp://www
.digikey.com\n, and other places.\n\n\nARM-USB-TINY-H connector with JTAG interface for debugging ARM microcontrollers (comes with the ribbon cable to hook up to the board)\n\n\nUSB A-B type cable to connect the debugger to your personal computer\n\n\nPersonal Computer\n\n\n\n\nThe instructions assume the user is using a Bourne-compatible shell (e.g. bash or zsh) on your computer. The given instructions have been tested with the following releases of operating systems:\n\n\n\n\nMac: OS X Yosemite Version 10.10.5\n\n\nLinux: Ubuntu 14.10 (Utopic Unicorn)\n\n\nWindows: Windows 10\n\n\n\n\nAccess to the Apache repo\n\n\n\n\n\n\nGet an account on Apache. You do not need a committer account to view the website or clone the repository but you need it to push changes to it.\n\n\n\n\n\n\nThe latest codebase for the Mynewt OS is on the master branch at https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git\n\n\n\n\n\n\nThe latest codebase for the Newt tool is on the master branch
at https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git\n\n\n\n\n\n\nThe following shows how to clone a Mynewt OS code repository:\n\n\n\n\n\n\nNon Committers\n\n\n$ git clone http://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git\n\n\n\n\n\n\n\nCommitters\n\n\n$ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git\n\n\n\n\n\n\n\nGetting your Mac Ready\n\n\nInstalling Homebrew to ease installs on OS X\n\n\n\n\n\n\nDo you have Homebrew? If not, open a terminal on your Mac and paste the following at a Terminal prompt. It will ask you for your sudo password.\n\n\n$ ruby -e \"$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)\"\n\n\n\nAlternatively, you can just extract (or \ngit clone\n) Homebrew and install it to \n/usr/local\n.\n\n\n\n\n\n\nInstalling Go\n\n\n\n\n\n\nThe directory structure must be first readied for using Go. Go code must be kept inside a workspace. A workspace is a directory hierarchy with
three directories at its root:\n\n\n\n\n\n\nsrc contains Go source files organized into packages (one package per directory),\n\n\n\n\n\n\npkg contains package objects, and\n\n\n\n\n\n\nbin contains executable commands.\n\n\n\n\n\n\nThe GOPATH environment variable specifies the location of your workspace. First create a 'dev' directory and then a 'go' directory under it. Set the GOPATH environment variable to this directory where you will soon clone the newt tool repository.\n\n\n$ cd $HOME\n$ mkdir -p dev/go \n$ cd dev/go\n$ export GOPATH=`pwd`\n\n\n\nNote that you need to add export statements to ~/.bash_profile to export variables permanently. Don't forget to source the file for the change to go into effect.\n\n\n$ vi ~/.bash_profile\n$ source ~/.bash_profile\n\n\n\n\n\n\n\nNext you will use Homebrew to install Go. The summary message at the end of the installation should indicate that it is installed in the /usr/local/Cellar/go/ directory. You will use the Go command 'install'
to compile and install packages (called eggs in the Mynewt world) and dependencies. \n\n\n$ brew install go\n==\n \n...\n... \n==\n *Summary*\n\ud83c\udf7a /usr/local/Cellar/go/1.5.1: 5330 files, 273M\n\n\n\nAlternatively, you can download the Go package directly from (https://golang.org/dl/) instead of brewing it. Install it in /usr/local directory.\n\n\n\n\n\n\nCreating local repository\n\n\n\n\n\n\nYou are ready to download the newt tool repository. You will use Go to copy the directory (currently the asf incubator directory). Be patient as it may take a minute or two. Check the directories installed.\n\n\n$ go get git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt\n$ ls\n bin pkg src\n$ ls src\ngit-wip-us.apache.org github.com gopkg.in\n\n\n\n\n\n\n\nCheck that newt.go is in place.\n\n\n$ ls $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt \nGodeps README.md coding_style.txt newt.go\nLICENSE cli
design.txt\n\n\n\n\n\n\n\nBuilding the Newt tool\n\n\n\n\n\n\nYou will use Go to run the newt.go program to build the newt tool. The command used is \ngo install\n which compiles and writes the resulting executable to an output file named \nnewt\n. It installs the results along with its dependencies in $GOPATH/bin.\n\n\n$ cd $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt\n$ go install\n$ ls \"$GOPATH\"/bin/\ngodep incubator-mynewt-newt.git newt\n\n\n\n\n\n\n\nTry running newt using the compiled binary. For example, check for the version number by typing 'newt version'. See all the possible commands available to a user of newt by typing 'newt -h'.\n\n\n\n\n\n\nNote: If you are going to be be modifying the newt tool itself often and wish to compile the program every time you call it, you may want to store the command in a variable in your .bash_profile. So type in \nexport newt=\"go run $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator
-mynewt-newt.git/newt/newt/go\"\n in your .bash_profile and execute it by calling \n$newt\n at the prompt instead of \nnewt\n. Here, you use \ngo run\n which runs the compiled binary directly without producing an executable. Don't forget to reload the updated bash profile by typing \nsource ~/.bash_profile\n at the prompt! \n\n\n $ newt version\n Newt version: 1.0\n $ newt -h\n Newt allows you to create your own embedded project based on the Mynewt\n operating system. Newt provides both build and package management in a\n single tool, which allows you to compose an embedded workspace, and set\n of projects, and then build the necessary artifacts from those projects.\n For more information on the Mynewt operating system, please visit\n https://www.github.com/mynewt/documentation.\n\n Please use the newt help command, and specify the name of the command\n you want help for, for help on how to use a specific command\n\n Usage:\n newt [flags]\n
newt [command]\n\n Examples:\n newt\n newt help [\ncommand-name\n]\n For help on \ncommand-name\n. If not specified, print this message.\n\n\n Available Commands:\n version Display the Newt version number.\n target Set and view target information\n egg Commands to list and inspect eggs on a nest\n nest Commands to manage nests \n clutches (remote egg repositories)\n help Help about any command\n\n Flags:\n -h, --help=false: help for newt\n -l, --loglevel=\"WARN\": Log level, defaults to WARN.\n -q, --quiet=false: Be quiet; only display error output.\n -s, --silent=false: Be silent; don't output anything.\n -v, --verbose=false: Enable verbose output when executing commands.\n\n\n Use \"newt help [command]\" for more information about a command.\n\n\n\n\n\nWithout creating a project repository you can't do a whole lot with the Newt tool. So you'll have to wait till you have downloaded
a nest to try out the tool. \n\n\n\n\nGetting the debugger ready\n\n\n\n\n\n\nBefore you start building nests and hatching eggs, you need to do one final step in the environment preparation - install gcc / libc that can produce 32-bit executables. So, first install gcc. You will see the brew steps and a final summary confirming install.\n\n\n$ brew install gcc\n...\n...\n==\n Summary\n\ud83c\udf7a /usr/local/Cellar/gcc/5.2.0: 1353 files, 248M\n\n\n\n\n\n\n\nARM maintains a pre-built GNU toolchain with a GCC source branch targeted at Embedded ARM Processors namely Cortex-R/Cortex-M processor families. Install the PX4 Toolchain and check the version installed. Make sure that the symbolic link installed by Homebrew points to the correct version of the debugger. If not, you can either change the symbolic link using the \"ln -f -s\" command or just go ahead and try with the version it points to!\n\n\n$ brew tap PX4/homebrew-px4\n$ brew update\n$ brew install gcc-arm-none-eabi-49\n$ arm-
none-eabi-gcc --version \narm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288]\nCopyright (C) 2014 Free Software Foundation, Inc.\nThis is free software; see the source for copying conditions. There is NO\nwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n$ ls -al /usr/local/bin/arm-none-eabi-gdb\nlrwxr-xr-x 1 aditihilbert admin 69 Sep 22 17:16 /usr/local/bin/arm-none-eabi-gdb -\n /usr/local/Cellar/gcc-arm-none-eabi-49/20150609/bin/arm-none-eabi-gdb\n\n\n\nNote: If no version is specified, brew will install the latest version available. MynewtOS will eventually work with multiple versions available including the latest releases. However, at present we have tested only with this version and recommend it for getting started. \n\n\n\n\n\n\nYou have to install OpenOCD (Open On-Chip Debugger) which is an open-source software that will allow you to interface with the JTAG debug connecto
r/adaptor for the Olimex board. It lets you program, debug, and test embedded target devices which, in this case, is the Olimex board. Use brew to install it. Brew adds a simlink /usr/local/bin/openocd to the openocd directory in the Cellar. For more on OpenOCD go to \nhttp://openocd.org\n.\n\n\n$ brew install open-ocd\n$ which openocd\n/usr/local/bin/openocd\n$ ls -l $(which openocd)\nlrwxr-xr-x 1 \nuser\n admin 36 Sep 17 16:22 /usr/local/bin/openocd -\n ../Cellar/open-ocd/0.9.0/bin/openocd\n\n\n\n\n\n\n\nProceed to the \nBuilding test code on simulator\n section.\n\n\n\n\n\n\nGetting your Ubuntu machine Ready\n\n\nInstalling some prerequisites\n\n\n\n\nInstall git, libcurl, and the Go language if you do not have them already.\n$ sudo apt-get install git \n$ sudo apt-get install libcurl4-gnutls-dev \n$ sudo apt-get install golang\n\n\n\n\n\n\n\nCreating local repository\n\n\n\n\n\n\nThe directory structure must be first readied for using Go. Go code must be kept inside a workspa
ce. A workspace is a directory hierarchy with three directories at its root:\n\n\n\n\n\n\nsrc contains Go source files organized into packages (one package per directory),\n\n\n\n\n\n\npkg contains package objects, and\n\n\n\n\n\n\nbin contains executable commands.\n\n\n\n\n\n\nThe GOPATH environment variable specifies the location of your workspace. First create a 'dev' directory and then a 'go' directory under it. Set the GOPATH environment variable to this directory where you will soon clone the newt tool repository.\n\n\n$ cd $HOME\n$ mkdir -p dev/go \n$ cd dev/go\n$ export GOPATH=$PWD\n\n\n\nNote that you need to add export statements to ~/.bashrc (or equivalent) to export variables permanently.\n\n\n\n\n\n\nYou are ready to download the newt tool repository. You will use Go to copy the directory (currently the asf incubator directory). Be patient as it may take a minute or two. Check the directories installed.\n\n\n$ go get git-wip-us.apache.org/repos/asf/incubator-mynewt-new
t.git/newt\n$ ls\n bin pkg src\n$ ls src\ngit-wip-us.apache.org github.com gopkg.in\n\n\n\n\n\n\n\nCheck that newt is in place.\n\n\n$ ls $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt \nGodeps README.md coding_style.txt newt.go\nLICENSE cli design.txt\n\n\n\n\n\n\n\nBuilding the newt tool\n\n\n\n\n\n\nYou will use Go to run the newt.go program to build the newt tool. The command used is \ngo install\n which compiles and writes the resulting executable to an output file named \nnewt\n. It installs the results along with its dependencies in $GOPATH/bin.\n\n\n$ cd $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt\n$ go install\n$ ls \"$GOPATH\"/bin/\ngodep incubator-mynewt-newt.git newt\n\n\n\n\n\n\n\nTry running newt using the compiled binary. For example, check for the version number by typing 'newt version'. See all the possible commands available to a user of newt by
typing 'newt -h'.\n\n\n\n\n\n\nNote: If you are going to be be modifying the newt tool itself often and wish to compile the program every time you call it, you may want to store the command in a variable in your .bash_profile. So type in \nexport newt=\"go run $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt/newt/go\"\n in your ~/.bashrc (or equivalent) and execute it by calling \n$newt\n at the prompt instead of \nnewt\n. Here, you use \ngo run\n which runs the compiled binary directly without producing an executable. \n\n\n $ newt version\n Newt version: 1.0\n $ newt -h\n Newt allows you to create your own embedded project based on the Mynewt\n operating system. Newt provides both build and package management in a\n single tool, which allows you to compose an embedded workspace, and set\n of projects, and then build the necessary artifacts from those projects.\n For more information on the Mynewt operating system, please visit\n
https://www.github.com/mynewt/documentation.\n\n Please use the newt help command, and specify the name of the command\n you want help for, for help on how to use a specific command\n\n Usage:\n newt [flags]\n newt [command]\n\n Examples:\n newt\n newt help [\ncommand-name\n]\n For help on \ncommand-name\n. If not specified, print this message.\n\n\n Available Commands:\n version Display the Newt version number.\n target Set and view target information\n egg Commands to list and inspect eggs on a nest\n nest Commands to manage nests \n clutches (remote egg repositories)\n help Help about any command\n\n Flags:\n -h, --help=false: help for newt\n -l, --loglevel=\"WARN\": Log level, defaults to WARN.\n -q, --quiet=false: Be quiet; only display error output.\n -s, --silent=false: Be silent; don't output anything.\n -v, --verbose=false: Enable verbose output when executing
commands.\n\n\n Use \"newt help [command]\" for more information about a command.\n\n\n\n\n\nWithout creating a project repository you can't do a whole lot with the Newt tool. So you'll have to wait till you have downloaded a nest to try out the tool. \n\n\n\n\nGetting the debugger ready\n\n\n\n\n\n\nBefore you start building nests and hatching eggs, you need to do one final step in the environment preparation - install gcc / libc that can produce 32-bit executables. You can install these as follows: \n\n\n$ sudo apt-get install gcc-multilib libc6-i386\n\n\n\n\n\n\n\nFor the LED project on the Olimex hardware, you have to install gcc for AM 4.9.3. This package can be installed with apt-get as documented below. The steps are explained in depth at \nhttps://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded\n.\n\n\n$ sudo apt-get remove binutils-arm-none-eabi gcc-arm-none-eabi \n$ sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded \n$ sudo apt-get update \n$ sudo apt-g
et install gcc-arm-none-eabi\n\n\n\n\n\n\n\nAnd finally, you have to install OpenOCD (Open On-Chip Debugger) which is an open-source software that will allow you to interface with the JTAG debug connector/adaptor for the Olimex board. It lets you program, debug, and test embedded target devices which, in this case, is the Olimex board. You have to acquire OpenOCD 0.8.0. \n\n\nIf you are running Ubuntu 15.x, then you are in luck and you can simply run: \n\n\n$ sudo apt-get install openocd\n\n\n\nOther versions of Ubuntu may not have the correct version of openocd available. In this case, you should download the openocd 0.8.0 package from \nhttps://launchpad.net/ubuntu/vivid/+source/openocd\n. The direct link to the amd64 build is \nhttp://launchpadlibrarian.net/188260097/openocd_0.8.0-4_amd64.deb\n. \n\n\n\n\n\n\nProceed to the \nBuilding test code on simulator\n section.\n\n\n\n\n\n\nGetting your Windows machine ready for simulated target\n\n\nThe \nnewt\n tool is the build softwar
e used to build Mynewt OS images or executables for any embedded hardware device/board, including the one for the current tutorial (STM32-E407 development board from Olimex). You can run the \nnewt\n tool natively on a computer running any of the three Operating System machines - OSX, Linux, or Windows.\n\n\nHowever, Mynewt OS images for a simulated target are built on the Windows machine by using Linux versions of the build software (newt)in a virtual machine on your Windows box. The Linux VM is set up by installing the Docker Toolbox. Your Windows machine will communicate with the Linux VM via transient ssh connections. You will then download a Docker image (\nnewtvm.exe\n)that allows you to run the newt commands in the Linux Docker instance. The Docker image contains:\n\n\n\n\nThe newt command-line tool\n\n\nGo\n\n\nA multilib-capable native gcc / glibc\n\n\nAn arm-none-eabi gcc\n\n\nNative gdb\n\n\n\n\nThe sequence of events when using the Docker image is as follows:\n\n\n\n\nA
new docker environment is created in the Linux VM.\n\n\nThe specified command with the newtvm prefix (\nnewtvm newt\n command) is sent to the docker environment via ssh.\n\n\nThe Linux command runs.\n\n\nThe output from the command is sent back to Windows via ssh.\n\n\nThe output is displayed in the Windows command prompt.\n\n\n\n\nInstall Linux virtual machine\n\n\n\n\n\n\nDownload the Docker Toolbox for Windows (version 1.9.0c or later) from \nhttps://www.docker.com/docker-toolbox\n. The Docker toolbox creates a consistently reproducible and self-contained environment in Linux.\n\n\n\n\n\n\nRun the Docker Toolbox installer. All the default settings are OK.\n\n\n\n\n\n\nYou may need to add \"C:\\Program Files\\Git\\usr\\bin\" to your PATH\nenvironment variable. To add to the PATH environment variable, right-click on the Start button in the bottom left corner. Choose System -\n Advanced system settings -\n Environment Variables. Click on the PATH variable under \"System variables\
" and click Edit to check and add it if it is not already there. \n\n\n\n\n\n\nInstall newtvm tool\n\n\n\n\n\n\nFrom your base user (home) directory, pull or clone the latest code from the newt repository into the \nnewt\n directory. It includes the executable \nnewtvm.exe\n for the newtvm tool in the \nnewtvm\n directory.\n\n\nC:\\Users\\admin\n git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt newt\n\n\n\n\n\n\nThe newtvm tool is what allows you to run programs in the Linux docker\ninstance. \n\n\n\n\nRun the Docker Quickstart Terminal application inside the Docker folder under Programs. You can find it by clicking Start button -\n All apps. By default, the Docker Toolbox installer creates a shortcut to this program on your desktop. Wait until you see an ASCII art whale displayed in the terminal window and the Docker prompt given. \n ## .\n ## ## ## ==\n ## ## ## ## ## ===\n /\"\"\"\"\"\"\"\"\"\"\"\
"\"\"\"\"\"\\___/ ===\n~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ / ===- ~~~\n \\______ o __/\n \\ \\ __/\n \\____\\_______/\n\n docker is configured to use the default machine with IP 192.168.99.100\n For help getting started, check out the docs at https://docs.docker.com\n\n admin@dev1 MINGW64 ~ (master)\n $\n\n\n\n\n\n\n\nThe first time you run this, it may take several minutes to complete. You will need to run the Docker Quickstart Terminal once each time you\nrestart your computer.\n\n\n\n\nOpen a command prompt (e.g., Windows-R, \"cmd\", enter). You execute the newt tool commands as though you were running newt in Linux, but you prefix each command with \"newtvm\". For example:\nC:\\Users\\admin\\newt\\newtvm\n newtvm newt help\n\n\n\n\n\n\n\nThe newtvm tool will take a long time to run the first time you execute\nit. The delay is due to the fact that the tool must download the mynewt\ndocker instance.\n\n\n\n\nYou are now ready to proceed to \nbuilding the
image for the simulated target\n.\n\n\n\n\nGetting your Windows machine ready for hardware target\n\n\nWhen you want to produce images for actual hardware board on your Windows machine, go through the following setup procedure and then proceed to the \nblinky project on the Olimex board\n with this method.\n\n\nInstalling some prerequisites\n\n\n\n\n\n\nYou have to install the following if you do not have them already. The steps below indicate specific folders where each of these programs should be installed. You can choose different locations, but the remainder of this\ntutorial for a Windows machine assumes the specified folders. \n\n\n\n\nwin-builds-i686\n\n\nwin-builds-x86_64\n\n\nMSYS\n\n\ngcc for ARM\n\n\nopenocd\n\n\nzadig\n\n\ngit\n\n\n\n\ngo\n\n\n\n\nwin-builds (mingw64) 1.5 for i686\n\n\n\n\nDownload from \nhttp://win-builds.org/doku.php/download_and_installation_from_windows\n. Install at: \"C:\\win-builds-i686\".\n\n\nBe sure to click the i686 option (not x86_64). T
he defaults for all other options are OK. The installer will want to download a bunch of additional packages. They are not all necessary, but it is simplest to just accept the defaults.\n\n\n\n\nwin-builds (mingw64) 1.5 for x86_64\n\n\n\n\nDownload from \nhttp://win-builds.org/doku.php/download_and_installation_from_windows\n. Install at \"C:\\win-builds-x86_64\"\n\n\nRun the installer a second time, but this time click the x86_64 option, NOT i686. The defaults for all other options are OK.\n\n\n\n\nMSYS\n\n\n\n\nStart your download from \nhttp://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/MSYS-20111123.zip\n\n\nUnzip to \"C:\\msys\"\n\n\n\n\ngcc for ARM, 4.9.3\n\n\n\n\nDownload the Windows installer from \nhttps://launchpad.net/gcc-arm-embedded/+download\n and install at \"C:\\Program Files (x86)\\GNU Tools ARM Embedded\\4.9 2015q3\".\n\n\n\n\nOpenOCD 0.8.0 \n\n\n\n\nDownload OpenOCD 0.8.0 from \nhttp://www.fredd
iechopin.info/en/download/category/4-openocd\n. Unzip to \"C:\\openocd\".\n\n\n\n\nZadig 2.1.2\n\n\n\n\nDownload it from \nhttp://zadig.akeo.ie\n and install it at \"C:\\zadig\".\n\n\n\n\nGit\n\n\n\n\nClick on \nhttps://git-scm.com/download/win\n to start the download. Install at \"C:\\Program Files (x86)\\Git\". Specify the \"Use Git from the Windows Command Prompt\" option. The defaults for all other options are OK.\n\n\n\n\nGo\n\n\n\n\nDownload the release for Microsoft Windows from \nhttps://golang.org/dl/\n and install it \"C:\\Go\".\n\n\n\n\n\n\n\n\n\n\nCreating local repository\n\n\n\n\n\n\nThe directory structure must be first readied for using Go. Go code must be kept inside a workspace. A workspace is a directory hierarchy with three directories at its root:\n\n\n\n\n\n\nsrc contains Go source files organized into packages (one package per directory),\n\n\n\n\n\n\npkg contains package objects, and\n\n\n\n\n\n\nbin contains executable commands.\n\n\n\n\n\n\nThe GOPATH envi
ronment variable specifies the location of your workspace. First create a 'dev' directory and then a 'go' directory under it. Set the GOPATH environment variable to this directory and then proceed to create the directory for cloning the newt tool repository.\n\n\n$ cd c:\\\n$ mkdir dev\\go\n$ cd dev\\go\n\n\n\n\n\n\n\nSet the following user environment variables using the steps outlined here.\n\n\n\n\nGOPATH: C:\\dev\\go\n\n\nPATH: C:\\Program Files (x86)\\GNU Tools ARM Embedded\\4.9 2015q3\\bin;%GOPATH%\\bin;C:\\win-builds-x86_64\\bin;C:\\win-builds-i686\\bin;C:\\msys\\bin\n\n\n\n\nSteps:\n\n\n\n\nRight-click the start button\n\n\nClick \"Control panel\"\n\n\nClick \"System and Security\"\n\n\nClick \"System\"\n\n\nClick \"Advanced system settings\" in the left panel\n\n\nClick the \"Envoronment Variables...\" button\n\n\nThere will be two sets of environment variables: user variables\n in the upper half of the screen, and system variables in the lower\n half. Configuring the us
er variables is recommended and tested \n (though system variables will work as well).\n\n\n\n\n\n\n\n\nNext, install godep. Note that the following command produces no output.\n\n\n$ go get github.com/tools/godep\n\n\n\n\n\n\n\nSet 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.\n\n\n$ go get git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt\n$ dir \n bin pkg src\n$ dir src\ngit-wip-us.apache.org github.com gopkg.in\n$ dir\nnewt\n$ cd newt\n$ dir\nGodeps README.md coding_style.txt newt.go\nLICENSE cli design.txt\n\n\n\n\n\n\n\nCheck that newt is in place.\n\n\n$ dir $GOPATH\\src\\git-wip-us.apache.org\\repos\\asf\\incubator-mynewt-newt.
git\\newt \nGodeps README.md coding_style.txt newt.go\nLICENSE cli design.txt\n\n\n\n\n\n\n\nBuilding the newt tool\n\n\n\n\n\n\nYou will use Go to run the newt.go program to build the newt tool. The command used is \ngo install\n which compiles and writes the resulting executable to an output file named \nnewt\n. It installs the results along with its dependencies in $GOPATH/bin.\n\n\n$ go install\n$ ls \"$GOPATH\"/bin/\ngodep incubator-mynewt-newt.git newt\n\n\n\n\n\n\n\nTry running newt using the compiled binary. For example, check for the version number by typing 'newt version'. See all the possible commands available to a user of newt by typing 'newt -h'.\n\n\nNote: If you are going to be be modifying the newt tool itself often and wish to compile the program every time you call it, you may want to define the newt environment variable that allows you to execute the command via \n%newt%\n. Use \nset newt=go run %GOPATH%\\src\\gith
ub.com\\mynewt\\newt\\newt.go\n or set it from the GUI. Here, you use \ngo run\n which runs the compiled binary directly without producing an executable.\n\n\n$ newt version\nNewt version: 1.0\n$ newt -h\nNewt allows you to create your own embedded project based on the Mynewt\noperating system. Newt provides both build and package management in a\nsingle tool, which allows you to compose an embedded workspace, and set\nof projects, and then build the necessary artifacts from those projects.\nFor more information on the Mynewt operating system, please visit\nhttps://www.github.com/mynewt/documentation.\n\nPlease use the newt help command, and specify the name of the command\nyou want help for, for help on how to use a specific command\n\nUsage:\n newt [flags]\n newt [command]\n\nExamples:\n newt\n newt help [\ncommand-name\n]\n For help on \ncommand-name\n. If not specified, print this message.\n\nAvailable Commands:\n version Display the Newt version number.\n target Se
t and view target information\n egg Commands to list and inspect eggs on a nest\n nest Commands to manage nests \n clutches (remote egg repositories)\n help Help about any command\n\nFlags:\n -h, --help=false: help for newt\n -l, --loglevel=\"WARN\": Log level, defaults to WARN.\n -q, --quiet=false: Be quiet; only display error output.\n -s, --silent=false: Be silent; don't output anything.\n -v, --verbose=false: Enable verbose output when executing commands.\n\nUse \"newt help [command]\" for more information about a command.\n\n\n\n\n\n\n\nWithout creating a project repository you can't do a whole lot with the Newt tool. So you'll have to wait till you have downloaded a nest to try out the tool. \n\n\n\n\n\n\nGetting the debugger ready\n\n\n\n\n\n\nUse Zadig to configure the USB driver for your Olimex debugger. If your debugger is already set up, you can skip this step.\n\n\n\n\nPlug in your Olimex debugger.\n\n\nStart Zadig.\n\n\nCheck the Options -\n List
All Devices checkbox.\n\n\nSelect \"Olimex OpenOCD JTAG ARM-USB-TINY-H\" in the dropdown menu.\n\n\nSelect the \"WinUSB\" driver.\n\n\nClick the \"Install Driver\" button.\n\n\n\n\n\n\n\n\nProceed to the section on how to \nmake an LED blink\n section.\n\n\n\n\n\n\nBuilding test code on simulator\n\n\nNote: On a Windows computer, the simulator can be run only in a Linux virtual environment. Make sure you have installed the Docker instance as outlined in \nan earlier section\n. Consequently, all \nnewt\n commands must be prefaced with \nnewtvm\n.\n\n\n\n\n\n\nFirst, you have to create a repository for the project i.e. build your first nest! Go to ~/dev (or your base user directory on a Windows machine)and clone the larva repository from the apache git repository into a local directory named \nlarva\n.\n\n\nSubstitute DOS commands for Unix commands as necessary in the following steps if your machine is running Windows. The newt tool commands do not change.\n\n\n$ cd ~/dev \n$ git clon
e https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva\n$ ls\ngo larva\n$ cd larva\n$ ls\nLICENSE clutch.yml hw nest.yml project\nREADME.md compiler libs net scripts\n\n\n\nOn Windows, open a command prompt (e.g., Windows-R, \"cmd\", enter) and work from your home directory:\n\n\nC:\\Users\\admin\n git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva\nC:\\Users\\admin\n cd larva\nC:\\Users\\admin\\larva\n dir\nVolume in drive C is Windows\nVolume Serial Number is 4CBB-0920\n\nDirectory of C:\\Users\\admin\\larva\n\n\nDIR\n .\n\nDIR\n ..\n 76 .gitignore\n 0 .gitmodules\n .nest\n 6,133 clutch.yml\n\nDIR\n compiler\n\nDIR\n hw\n\nDIR\n libs\n 11,560 LICENSE\n 20 nest.yml\n\nDIR\n net\n\nDIR\n project\n 2,263 README.md\n\nDIR\n scripts\n6 File(s) 20,052 by
tes\n9 Dir(s) 90,723,442,688 bytes free\n\n\n\n\n\n\n\nYou will now create a new target using the newt tool. You can either use the compiled binary \nnewt\n or run the newt.go program using \n$newt\n (assuming you have stored the command in a variable in your .bash_profile or .bashrc). When you do a \nnewt target show\n or \n$newt target show\n it should list all the projects you have created so far. \n\n\n$ newt target create sim_test\nCreating target sim_test\nTarget sim_test sucessfully created!\n$ newt target show\nsim_test\n name: sim_test\n arch: sim\n\n\n\nRemember, on a Windows machine you will have to preface \nnewt\n with \nnewtvm\n!\n\n\nC:\\Users\\admin\\larva\nnewtvm newt target create sim_test\n\n\n\n\n\n\n\nNow continue to populate and build out the sim project.\n\n\n$ newt target set sim_test project=test\nTarget sim_test successfully set project to test\n$ newt target set sim_test compiler_def=debug\nTarget sim_test successfully set compiler_def to debug\n$ n
ewt target set sim_test bsp=hw/bsp/native\nTarget sim_test successfully set bsp to hw/bsp/native\n$ newt target set sim_test compiler=sim\nTarget sim_test successfully set compiler to sim\n$ newt target show sim_test\nsim_test\n arch: sim\n project: test\n compiler_def: debug\n bsp: hw/bsp/native\n compiler: sim\n name: sim_test\n\n\n\nAgain remember to preface \nnewt\n with \nnewtvm\non a Windows machine as shown below. Continue to fill out all the project attributes.\n\n\nC:\\Users\\admin\\larva\nnewtvm newt target set sim_test project=test\nTarget sim_test successfully set project to test\n\n\n\n\n\n\n\nConfigure newt to use the gnu build tools native to OS X or linux. In order for sim to work properly, it needs to be using 32-bit gcc (gcc-5). Replace \n~/dev/larva/compiler/sim/compiler.yml with the compiler/sim/osx-compiler.yml or linux-compiler.yml file, depending on the system. On a Windows machine follow the instruction for the Linux machine as you are runni
ng commands in a Linux VM.\n\n\nFor a Mac OS X environment:\n\n\n$ cp compiler/sim/osx-compiler.yml compiler/sim/compiler.yml\n\n\n\nFor a Linux machine:\n\n\n$ cp compiler/sim/linux-compiler.yml compiler/sim/compiler.yml\n\n\n\n\n\n\n\nNext, create (hatch!) the eggs for this project using the newt tool - basically, build the packages for it. You can specify the VERBOSE option if you want to see the gory details. Always remember to preface \nnewt\n with \nnewtvm\non a Windows machine.\n\n\n$ newt target build sim_test\nSuccessfully run!\n\n\n\nYou can specify the VERBOSE option if you want to see the gory details.\n\n\n$newt -l VERBOSE target build sim_test\n2015/09/29 09:46:12 [INFO] Building project test\n2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//bootutil...\n2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//cmsis-core...\n2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//ffs..\n...\nSuc
cessfully run!\n\n\n\n\n\n\n\nTry running the test suite executable inside this project and enjoy your first successful hatch.\n\n\n$ newt ./project/test/bin/sim_test/test.elf\n[pass] os_mempool_test_suite/os_mempool_test_case\n[pass] os_mutex_test_suite/os_mutex_test_basic\n[pass] os_mutex_test_suite/os_mutex_test_case_1\n[pass] os_mutex_test_suite/os_mutex_test_case_2\n[pass] os_sem_test_suite/os_sem_test_basic\n[pass] os_sem_test_suite/os_sem_test_case_1\n[pass] os_sem_test_suite/os_sem_test_case_2\n[pass] os_sem_test_suite/os_sem_test_case_3\n[pass] os_sem_test_suite/os_sem_test_case_4\n[pass] os_mbuf_test_suite/os_mbuf_test_case_1\n[pass] os_mbuf_test_suite/os_mbuf_test_case_2\n[pass] os_mbuf_test_suite/os_mbuf_test_case_3\n[pass] gen_1_1/ffs_test_unlink\n[pass] gen_1_1/ffs_test_rename\n[pass] gen_1_1/ffs_test_truncate\n[pass] gen_1_1/ffs_test_append\n[pass] gen_1_1/ffs_test_read\n[pass] gen_1_1/ffs_test_overwrite_one\n[pass] gen_1_1/ffs_test_overwrite_two\n[pass] gen_1_1/ffs_t
est_overwrite_three\n...\n...\n[pass] boot_test_main/boot_test_vb_ns_11\n\n\n\n\n\n\n\nUsing SRAM to make LED blink\n\n\nYou are here because you want to build an image to be run from internal SRAM on the Olimex board.\n\n\nPreparing the Software\n\n\n\n\n\n\nMake sure the PATH environment variable includes the $HOME/dev/go/bin directory (or C:\\%GOPATH%\\bin on Windows machine). \n\n\nSubstitute DOS commands for Unix commands as necessary in the following steps if your machine is running Windows (e.g. \ncd dev\\go\n instead of \ncd dev/go\n). The newt tool commands do not change.\n\n\n\n\n\n\nIf you have cloned the larva repository for the simulator test in the previous section you can skip this step. Otherwise, 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 \nlarva\n.\n\n\nSubstitute DOS commands for Unix commands as necessary in the following steps i
f your machine is running Windows. The newt tool commands do not change.\n\n\n$ cd ~/dev \n$ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva\n$ ls\ngo larva\n$ cd larva\n$ ls\nLICENSE clutch.yml hw nest.yml project\nREADME.md compiler libs net scripts\n\n\n\n\n\n\n\nYou 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.\n\n\n\n\n\n\nRemember to prefix each command with \"newtvm\" if you are executing the newt command in a Linux virtual machine on your Windows box!\n\n\n $ newt target create blinky
\n Creating target blinky\n Target blinky sucessfully created!\n $ newt target set blinky arch=cortex_m4\n Target blinky successfully set arch to arm\n $ newt target set blinky compiler=arm-none-eabi-m4\n Target blinky successfully set compiler to arm-none-eabi-m4\n $ newt target set blinky project=blinky\n Target blinky successfully set project to blinky\n $ newt target set blinky compiler_def=debug\n Target blinky successfully set compiler_def to debug\n $ newt target set blinky bsp=hw/bsp/olimex_stm32-e407_devboard\n Target blinky successfully set bsp to hw/bsp/olimex_stm32-e407_devboard\n $ newt target show blinky\n blinky\n compiler: arm-none-eabi-m4\n project: blinky\n compiler_def: debug\n bsp: hw/bsp/olimex_stm32-e407_devboard\n name: blinky\n arch: cortex_m4\n\n\n\n\n\n\n\nNow you have to build the image. The linker script within the \nhw/bsp/olimex_stm32-e407_devboard\n egg builds an image
for flash memory by default. Since you want an image for the SRAM, you need to switch that script with \nrun_from_sram.ld\n in order to get the egg to produce an image for SRAM. \n 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. \n. \n\n\nOnce 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.\n\n\n$ cd ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard\n$ diff olimex_stm32-e407_devboard.ld run_from_sram.ld\n$ cp run_from_sram.ld olimex_stm32-e407_devboard.ld\n$ cd ~/dev/larva/project/blinky/bin/blinky\n$ newt target build blinky\nBuilding target blinky (project = blin
ky)\nCompiling case.c\nCompiling suite.c\n...\nSuccessfully run!\n$ ls\nLICENSE clutch.yml hw nest.yml project\nREADME.md compiler libs net scripts\n$ cd project\n$ ls\nbin2img bletest blinky boot ffs2native test\n$ cd blinky\n$ ls\nbin blinky.yml egg.yml src\n$ cd bin\n$ ls\nblinky\n$ cd blinky\n$ ls\nblinky.elf blinky.elf.bin blinky.elf.cmd blinky.elf.lst blinky.elf.map\n\n\n\n\n\n\n\nCheck that you have all the scripts needed to get OpenOCD up and talking with the project's specific hardware. Depending on your system (Ubuntu, Windows) you may already have the scripts in your \n/usr/share/openocd/scripts/\n directory as they may have been part of the openocd download. If yes, you are all set and can proceed to preparing the hardware.\n\n\n\n\n\n\nOtherwise check the \n~/dev/larva/hw/bsp/olimex_stm32-e407_devboard\n directory for a file named \nf407.cfg\n. That is the config we will use to talk to this specific hardware
using OpenOCD. You are all set if you see it.\n\n\n $ ls ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard\n bin olimex_stm32-e407_devboard_debug.sh\n boot-olimex_stm32-e407_devboard.ld olimex_stm32-e407_devboard_download.sh\n egg.yml run_from_flash.ld\n f407.cfg run_from_loader.ld\n include run_from_sram.ld\n olimex_stm32-e407_devboard.ld src\n\n\n\nPreparing the hardware to boot from embedded SRAM\n\n\n\n\n\n\nLocate the boot jumpers on the board.\n\n\n\n\n\n\n\n\n\nB1_1/B1_0 and B0_1/B0_0 are PTH jumpers which can be moved relatively easy. Note that the markings on the board may not always be accurate. Always refer to the manual for the correct positioning of jumpers in case of doubt. The two jumpers must always be moved together \u2013 they are responsible for the boot mode if bootloader is present. The board can search for bootloader on three places \u2013 User Flash Memory, System Memory or
the Embedded SRAM. We will configure it to boot from SRAM by jumpering B0_1 and B1_1.\n\n\n\n\n\n\nConnect USB-OTG#2 in the picture above to a USB port on your computer (or a powered USB hub to make sure there is enough power available to the board). \n\n\n\n\n\n\nThe red PWR LED should be lit. \n\n\n\n\n\n\nConnect the JTAG connector to the SWD/JTAG interface on the board. The other end of the cable should be connected to the USB port or hub of your computer.\n\n\n\n\n\n\nLet's Go!\n\n\n\n\n\n\nMake sure you are in the blinky project directory with the blinky.elf executable. Run the debug command in the newt tool. You should see some status messages are shown below. There is an inbuilt \n-c \"reset halt\"\n flag that tells it to halt after opening the session.\n\n\n$ cd dev/larva/project/blinky/bin/blinky\n$ newt target debug blinky\nDebugging with /Users/aditihilbert/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_debug.sh blinky\nDebugging /Users/aditihilb
ert/dev/larva/project/blinky/bin/blinky/blinky.elf\nGNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs\nCopyright (C) 2014 Free Software Foundation, Inc.\nLicense GPLv3+: GNU GPL version 3 or later \nhttp://gnu.org/licenses/gpl.html\n\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law. Type \"show copying\"\nand \"show warranty\" for details.\nThis GDB was configured as \"--host=x86_64-apple-darwin10 --target=arm-none-eabi\".\nType \"show configuration\" for configuration details.\nFor bug reporting instructions, please see:\n\nhttp://www.gnu.org/software/gdb/bugs/\n.\nFind the GDB manual and other documentation resources online at:\n\nhttp://www.gnu.org/software/gdb/documentation/\n.\nFor help, type \"help\".\nType \"apropos word\" to search for commands related to \"word\"...\nReading symbols from /Users/aditihilbert/dev/larva/project/blinky/bin/ blinky/blinky.elf...done.\nOpen On-Chip D
ebugger 0.8.0 (2015-09-22-18:21)\nLicensed under GNU GPL v2\nFor bug reports, read\n http://openocd.sourceforge.net/doc/doxygen/bugs.html\nInfo : only one transport option; autoselect 'jtag'\nadapter speed: 1000 kHz\nadapter_nsrst_delay: 100\njtag_ntrst_delay: 100\nWarn : target name is deprecated use: 'cortex_m'\nDEPRECATED! use 'cortex_m' not 'cortex_m3'\ncortex_m reset_config sysresetreq\nInfo : clock speed 1000 kHz\nInfo : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)\nInfo : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)\nInfo : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints\nInfo : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)\nInfo : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)\ntarget state: halted\ntarget halted due to debug-request, current mode: Thread \nxPSR: 0x01000000 pc: 0x20000250 msp: 0x
10010000\nInfo : accepting 'gdb' connection from 3333\nInfo : device id = 0x10036413\nInfo : flash size = 1024kbytes\nReset_Handler () at startup_STM32F40x.s:199\n199 ldr r1, =__etext\n\n\n\nCheck the value of the msp (main service pointer) register. If it is not 0x10010000 as indicated above, you will have to manually set it after you open the gdp tool and load the image on it. \n\n\n(gdb) set $msp=0x10010000\n\n\n\nNow load the image and type \"c\" or \"continue\" from the GNU debugger. \n\n\n(gdb) load ~/dev/larva/project/blinky/bin/blinky/blinky.elf\nLoading section .text, size 0x4294 lma 0x20000000\nLoading section .ARM.extab, size 0x24 lma 0x20004294\nLoading section .ARM.exidx, size 0xd8 lma 0x200042b8\nLoading section .data, size 0x874 lma 0x20004390\nStart address 0x20000250, load size 19460\nTransfer rate: 81 KB/sec, 2432 bytes/write.\n(gdb) c\nContinuing.\n\n\n\n\n\n\n\nVoil\u00e0! The board's LED should be blinking at 1 Hz.\n\n\n\n\n\n\nUsing flash to make LED bli
nk\n\n\nYou are here because you want to build an image to be run from flash memory on the Olimex board.\n\n\n\n\nConfigure the board to boot from flash by moving the two jumpers together to B0_0 and B1_0. Refer to the pictures of the board under the section titled \n\"Preparing the hardware to boot from embedded SRAM\"\n.\n\n\n\n\nYou will have to reset the board once the image is uploaded to it.\n\n\n\n\n\n\nIf you skipped the first option for the project \n(downloading an image to SRAM)\n, then skip this step. Otherwise, continue with this step. \n\n\nBy default, the linker script (\nolimex_stm32-e407_devboard.ld\n) is configured to run from bootloader and flash. However, if you first ran the image from SRAM you had changed \nolimex_stm32-e407_devboard.ld\n to match \nrun_from_sram.ld\n. You will therefore return to defaults with \nolimex_stm32-e407_devboard.ld\n linker script matching the contents of 'run_from_loader.ld'. Return to the project directory.\n\n\n$ cd ~/dev/larva/hw
/bsp/olimex_stm32-e407_devboard\n$ diff olimex_stm32-e407_devboard.ld run_from_sram.ld\n$ diff olimex_stm32-e407_devboard.ld run_from_loader.ld\n$ cp run_from_loader.ld olimex_stm32-e407_devboard.ld\n$ cd ~/dev/larva/project/blinky/bin/blinky\n\n\n\n\n\n\n\nIn order to run the image from flash, you need to build the bootloader as well. The bootloader does the initial bring up of the Olimex board and then transfers control to the image stored at a location in flash known to it. The bootloader in turn requires the bin2image tool to check the image header for version information, CRC checks etc. So, we will need to build these two additional targets (bootloader and bin2img).\n\n\n\n\n\n\nLet's first create bin2img:\n\n\n $ newt target create bin2img\n Creating target bin2img\n Target bin2img successfully created!\n $ newt target set bin2img arch=sim\n Target bin2img successfully set arch to sim\n $ newt target set bin2img compiler=sim\n Target bin2img successfully
set compiler to sim\n $ newt target set bin2img project=bin2img\n Target bin2img successfully set project to bin2img\n $ newt target set bin2img compiler_def=debug\n Target bin2img successfully set compiler_def to debug\n $ newt target set bin2img bsp=hw/bsp/native\n Target bin2img successfully set bsp to hw/bsp/native\n $ newt target show bin2img\n bin2img\n arch: sim\n compiler: sim\n project: bin2img\n compiler_def: debug\n bsp: hw/bsp/native\n name: bin2img\n\n\n\nAnd then let's create boot_olimex:\n\n\n $ newt target create boot_olimex\n Creating target boot_olimex\n Target boot_olimex successfully created!\n $ newt target set boot_olimex arch=cortex_m4\n Target boot_olimex successfully set arch to cortex_m4\n $ newt target set boot_olimex compiler=arm-none-eabi-m4\n Target boot_olimex successfully set compiler to arm-none-eabi-m4\n $ newt target set boot_olimex project=boot\n Target bo
ot_olimex successfully set project to boot\n $ newt target set boot_olimex compiler_def=optimized\n Target boot_olimex successfully set compiler_def to optimized\n $ newt target set boot_olimex bsp=hw/bsp/olimex_stm32-e407_devboard\n Target boot_olimex successfully set bsp to hw/bsp/olimex_stm32-e407_devboard\n $ newt target show boot_olimex\n boot_olimex\n project: boot\n compiler_def: optimized\n bsp: hw/bsp/olimex_stm32-e407_devboard\n name: boot_olimex\n arch: cortex_m4\n compiler: arm-none-eabi-m4\n\n\n\n\n\n\n\nLet's build all the three targets now.\n\n\n$ newt target build bin2img\nBuilding target bin2img (project = bin2img)\nBuilding project bin2img\nSuccessfully run!\n$ newt target build boot_olimex\nBuilding target boot_olimex (project = boot)\nBuilding project boot\nSuccessfully run!\n$ newt target build blinky\nBuilding target blinky (project = blinky)\nBuilding project blinky\nSuccessfully run!\n\n\n\n\n\n\n\nG
o to the project directory and download the bootloader and the image to flash ... in a flash! \n\n\n$ cd ~/dev/larva/project/blinky/bin/blinky\n$ newt target download boot_olimex\nDownloading with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_download.sh\n$ newt target download blinky\nDownloading with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_download.sh\n\n\n\n\n\n\n\nThe LED should be blinking!\n\n\n\n\n\n\nBut 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. \n\n\nThe LED light will start blinking again. Success!\n\n\nNote #1: If you want to download the image to flash and a gdb session opened up, use \nnewt targe
t debug blinky\n instead of \nnewt target download blinky\n.\n\n\n$ newt target debug blinky\nDebugging with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_debug.sh blinky\nDebugging ~/dev/larva/project/blinky/bin/blinky/blinky.elf\nGNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs\nCopyright (C) 2014 Free Software Foundation, Inc.\nLicense GPLv3+: GNU GPL version 3 or later \nhttp://gnu.org/licenses/gpl.html\n\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law. Type \"show copying\"\nand \"show warranty\" for details.\nThis GDB was configured as \"--host=x86_64-apple-darwin10 --target=arm-none-eabi\".\nType \"show configuration\" for configuration details.\nFor bug reporting instructions, please see:\n\nhttp://www.gnu.org/software/gdb/bugs/\n.\nFind the GDB manual and other documentation resources online at:\n\nhttp://www.gnu.org/software/gdb/documentation/\n.\nFor hel
p, type \"help\".\nType \"apropos word\" to search for commands related to \"word\"...\nReading symbols from /Users/aditihilbert/dev/larva/project/blinky/bin/blinky/blinky.elf...done.\nOpen On-Chip Debugger 0.8.0 (2015-09-22-18:21)\nLicensed under GNU GPL v2\nFor bug reports, read\n http://openocd.sourceforge.net/doc/doxygen/bugs.html\nInfo : only one transport option; autoselect 'jtag'\nadapter speed: 1000 kHz\nadapter_nsrst_delay: 100\njtag_ntrst_delay: 100\nWarn : target name is deprecated use: 'cortex_m'\nDEPRECATED! use 'cortex_m' not 'cortex_m3'\ncortex_m reset_config sysresetreq\nInfo : clock speed 1000 kHz\nInfo : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)\nInfo : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)\nInfo : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints\nInfo : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)\nInfo : JTAG tap:
stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)\ntarget state: halted\ntarget halted due to debug-request, current mode: Thread \nxPSR: 0x01000000 pc: 0x08000250 msp: 0x10010000\nInfo : accepting 'gdb' connection from 3333\nInfo : device id = 0x10036413\nInfo : flash size = 1024kbytes\nReset_Handler () at startup_STM32F40x.s:199\n199 ldr r1, =__etext\n(gdb)\n\n\n\nNote #2: If you want to erase the flash and load the image again you may use the following commands from within gdb. \nflash erase_sector 0 0 x\n 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.\n\n\n(gdb) monitor flash erase_sector 0 0 4\nerased sectors 0 throu
gh 4 on flash bank 0 in 2.296712s\n(gdb) monitor mdw 0x08000000 16\n0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff \n(0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff \n(0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff \n(0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff \n(gdb) monitor flash info 0\n\nmonitor flash erase_check 0",
- "title": "Blinky, The First Project"
- },
- {
- "location": "/get_started/project1/#blinky-the-first-project",
- "text": "Objective 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 Project Blinky . The goals of this tutorial are threefold: First, you will learn how to set up your environment to be ready to use Mynewt OS and newt tool. Second, we will walk you through a download of eggs for building and testing on a simulated target . Third, you will download eggs and use tools to create a runtime image for a board to make its LED blink. You have two choices here - you can download an image to SRAM or you can download it to flash . Time Requirement : Allow yourself a couple of hours for this project if you are relatively new to embedded systems and playing with development boards. Those jumpers can be pesky! What you need STM32-E407 development board from Olimex. You can order it from http://www.mouser.com , http://www.digikey.com , and other places. ARM-USB-TINY-H connector with JTAG interface f
or debugging ARM microcontrollers (comes with the ribbon cable to hook up to the board) USB A-B type cable to connect the debugger to your personal computer Personal Computer The instructions assume the user is using a Bourne-compatible shell (e.g. bash or zsh) on your computer. The given instructions have been tested with the following releases of operating systems: Mac: OS X Yosemite Version 10.10.5 Linux: Ubuntu 14.10 (Utopic Unicorn) Windows: Windows 10 Access to the Apache repo Get an account on Apache. You do not need a committer account to view the website or clone the repository but you need it to push changes to it. The latest codebase for the Mynewt OS is on the master branch at https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git The latest codebase for the Newt tool is on the master branch at https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git The following shows how to clone a Mynewt OS code repository: Non Committers
$ git clone http://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git Committers $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git Getting your Mac Ready Installing Homebrew to ease installs on OS X Do you have Homebrew? If not, open a terminal on your Mac and paste the following at a Terminal prompt. It will ask you for your sudo password. $ ruby -e \"$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)\" Alternatively, you can just extract (or git clone ) Homebrew and install it to /usr/local . Installing Go The directory structure must be first readied for using Go. Go code must be kept inside a workspace. A workspace is a directory hierarchy with three directories at its root: src contains Go source files organized into packages (one package per directory), pkg contains package objects, and bin contains executable commands. The GOPATH environment variable specifies the location of
your workspace. First create a 'dev' directory and then a 'go' directory under it. Set the GOPATH environment variable to this directory where you will soon clone the newt tool repository. $ cd $HOME\n$ mkdir -p dev/go \n$ cd dev/go\n$ export GOPATH=`pwd` Note that you need to add export statements to ~/.bash_profile to export variables permanently. Don't forget to source the file for the change to go into effect. $ vi ~/.bash_profile\n$ source ~/.bash_profile Next you will use Homebrew to install Go. The summary message at the end of the installation should indicate that it is installed in the /usr/local/Cellar/go/ directory. You will use the Go command 'install' to compile and install packages (called eggs in the Mynewt world) and dependencies. $ brew install go\n== \n...\n... \n== *Summary*\n\ud83c\udf7a /usr/local/Cellar/go/1.5.1: 5330 files, 273M Alternatively, you can download the Go package directly from (https://golang.org/dl/) instead of brewing it. Install it
in /usr/local directory. Creating local repository You are ready to download the newt tool repository. You will use Go to copy the directory (currently the asf incubator directory). Be patient as it may take a minute or two. Check the directories installed. $ go get git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt\n$ ls\n bin pkg src\n$ ls src\ngit-wip-us.apache.org github.com gopkg.in Check that newt.go is in place. $ ls $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt \nGodeps README.md coding_style.txt newt.go\nLICENSE cli design.txt Building the Newt tool You will use Go to run the newt.go program to build the newt tool. The command used is go install which compiles and writes the resulting executable to an output file named newt . It installs the results along with its dependencies in $GOPATH/bin. $ cd $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt
.git/newt\n$ go install\n$ ls \"$GOPATH\"/bin/\ngodep incubator-mynewt-newt.git newt Try running newt using the compiled binary. For example, check for the version number by typing 'newt version'. See all the possible commands available to a user of newt by typing 'newt -h'. Note: If you are going to be be modifying the newt tool itself often and wish to compile the program every time you call it, you may want to store the command in a variable in your .bash_profile. So type in export newt=\"go run $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt/newt/go\" in your .bash_profile and execute it by calling $newt at the prompt instead of newt . Here, you use go run which runs the compiled binary directly without producing an executable. Don't forget to reload the updated bash profile by typing source ~/.bash_profile at the prompt! $ newt version\n Newt version: 1.0\n $ newt -h\n Newt allows you to create your own embedde
d project based on the Mynewt\n operating system. Newt provides both build and package management in a\n single tool, which allows you to compose an embedded workspace, and set\n of projects, and then build the necessary artifacts from those projects.\n For more information on the Mynewt operating system, please visit\n https://www.github.com/mynewt/documentation.\n\n Please use the newt help command, and specify the name of the command\n you want help for, for help on how to use a specific command\n\n Usage:\n newt [flags]\n newt [command]\n\n Examples:\n newt\n newt help [ command-name ]\n For help on command-name . If not specified, print this message.\n\n\n Available Commands:\n version Display the Newt version number.\n target Set and view target information\n egg Commands to list and inspect eggs on a nest\n nest Commands to manage nests clutches (remote egg repositories)\n help
Help about any command\n\n Flags:\n -h, --help=false: help for newt\n -l, --loglevel=\"WARN\": Log level, defaults to WARN.\n -q, --quiet=false: Be quiet; only display error output.\n -s, --silent=false: Be silent; don't output anything.\n -v, --verbose=false: Enable verbose output when executing commands.\n\n\n Use \"newt help [command]\" for more information about a command. Without creating a project repository you can't do a whole lot with the Newt tool. So you'll have to wait till you have downloaded a nest to try out the tool. Getting the debugger ready Before you start building nests and hatching eggs, you need to do one final step in the environment preparation - install gcc / libc that can produce 32-bit executables. So, first install gcc. You will see the brew steps and a final summary confirming install. $ brew install gcc\n...\n...\n== Summary\n\ud83c\udf7a /usr/local/Cellar/gcc/5.2.0: 1353 files, 248M ARM maintains a pre-b
uilt GNU toolchain with a GCC source branch targeted at Embedded ARM Processors namely Cortex-R/Cortex-M processor families. Install the PX4 Toolchain and check the version installed. Make sure that the symbolic link installed by Homebrew points to the correct version of the debugger. If not, you can either change the symbolic link using the \"ln -f -s\" command or just go ahead and try with the version it points to! $ brew tap PX4/homebrew-px4\n$ brew update\n$ brew install gcc-arm-none-eabi-49\n$ arm-none-eabi-gcc --version \narm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288]\nCopyright (C) 2014 Free Software Foundation, Inc.\nThis is free software; see the source for copying conditions. There is NO\nwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n$ ls -al /usr/local/bin/arm-none-eabi-gdb\nlrwxr-xr-x 1 aditihilbert admin 69 Sep 22 17:16 /usr/local/bin/arm-none-eabi-gdb - /
usr/local/Cellar/gcc-arm-none-eabi-49/20150609/bin/arm-none-eabi-gdb Note: If no version is specified, brew will install the latest version available. MynewtOS will eventually work with multiple versions available including the latest releases. However, at present we have tested only with this version and recommend it for getting started. You have to install OpenOCD (Open On-Chip Debugger) which is an open-source software that will allow you to interface with the JTAG debug connector/adaptor for the Olimex board. It lets you program, debug, and test embedded target devices which, in this case, is the Olimex board. Use brew to install it. Brew adds a simlink /usr/local/bin/openocd to the openocd directory in the Cellar. For more on OpenOCD go to http://openocd.org . $ brew install open-ocd\n$ which openocd\n/usr/local/bin/openocd\n$ ls -l $(which openocd)\nlrwxr-xr-x 1 user admin 36 Sep 17 16:22 /usr/local/bin/openocd - ../Cellar/open-ocd/0.9.0/bin/openocd Proceed to
the Building test code on simulator section. Getting your Ubuntu machine Ready Installing some prerequisites Install git, libcurl, and the Go language if you do not have them already. $ sudo apt-get install git \n$ sudo apt-get install libcurl4-gnutls-dev \n$ sudo apt-get install golang Creating local repository The directory structure must be first readied for using Go. Go code must be kept inside a workspace. A workspace is a directory hierarchy with three directories at its root: src contains Go source files organized into packages (one package per directory), pkg contains package objects, and bin contains executable commands. The GOPATH environment variable specifies the location of your workspace. First create a 'dev' directory and then a 'go' directory under it. Set the GOPATH environment variable to this directory where you will soon clone the newt tool repository. $ cd $HOME\n$ mkdir -p dev/go \n$ cd dev/go\n$ export GOPATH=$PWD Note that you nee
d to add export statements to ~/.bashrc (or equivalent) to export variables permanently. You are ready to download the newt tool repository. You will use Go to copy the directory (currently the asf incubator directory). Be patient as it may take a minute or two. Check the directories installed. $ go get git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt\n$ ls\n bin pkg src\n$ ls src\ngit-wip-us.apache.org github.com gopkg.in Check that newt is in place. $ ls $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt \nGodeps README.md coding_style.txt newt.go\nLICENSE cli design.txt Building the newt tool You will use Go to run the newt.go program to build the newt tool. The command used is go install which compiles and writes the resulting executable to an output file named newt . It installs the results along with its dependencies in $GOPATH/bin. $ cd $GOPATH/src/git-wip-us.apache.org
/repos/asf/incubator-mynewt-newt.git/newt\n$ go install\n$ ls \"$GOPATH\"/bin/\ngodep incubator-mynewt-newt.git newt Try running newt using the compiled binary. For example, check for the version number by typing 'newt version'. See all the possible commands available to a user of newt by typing 'newt -h'. Note: If you are going to be be modifying the newt tool itself often and wish to compile the program every time you call it, you may want to store the command in a variable in your .bash_profile. So type in export newt=\"go run $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt/newt/go\" in your ~/.bashrc (or equivalent) and execute it by calling $newt at the prompt instead of newt . Here, you use go run which runs the compiled binary directly without producing an executable. $ newt version\n Newt version: 1.0\n $ newt -h\n Newt allows you to create your own embedded project based on the Mynewt\n operating system.
Newt provides both build and package management in a\n single tool, which allows you to compose an embedded workspace, and set\n of projects, and then build the necessary artifacts from those projects.\n For more information on the Mynewt operating system, please visit\n https://www.github.com/mynewt/documentation.\n\n Please use the newt help command, and specify the name of the command\n you want help for, for help on how to use a specific command\n\n Usage:\n newt [flags]\n newt [command]\n\n Examples:\n newt\n newt help [ command-name ]\n For help on command-name . If not specified, print this message.\n\n\n Available Commands:\n version Display the Newt version number.\n target Set and view target information\n egg Commands to list and inspect eggs on a nest\n nest Commands to manage nests clutches (remote egg repositories)\n help Help about any command\n\n Flags:\n -
h, --help=false: help for newt\n -l, --loglevel=\"WARN\": Log level, defaults to WARN.\n -q, --quiet=false: Be quiet; only display error output.\n -s, --silent=false: Be silent; don't output anything.\n -v, --verbose=false: Enable verbose output when executing commands.\n\n\n Use \"newt help [command]\" for more information about a command. Without creating a project repository you can't do a whole lot with the Newt tool. So you'll have to wait till you have downloaded a nest to try out the tool. Getting the debugger ready Before you start building nests and hatching eggs, you need to do one final step in the environment preparation - install gcc / libc that can produce 32-bit executables. You can install these as follows: $ sudo apt-get install gcc-multilib libc6-i386 For the LED project on the Olimex hardware, you have to install gcc for AM 4.9.3. This package can be installed with apt-get as documented below. The steps are explained in depth at h
ttps://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded . $ sudo apt-get remove binutils-arm-none-eabi gcc-arm-none-eabi \n$ sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded \n$ sudo apt-get update \n$ sudo apt-get install gcc-arm-none-eabi And finally, you have to install OpenOCD (Open On-Chip Debugger) which is an open-source software that will allow you to interface with the JTAG debug connector/adaptor for the Olimex board. It lets you program, debug, and test embedded target devices which, in this case, is the Olimex board. You have to acquire OpenOCD 0.8.0. If you are running Ubuntu 15.x, then you are in luck and you can simply run: $ sudo apt-get install openocd Other versions of Ubuntu may not have the correct version of openocd available. In this case, you should download the openocd 0.8.0 package from https://launchpad.net/ubuntu/vivid/+source/openocd . The direct link to the amd64 build is http://launchpadlibrarian.net/188260097/openocd_0.8.0-4_
amd64.deb . Proceed to the Building test code on simulator section. Getting your Windows machine ready for simulated target The newt tool is the build software used to build Mynewt OS images or executables for any embedded hardware device/board, including the one for the current tutorial (STM32-E407 development board from Olimex). You can run the newt tool natively on a computer running any of the three Operating System machines - OSX, Linux, or Windows. However, Mynewt OS images for a simulated target are built on the Windows machine by using Linux versions of the build software (newt)in a virtual machine on your Windows box. The Linux VM is set up by installing the Docker Toolbox. Your Windows machine will communicate with the Linux VM via transient ssh connections. You will then download a Docker image ( newtvm.exe )that allows you to run the newt commands in the Linux Docker instance. The Docker image contains: The newt command-line tool Go A multilib-capable
native gcc / glibc An arm-none-eabi gcc Native gdb The sequence of events when using the Docker image is as follows: A new docker environment is created in the Linux VM. The specified command with the newtvm prefix ( newtvm newt command) is sent to the docker environment via ssh. The Linux command runs. The output from the command is sent back to Windows via ssh. The output is displayed in the Windows command prompt. Install Linux virtual machine Download the Docker Toolbox for Windows (version 1.9.0c or later) from https://www.docker.com/docker-toolbox . The Docker toolbox creates a consistently reproducible and self-contained environment in Linux. Run the Docker Toolbox installer. All the default settings are OK. You may need to add \"C:\\Program Files\\Git\\usr\\bin\" to your PATH\nenvironment variable. To add to the PATH environment variable, right-click on the Start button in the bottom left corner. Choose System - Advanced system settings - Environme
nt Variables. Click on the PATH variable under \"System variables\" and click Edit to check and add it if it is not already there. Install newtvm tool From your base user (home) directory, pull or clone the latest code from the newt repository into the newt directory. It includes the executable newtvm.exe for the newtvm tool in the newtvm directory. C:\\Users\\admin git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt newt The newtvm tool is what allows you to run programs in the Linux docker\ninstance. Run the Docker Quickstart Terminal application inside the Docker folder under Programs. You can find it by clicking Start button - All apps. By default, the Docker Toolbox installer creates a shortcut to this program on your desktop. Wait until you see an ASCII art whale displayed in the terminal window and the Docker prompt given. ## .\n ## ## ## ==\n ## ## ## ## ## ===\n /\"\"\"\
"\"\"\"\"\"\"\
<TRUNCATED>