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/04/26 23:02:28 UTC
[6/7] incubator-mynewt-site git commit: Lots of HAL additions by P
Dietrich. This closes #73. BLE security blurb added. Docker container and
quick start docs cleaned up
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/a946b6be/mkdocs/search_index.json
----------------------------------------------------------------------
diff --git a/mkdocs/search_index.json b/mkdocs/search_index.json
index 383df2e..2cf2f35 100644
--- a/mkdocs/search_index.json
+++ b/mkdocs/search_index.json
@@ -7,17 +7,17 @@
},
{
"location": "/about/",
- "text": "Features\n\n\nApache Mynewt's open-source embedded software is designed with the following components:\n\n\n\n\nMynewt OS: Real-time operating system kernel (Scheduler, Mutexes, Semaphores, etc.)\n\n\nNewt tool: Command line package management and build system \n\n\nHardware Abstraction Layer unifying common MCU features (e.g. GPIOs, High Resolution Timers, PWM interfaces, UARTs, ADCs, etc.)\n\n\nBoard Support Infrastructure, that defines the framework for building software for various board architectures.\n\n\nImage management and upgrade using the secure bootloader, and flash filesystem.\n\n\nSystem configuration that allows collection of logs and statistics for all packages (with filtering options) ranging from OS-level resources such as memory pools, priorities to interface level counters such as packet exchange and queues\n\n\nCore dump captures to enable remote diagnosis of device failures and hiccups\n\n\nNetwork protocol stacks \n\n\nFirst fully open-sou
rce BLE 4.2 stack\n\n\nSupport for PDUs of up to 251 bytes for high throughput\n\n\nSupport for all 4 roles to be run concurrently - Broadcaster, Observer, Peripheral, Central\n\n\nRandom addresses for link-layer security\n\n\nSecurity Manager Protocol\n\n\nLE Secure Connections\n\n\n\n\n\n\n\n\n\n\n\n\nRoadmap\n\n\n\n\n\n\n\n\nRelease Version\n\n\nDescriptor\n\n\nDate\n\n\nFeatures\n\n\n\n\n\n\n\n\n\n\n0.8.0b2\n\n\nBeta #2 before pre-GA release #1\n\n\nmid-March, 2016\n\n\n* Arduino Zero support\n\n\n\n\n\n\n\n\n\n\n\n\n* OS Time\n\n\n\n\n\n\n\n\n\n\n\n\n* Several new tutorials for OS\n\n\n\n\n\n\n\n\n\n\n\n\n* Tutorials for BLE 4.2\n\n\n\n\n\n\n\n\n\n\n\n\n* BLE 4.2: Random static address\n\n\n\n\n\n\n0.8.0\n\n\npre-GA release #1\n\n\nmid-April, 2016\n\n\n* HAL extensions in OS\n\n\n\n\n\n\n\n\n\n\n\n\n* Arduino DUE support\n\n\n\n\n\n\n\n\n\n\n\n\n* Image verification\n\n\n\n\n\n\n\n\n\n\n\n\n* BLE 4.2 stats and logs\n\n\n\n\n\n\n\n\n\n\n\n\n* Crash dump capture and retrieval\n\n
\n\n\n\n\n0.9.0b1\n\n\nBeta before pre-GA release #2\n\n\nmid-May, 2016\n\n\n* Support images in external flash\n\n\n\n\n\n\n\n\n\n\n\n\n* Support for low power modes in multiple SoCs\n\n\n\n\n\n\n\n\n\n\n\n\n* BLE 4.2: LE legacy pairing\n\n\n\n\n\n\n\n\n\n\n\n\n* BLE 4.2: LE Secure Connections\n\n\n\n\n\n\n\n\n\n\n\n\n* BLE 4.2: Host and Controller separation\n\n\n\n\n\n\n\n\n\n\n\n\n* BLE 4.2: Random private resolvable addresses\n\n\n\n\n\n\n\n\n\n\n\n\n* BLE 4.2 stats and logs\n\n\n\n\n\n\n0.9.0\n\n\npre-GA release #2\n\n\nmid-June, 2016\n\n\n* Test coverage improvements\n\n\n\n\n\n\n\n\n\n\n\n\n* BLE 4.2: GATT based BLE profiles for Mynewt\n\n\n\n\n\n\n\n\n\n\n\n\n* BLE 4.2: Configurability improvements\n\n\n\n\n\n\n\n\n The detailed roadmap is tracked on \nJIRA for Mynewt\n. \n\n\nFeature Request\n\n\nThe WISHLIST at the top of the roadmap on \nJIRA for Mynewt\n features all the new ideas awaiting discussion and review. Once the community decides to go ahead with a request, it
is scheduled into a release. Generally, effort is made to schedule a requested feature into a particular version no later than 6 weeks prior to the planned release date.\n\n\nIf you have suggestions for a new feature, use case, or implementation improvements, file a JIRA ticket with Issue Type set to \"Wish\". Introduce it in the \ndev@\n mailing list with a link to the JIRA ticket. This assumes you have signed up for an account on JIRA and submitted a request to the dev@ mailing list for your JIRA username to be added to the Apache Mynewt (MYNEWT) project. \n\n\nFAQ\n\n\n Questions? \n Click \nhere",
+ "text": "Features\n\n\nApache Mynewt's open-source embedded software is designed with the following components:\n\n\n\n\nMynewt OS: Real-time operating system kernel (Scheduler, Mutexes, Semaphores, etc.)\n\n\nNewt tool: Command line package management and build system \n\n\nHardware Abstraction Layer unifying common MCU features (e.g. GPIOs, High Resolution Timers, PWM interfaces, UARTs, ADCs, etc.)\n\n\nBoard Support Infrastructure, that defines the framework for building software for various board architectures.\n\n\nImage management and upgrade using the secure bootloader, and flash filesystem.\n\n\nSystem configuration that allows collection of logs and statistics for all packages (with filtering options) ranging from OS-level resources such as memory pools, priorities to interface level counters such as packet exchange and queues\n\n\nCore dump captures to enable remote diagnosis of device failures and hiccups\n\n\nNetwork protocol stacks \n\n\nWorld's first fully
open-source BLE 4.2 stack\n\n\nSupport for PDUs of up to 251 bytes for high throughput\n\n\nSupport for all 4 roles to be run concurrently - Broadcaster, Observer, Peripheral, Central\n\n\nRandom addresses for link-layer security\n\n\nSecurity Manager Protocol\n\n\nLE Secure Connections\n\n\n\n\n\n\n\n\n\n\n\n\nRoadmap\n\n\n\n\n\n\n\n\nRelease Version\n\n\nDescriptor\n\n\nDate\n\n\nFeatures\n\n\n\n\n\n\n\n\n\n\n0.8.0\n\n\npre-GA release #1\n\n\nlate-April, 2016\n\n\n* HAL extensions in OS\n\n\n\n\n\n\n\n\n\n\n\n\n* Arduino DUE support\n\n\n\n\n\n\n\n\n\n\n\n\n* Image verification\n\n\n\n\n\n\n\n\n\n\n\n\n* Stats and logs enhancement\n\n\n\n\n\n\n\n\n\n\n\n\n* HAL additions: ADC, DAC, I2C, PWM, SPI\n\n\n\n\n\n\n\n\n\n\n\n\n* BLE 4.2: LE legacy pairing\n\n\n\n\n\n\n\n\n\n\n\n\n* BLE 4.2: Code size optimization\n\n\n\n\n\n\n0.9.0\n\n\npre-GA release #2\n\n\nMay, 2016\n\n\n* Support images in external flash\n\n\n\n\n\n\n\n\n\n\n\n\n* System watchdog\n\n\n\n\n\n\n\n\n\n\n\n\n* Support fo
r low power modes in multiple SoCs\n\n\n\n\n\n\n\n\n\n\n\n\n* BLE 4.2: LE Secure Connections\n\n\n\n\n\n\n\n\n\n\n\n\n* BLE 4.2: Host and Controller separation\n\n\n\n\n\n\n\n\n\n\n\n\n* BLE 4.2: Random private resolvable addresses\n\n\n\n\n\n\n\n\n\n\n\n\n* BLE 4.2: Remote configuration, upgrade, factory reset over BLE 4.2\n\n\n\n\n\n\n\n\n\n\n\n\n* BLE 4.2: Factory reset\n\n\n\n\n\n\n0.10.0\n\n\npre-GA release #3\n\n\nJune, 2016\n\n\n* Test coverage improvements\n\n\n\n\n\n\n\n\n\n\n\n\n* Support for additional Arduino boards\n\n\n\n\n\n\n\n\n\n\n\n\n* BLE 4.2: GATT based BLE profiles for Mynewt\n\n\n\n\n\n\n\n\n\n\n\n\n* BLE 4.2: Configurability improvements\n\n\n\n\n\n\n\n\n The detailed roadmap is tracked on \nJIRA for Mynewt\n. \n\n\nFeature Request\n\n\nThe WISHLIST at the top of the roadmap on \nJIRA for Mynewt\n features all the new ideas awaiting discussion and review. Once the community decides to go ahead with a request, it is scheduled into a release. Generally, effort
is made to schedule a requested feature into a particular version no later than 6 weeks prior to the planned release date.\n\n\nIf you have suggestions for a new feature, use case, or implementation improvements, file a JIRA ticket with Issue Type set to \"Wish\". Introduce it in the \ndev@\n mailing list with a link to the JIRA ticket. This assumes you have signed up for an account on JIRA and submitted a request to the dev@ mailing list for your JIRA username to be added to the Apache Mynewt (MYNEWT) project. \n\n\nFAQ\n\n\n Questions? \n Click \nhere",
"title": "About"
},
{
"location": "/about/#features",
- "text": "Apache Mynewt's open-source embedded software is designed with the following components: Mynewt OS: Real-time operating system kernel (Scheduler, Mutexes, Semaphores, etc.) Newt tool: Command line package management and build system Hardware Abstraction Layer unifying common MCU features (e.g. GPIOs, High Resolution Timers, PWM interfaces, UARTs, ADCs, etc.) Board Support Infrastructure, that defines the framework for building software for various board architectures. Image management and upgrade using the secure bootloader, and flash filesystem. System configuration that allows collection of logs and statistics for all packages (with filtering options) ranging from OS-level resources such as memory pools, priorities to interface level counters such as packet exchange and queues Core dump captures to enable remote diagnosis of device failures and hiccups Network protocol stacks First fully open-source BLE 4.2 stack Support for PDUs of up to 251 byte
s for high throughput Support for all 4 roles to be run concurrently - Broadcaster, Observer, Peripheral, Central Random addresses for link-layer security Security Manager Protocol LE Secure Connections",
+ "text": "Apache Mynewt's open-source embedded software is designed with the following components: Mynewt OS: Real-time operating system kernel (Scheduler, Mutexes, Semaphores, etc.) Newt tool: Command line package management and build system Hardware Abstraction Layer unifying common MCU features (e.g. GPIOs, High Resolution Timers, PWM interfaces, UARTs, ADCs, etc.) Board Support Infrastructure, that defines the framework for building software for various board architectures. Image management and upgrade using the secure bootloader, and flash filesystem. System configuration that allows collection of logs and statistics for all packages (with filtering options) ranging from OS-level resources such as memory pools, priorities to interface level counters such as packet exchange and queues Core dump captures to enable remote diagnosis of device failures and hiccups Network protocol stacks World's first fully open-source BLE 4.2 stack Support for PDUs of up to
251 bytes for high throughput Support for all 4 roles to be run concurrently - Broadcaster, Observer, Peripheral, Central Random addresses for link-layer security Security Manager Protocol LE Secure Connections",
"title": "Features"
},
{
"location": "/about/#roadmap",
- "text": "Release Version Descriptor Date Features 0.8.0b2 Beta #2 before pre-GA release #1 mid-March, 2016 * Arduino Zero support * OS Time * Several new tutorials for OS * Tutorials for BLE 4.2 * BLE 4.2: Random static address 0.8.0 pre-GA release #1 mid-April, 2016 * HAL extensions in OS * Arduino DUE support * Image verification * BLE 4.2 stats and logs * Crash dump capture and retrieval 0.9.0b1 Beta before pre-GA release #2 mid-May, 2016 * Support images in external flash * Support for low power modes in multiple SoCs * BLE 4.2: LE legacy pairing * BLE 4.2: LE Secure Connections * BLE 4.2: Host and Controller separation * BLE 4.2: Random private resolvable addresses * BLE 4.2 stats and logs 0.9.0 pre-GA release #2 mid-June, 2016 * Test coverage improvements * BLE 4.2: GATT based BLE profiles for Mynewt * BLE 4.2: Configurability improvements
The detailed roadmap is tracked on JIRA for Mynewt .",
+ "text": "Release Version Descriptor Date Features 0.8.0 pre-GA release #1 late-April, 2016 * HAL extensions in OS * Arduino DUE support * Image verification * Stats and logs enhancement * HAL additions: ADC, DAC, I2C, PWM, SPI * BLE 4.2: LE legacy pairing * BLE 4.2: Code size optimization 0.9.0 pre-GA release #2 May, 2016 * Support images in external flash * System watchdog * Support for low power modes in multiple SoCs * BLE 4.2: LE Secure Connections * BLE 4.2: Host and Controller separation * BLE 4.2: Random private resolvable addresses * BLE 4.2: Remote configuration, upgrade, factory reset over BLE 4.2 * BLE 4.2: Factory reset 0.10.0 pre-GA release #3 June, 2016 * Test coverage improvements * Support for additional Arduino boards * BLE 4.2: GATT based BLE profiles for Mynewt * BLE 4.2: Configurability improvements The detailed roadmap is tracke
d on JIRA for Mynewt .",
"title": "Roadmap"
},
{
@@ -107,12 +107,12 @@
},
{
"location": "/os/get_started/docker/",
- "text": "Everything You Need in a Docker Container\n\n\nDocker provides a quick and easy way to get up and running with Mynewt. The\nnewt command line tool and the entire build toolchain is available in a single\ndocker container. The container is all that's needed to run your Mynewt based\napplication in the simulator. Enabling USB2 with your docker installation will\nallow you to load your application on a supported device.\n\n\n\n\nInstall Docker\n\n\nInstall docker for your platform. \nMac OS X\n / \nWindows\n / \nLinux\n\n\nMake sure to double click the Docker Quickstart Terminal application if you're on Mac or Windows.\n\n\n\n\nUse the newt wrapper script\n\n\nUse the newt wrapper script to invoke newt. Create the following file, name it\n\nnewt\n, make it executable, and put it in your path. This will allow you to run newt as if it was natively installed. You can now follow the normal tutorials using the newt wrapper script.\n\n\n#!/bin/bash\n\n\ndocker run -ti
--rm --device\n=\n/dev/bus/usb --privileged -v \n$(pwd)\n:/workspace -w /workspace mynewt/newt:latest /newt \n$@\n\n\n\n\n\n\n\n\nNote 1:\n Remember to point to the correct subdirectory level when invoking \nnewt\n. For example, invoke it using \n../newt\n in the example below.\n\n\nuser@~/dockertest$ ls\nmyproj newt\nuser@~/dockertest$ cd myproj\n\nuser@~/dockertest/myproj$ ../newt version\n\nApache Newt (incubating) version: 0.8.0-b2\n\n\n\n\n\n\n\nNote 2:\n You can upgrade your container by running \ndocker pull mynewt/newt:latest\n when updates are made available.\n\n\n\n\nEnable USB2 Support for Mac or Windows\n\n\nIf you plan on loading your application on an actual device, do the steps below.\n\n\n\n\nInstall VirtualBox extension pack\n\n\nDocker uses a VirtualBox Linux VM to run containers. A free VirtualBox\nextension pack is required to enable USB2 support. Download the \nVirtualBox\n5.0.16 Oracle VM VirtualBox Extension\nPack\n\nand double click to install\n\n\n\n\nEn
able USB2 and select your device\n\n\n\n\n\n\nThe \"default\" VM created by docker-machine must first be stopped before you\n can enable USB2. You have two options:\n\n\n\n\nRun the command \ndocker-machine stop default\n in the terminal window or\n\n\nUse the VirtualBox UI. Right click on \ndefault\n -\n Close -\n Power Off\n\n\n\n\n\n\n\n\nEnable USB2 using the VirtualBox UI. Select the \"default\"\n VM-\nSettings-\nPorts-\nUSB2 to enable USB2. Add your device to the USB Device\n Filters to make the device visible in the docker container. See the image below.\n\n\n\n\n\n\n\n\n\n\nRestart the \"default\" VM. You have two options:\n\n\nRun \ndocker-machine start default\n in the terminal window or \n\n\nUse the VirtualBox UI. Make sure the \"default\" machine is highlighted. Click the green \"Start\" button. Select \"Headless Start\".\n\n\n\n\n\n\n\n\n\n\nNote 3\n: When working with actual hardware, remember that each board has an ID. If you swap boards and do not refresh the
USB Device Filter on the VirtualBox UI, the ID might be stale and the Docker instance may not be able to see the board correctly. For example, you may see an error message like \nError: unable to find CMSIS-DAP device\n when you try to load or run an image on the board. In that case, you need to click on the USB link in VirtualBox UI, remove the existing USB Device Filter (e.g. \"Atmel Corp. EDBG CMSIS-DAP[0101]\") by clicking on the \"Removes selected USB filter\" button, and add a new filter by clicking on the \"Adds new USB filter\" button.",
+ "text": "Everything You Need in a Docker Container\n\n\nDocker provides a quick and easy way to get up and running with Mynewt. The\nnewt command line tool and the entire build toolchain is available in a single\ndocker container. The container is all that's needed to run your Mynewt based\napplication in the simulator. Enabling USB2 with your docker installation will\nallow you to load your application on a supported device.\n\n\nThe Docker is the only supported option if you are working on a Windows machine. If you are using Mac OS X or Linux, you have the choice of installing a Docker container of tools and toolchains or installing them natively. This chapter describes how to set up the Docker image for all three platforms.\n\n\n\n\nInstall Docker\n\n\nInstall docker for your platform. \nMac OS X\n / \nWindows\n / \nLinux\n\n\nMake sure to double click the Docker Quickstart Terminal application if you're on Mac or Windows.\n\n\n\n\nUse the newt wrapper script\n\n\nUs
e the newt wrapper script to invoke newt. Create the following file, name it\n\nnewt\n, make it executable, and put it in your path. This will allow you to run newt as if it was natively installed. You can now follow the normal tutorials using the newt wrapper script.\n\n\n#!/bin/bash\n\n\ndocker run -ti --rm --device\n=\n/dev/bus/usb --privileged -v \n$(pwd)\n:/workspace -w /workspace mynewt/newt:latest /newt \n$@\n\n\n\n\n\n\n\n\nNote 1:\n Remember to point to the correct subdirectory level when invoking \nnewt\n. For example, invoke it using \n../newt\n in the example below.\n\n\nuser@~/dockertest$ ls\nmyproj newt\nuser@~/dockertest$ cd myproj\n\nuser@~/dockertest/myproj$ ../newt version\n\nApache Newt (incubating) version: 0.8.0-b2\n\n\n\n\n\n\n\nNote 2:\n You can upgrade your container by running \ndocker pull mynewt/newt:latest\n when updates are made available.\n\n\n\n\nEnable USB2 Support for Mac or Windows\n\n\nIf you plan on loading your application on an actual device,
do the steps below.\n\n\n\n\nInstall VirtualBox extension pack\n\n\nDocker uses a VirtualBox Linux VM to run containers. A free VirtualBox\nextension pack is required to enable USB2 support. Download the \nVirtualBox\n5.0.16 Oracle VM VirtualBox Extension\nPack\n\nand double click to install\n\n\n\n\nEnable USB2 and select your device\n\n\n\n\n\n\nThe \"default\" VM created by docker-machine must first be stopped before you\n can enable USB2. You have two options:\n\n\n\n\nRun the command \ndocker-machine stop default\n in the terminal window or\n\n\nUse the VirtualBox UI. Right click on \ndefault\n -\n Close -\n Power Off\n\n\n\n\n\n\n\n\nEnable USB2 using the VirtualBox UI. Select the \"default\"\n VM-\nSettings-\nPorts-\nUSB2 to enable USB2. Add your device to the USB Device\n Filters to make the device visible in the docker container. See the image below.\n\n\n\n\n\n\n\n\n\n\nRestart the \"default\" VM. You have two options:\n\n\nRun \ndocker-machine start default\n in
the terminal window or \n\n\nUse the VirtualBox UI. Make sure the \"default\" machine is highlighted. Click the green \"Start\" button. Select \"Headless Start\".\n\n\n\n\n\n\n\n\n\n\nNote 3\n: When working with actual hardware, remember that each board has an ID. If you swap boards and do not refresh the USB Device Filter on the VirtualBox UI, the ID might be stale and the Docker instance may not be able to see the board correctly. For example, you may see an error message like \nError: unable to find CMSIS-DAP device\n when you try to load or run an image on the board. In that case, you need to click on the USB link in VirtualBox UI, remove the existing USB Device Filter (e.g. \"Atmel Corp. EDBG CMSIS-DAP[0101]\") by clicking on the \"Removes selected USB filter\" button, and add a new filter by clicking on the \"Adds new USB filter\" button.",
"title": "All-in-one Docker Container"
},
{
"location": "/os/get_started/docker/#everything-you-need-in-a-docker-container",
- "text": "Docker provides a quick and easy way to get up and running with Mynewt. The\nnewt command line tool and the entire build toolchain is available in a single\ndocker container. The container is all that's needed to run your Mynewt based\napplication in the simulator. Enabling USB2 with your docker installation will\nallow you to load your application on a supported device.",
+ "text": "Docker provides a quick and easy way to get up and running with Mynewt. The\nnewt command line tool and the entire build toolchain is available in a single\ndocker container. The container is all that's needed to run your Mynewt based\napplication in the simulator. Enabling USB2 with your docker installation will\nallow you to load your application on a supported device. The Docker is the only supported option if you are working on a Windows machine. If you are using Mac OS X or Linux, you have the choice of installing a Docker container of tools and toolchains or installing them natively. This chapter describes how to set up the Docker image for all three platforms.",
"title": "Everything You Need in a Docker Container"
},
{
@@ -142,7 +142,7 @@
},
{
"location": "/os/get_started/native_tools/",
- "text": "Installing Native Mynewt Tools\n\n\nThis page shows how to install tools for native Mynewt targets (simulated targets on your laptop/computer) without using a Docker container. In other words, it allows you to run Mynewt OS as a native application on your Mac or Linux machine to simulate a target and use the Newt tool running natively on your machine to manage the simulated target. It also allows you to run the test suites for all packages not requiring HW support. You may choose to do this instead of using the build toolchain and Newt tool available in a Docker container.\n\n\nThis page provides guidance for MAC and Linux. See the relevant sections below.\n\n\n\n\nSet up toolchain for Mac\n\n\nInstall Brew\n\n\nIf you have not already installed Homebrew from the \n\nnewt\n tutorials pages\n, install it. \n\n\n\n\nInstall gcc/libc\n\n\nOS X ships with a C compiler called Clang. To build applications for the Mynewt simulator, you will need a different compiler:
gcc.\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\nInstall gdb\n\n\n$ brew install gdb\n...\n...\n==\n Summary\n\ud83c\udf7a /usr/local/Cellar/gdb/7.10.1: XXX files,YYM\n\n\n\n\n\n\n\nNOTE:\n When running a program with gdb, you may need to sign your gdb\nexecutable. \nThis page\n\nshows a recipe for gdb signing. Alternately you can skip this step and\ncontinue without the ability to debug your mynewt application on your PC.*\n\n\n\n\nSet up toolchain for Linux\n\n\nThe below procedure can be used to set up a Debian-based Linux system (e.g.,\nUbuntu). If you are running a different Linux distribution, you will need to\nsubstitute invocations of \napt-get\n in the below steps with the package manager\nthat your distro uses.\n\n\n\n\nInstall gcc/libc that will produce 32-bit executables:\n\n\n$ sudo apt-get install gcc-multilib libc6-i386\n\n\n\n\n\n\n\nInstall gdb\n\n\n$ sudo apt-get install gdb\n\nReadi
ng package lists... Done\nBuilding dependency tree \nReading state information... Done\nSuggested packages:\n gdb-doc gdbserver\nThe following NEW packages will be installed:\n gdb\n...\nProcessing triggers for man-db (2.6.7.1-1ubuntu1) ...\nSetting up gdb (7.7.1-0ubuntu5~14.04.2) ...\n\n\n\n\n\n\n\nAt this point you have installed all the necessary software to build and test code on a simluator running on your Mac or Linux. Proceed to the \nBuild test code on simulator\n section.",
+ "text": "Installing Native Mynewt Tools\n\n\nThis page shows how to install tools for native Mynewt targets (simulated targets on your laptop/computer) without using a Docker container. In other words, it allows you to run Mynewt OS as a native application on your Mac or Linux machine to simulate a target and use the Newt tool running natively on your machine to manage the simulated target. It also allows you to run the test suites for all packages not requiring HW support. You may choose to do this instead of using the build toolchain and Newt tool available in a Docker container.\n\n\nThis page provides guidance for MAC and Linux. See the relevant sections below.\n\n\n\n\nSet up toolchain for Mac\n\n\nInstall Brew\n\n\nIf you have not already installed Homebrew from the \n\nnewt\n tutorials pages\n, install it. \n\n\n\n\nInstall gcc/libc\n\n\nOS X ships with a C compiler called Clang. To build applications for the Mynewt simulator, you will need a different compiler:
gcc.\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\nInstall gdb\n\n\n$ brew install gdb\n...\n...\n==\n Summary\n\ud83c\udf7a /usr/local/Cellar/gdb/7.10.1: XXX files,YYM\n\n\n\n\n\n\n\nNOTE:\n When running a program with gdb, you may need to sign your gdb\nexecutable. \nThis page\n\nshows a recipe for gdb signing. Alternately you can skip this step and\ncontinue without the ability to debug your mynewt application on your PC.*\n\n\n\n\nSet up toolchain for Linux\n\n\nThe below procedure can be used to set up a Debian-based Linux system (e.g.,\nUbuntu). If you are running a different Linux distribution, you will need to\nsubstitute invocations of \napt-get\n in the below steps with the package manager\nthat your distro uses.\n\n\n\n\nInstall gcc/libc that will produce 32-bit executables:\n\n\n$ sudo apt-get install gcc-multilib libc6-i386\n\n\n\n\n\n\n\nInstall gdb\n\n\n$ sudo apt-get install gdb\n\nReadi
ng package lists... Done\nBuilding dependency tree \nReading state information... Done\nSuggested packages:\n gdb-doc gdbserver\nThe following NEW packages will be installed:\n gdb\n...\nProcessing triggers for man-db (2.6.7.1-1ubuntu1) ...\nSetting up gdb (7.7.1-0ubuntu5~14.04.2) ...\n\n\n\n\n\n\n\nAt this point you have installed all the necessary software to build and test code on a simluator running on your Mac or Linux. Proceed to the \nCreate Your First Project\n section.",
"title": "Install Native Tools"
},
{
@@ -182,7 +182,7 @@
},
{
"location": "/os/get_started/native_tools/#install-gdb_1",
- "text": "$ sudo apt-get install gdb\n\nReading package lists... Done\nBuilding dependency tree \nReading state information... Done\nSuggested packages:\n gdb-doc gdbserver\nThe following NEW packages will be installed:\n gdb\n...\nProcessing triggers for man-db (2.6.7.1-1ubuntu1) ...\nSetting up gdb (7.7.1-0ubuntu5~14.04.2) ... At this point you have installed all the necessary software to build and test code on a simluator running on your Mac or Linux. Proceed to the Build test code on simulator section.",
+ "text": "$ sudo apt-get install gdb\n\nReading package lists... Done\nBuilding dependency tree \nReading state information... Done\nSuggested packages:\n gdb-doc gdbserver\nThe following NEW packages will be installed:\n gdb\n...\nProcessing triggers for man-db (2.6.7.1-1ubuntu1) ...\nSetting up gdb (7.7.1-0ubuntu5~14.04.2) ... At this point you have installed all the necessary software to build and test code on a simluator running on your Mac or Linux. Proceed to the Create Your First Project section.",
"title": "Install gdb"
},
{
@@ -292,17 +292,27 @@
},
{
"location": "/os/tutorials/tutorials/",
- "text": "Tutorials\n\n\nIf the introduction to Mynewt has piqued your interest and you want to familiarize yourself with some of its functionality, this series of tutorials is for you. The lessons are aimed at the beginner. \n\n\nHere is a sampler of the tutorials available. New ones are being constantly added and can be seen in the navigation bar on the left.\n\n\n\n\nBlinky on Arduino Zero hardware\n\n\nBlinky on Olimex/STM32F407ZGT6 Cortex-M4 hardware\n\n\nBlinky on STM32F3 discovery kit from ST Micro\n\n\nBlinky on nRF52 Development Kit from Nordic Semiconductor\n \nNote:\n This supports BLE.\n\n\nAdd a unit Test for a Package\n\n\nAdd an air-quality sensor\n \n\n\nAdditional Repositories\n\n\nA task to manage multiple events\n\n\n\n\nSend us an email on the dev@ mailing list if you have comments or suggestions!\n If you haven't joined the mailing list, you will find the links \nhere\n.",
+ "text": "Tutorials\n\n\nIf the introduction to Mynewt has piqued your interest and you want to familiarize yourself with some of its functionality, this series of tutorials is for you. The lessons are aimed at the beginner. \n\n\nThe full list of tutorials can be seen in the navigation bar on the left. New ones are being constantly added and will show up there automatically.\n\n\nPrerequisites:\n\n\n\n\nYou have installed Docker container of Newt tool and toolchains or you have installed them natively on your machine\n\n\nYou have created a new project space (directory structure) and populated it with the core code repository (apache-mynewt-core) or know how to as explained in ../get_started/project_create.\n\n\n\n\nTutorial categories:\n\n\nThe tutorials fall into a few broad categories. Some examples in each category are listed below.\n\n\n\n\n\n\nMaking an LED blink (the \"Hello World\" equivalent in the electronics world)\n\n\n\n\nBlinky on Arduino Zero hardware\n\n\
nBlinky on Olimex/STM32F407ZGT6 Cortex-M4 hardware\n\n\nBlinky on STM32F3 discovery kit from ST Micro\n\n\nBlinky on nRF52 Development Kit from Nordic Semiconductor\n \nNote:\n This supports BLE.\n\n\n\n\n\n\n\n\nNavigating the code and adding functionality \n\n\n\n\nAdding more repositories to your project\n\n\nAdding a unit test for a package\n\n\nAdding task to manage multiple events\n\n\n\n\n\n\n\n\nBluetooth Low Energy\n\n\n\n\nRunning the example BLE app included in the repo\n\n\n\n\n\n\n\n\nUsing NewtMgr \n\n\n\n\nEnabling remote communication with a device running Mynewt OS\n\n\n\n\n\n\n\n\nSend us an email on the dev@ mailing list if you have comments or suggestions!\n If you haven't joined the mailing list, you will find the links \nhere\n.",
"title": "toc"
},
{
"location": "/os/tutorials/tutorials/#tutorials",
- "text": "If the introduction to Mynewt has piqued your interest and you want to familiarize yourself with some of its functionality, this series of tutorials is for you. The lessons are aimed at the beginner. Here is a sampler of the tutorials available. New ones are being constantly added and can be seen in the navigation bar on the left. Blinky on Arduino Zero hardware Blinky on Olimex/STM32F407ZGT6 Cortex-M4 hardware Blinky on STM32F3 discovery kit from ST Micro Blinky on nRF52 Development Kit from Nordic Semiconductor Note: This supports BLE. Add a unit Test for a Package Add an air-quality sensor Additional Repositories A task to manage multiple events Send us an email on the dev@ mailing list if you have comments or suggestions! If you haven't joined the mailing list, you will find the links here .",
+ "text": "If the introduction to Mynewt has piqued your interest and you want to familiarize yourself with some of its functionality, this series of tutorials is for you. The lessons are aimed at the beginner. The full list of tutorials can be seen in the navigation bar on the left. New ones are being constantly added and will show up there automatically.",
"title": "Tutorials"
},
{
+ "location": "/os/tutorials/tutorials/#prerequisites",
+ "text": "You have installed Docker container of Newt tool and toolchains or you have installed them natively on your machine You have created a new project space (directory structure) and populated it with the core code repository (apache-mynewt-core) or know how to as explained in ../get_started/project_create.",
+ "title": "Prerequisites:"
+ },
+ {
+ "location": "/os/tutorials/tutorials/#tutorial-categories",
+ "text": "The tutorials fall into a few broad categories. Some examples in each category are listed below. Making an LED blink (the \"Hello World\" equivalent in the electronics world) Blinky on Arduino Zero hardware Blinky on Olimex/STM32F407ZGT6 Cortex-M4 hardware Blinky on STM32F3 discovery kit from ST Micro Blinky on nRF52 Development Kit from Nordic Semiconductor Note: This supports BLE. Navigating the code and adding functionality Adding more repositories to your project Adding a unit test for a package Adding task to manage multiple events Bluetooth Low Energy Running the example BLE app included in the repo Using NewtMgr Enabling remote communication with a device running Mynewt OS Send us an email on the dev@ mailing list if you have comments or suggestions! If you haven't joined the mailing list, you will find the links here .",
+ "title": "Tutorial categories:"
+ },
+ {
"location": "/os/tutorials/arduino_zero/",
- "text": "Running Mynewt on Arduino Zero\n\n\nThis tutorial describes how to run Mynewt OS on Arduino Zero. Follow these simple steps and your board will be blinking in no time!\n\n\nPrerequisites\n\n\nBefore tackling this tutorial, it's best to read about Mynewt in the \nIntroduction\n section of this documentation.\n\n\nEquipment\n\n\nYou will need the following equipment\n\n\n\n\nAn Arduino Zero board. NOTE: There are many flavors of Arduino. Ensure that \nyou have an Arduino Zero. See below for the verions of Arduino Zero that are\ncompatible with this tutorial\n\n\nA computer that can connect to the Arduino Zero over USB\n\n\nA USB cable (Type A to micro B) that can connect the computer to the Arduino\n\n\nThe Mynewt Release\n\n\n\n\nThis tutorial has been tested on the following two Arduino Zero boards - Zero and Zero-Pro.\n\n\n\n\n\n\nInstall Mynewt and Newt\n\n\n\n\nIf you have not already done so, install Newt as shown in the \nNewt install tutorial\n\n\nIf you
have not already done so, create a project as shown in the Quick Start guide on how to \nCreate Your First Project\n. Skip the testing and building the project steps in that tutorial since you will be defining a target for your Arduino board in this tutorial.\n\n\n\n\n\n\nFetch External Packages\n\n\nMynewt uses source code provided directly from the chip manufacturer for \nlow level operations. Sometimes this code is licensed only for the specific manufacturer of the chipset and cannot live in the Apache Mynewt repository. That happens to be the case for the Arduino Zero board which uses Atmel SAMD21. Runtime's github repository hosts such external third-party packages and the Newt tool can fetch them.\n\n\nTo fetch the package with MCU support for Atmel SAMD21 for Arduino Zero from the Runtime git repository, you need to add \nthe repository to the \nproject.yml\n file in your base project directory.\n\n\nHere is an example \nproject.yml\n file with the Arduino Zero repository\nad
ded. The sections with \nmynewt_arduino_zero\n that need to be added to \nyour project file are highlighted.\n\n\n$ more project.yml \nproject.name: \nmy_project\n\n\nproject.repositories:\n - apache-mynewt-core\n\n - mynewt_arduino_zero\n\n\nrepository.apache-mynewt-core:\n type: github\n vers: 0-latest\n user: apache\n repo: incubator-mynewt-core\n\n\nrepository.mynewt_arduino_zero:\n\n type: github\n\n vers: 0-latest\n\n user: runtimeinc\n\n repo: mynewt_arduino_zero\n\n$ \n\n\n\n\n\n\n\nOnce you've edited your \nproject.yml\n file, the next step is to install the \nproject dependencies, this can be done with the \nnewt install\n command \n(to see more output, provide the \n-v\n verbose option.): \n\n\n$ newt install \napache-mynewt-core\nmynewt_arduino_zero\n$\n\n\n\n\n\n\n\nCreate your bootloader target\n\n\nNext, you need to tell Newt what to build. For the Arduino Zero, we are going to \ngenerate both a bootloader, and an image target.\n\n\nTo g
enerate the bootloader target, you need to specify the following options. The output of the commands (indicating success) have been suppressed for easier readability. \n\n\n$ newt target create arduino_boot \n$ newt target set arduino_boot bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero \n$ newt target set arduino_boot app=@apache-mynewt-core/apps/boot \n$ newt target set arduino_boot build_profile=optimized\n\n\n\n\n\n\n\nIf you have an Arduino Zero Pro, you have to set the following next:\n\n\n$ newt target set arduino_boot features=arduino_zero_pro \n\n\n\n\n\nIf you have an Arduino Zero, you have to set the following instead:\n\n\n$ newt target set arduino_boot features=arduino_zero \n\n\n\n\n\n\n\nThese commands do a few things: \n\n\n\n\nCreate a target named \narduino_boot\n, in order to build the Arduino Zero Bootloader.\n\n\nSet the application for the \narduino_boot\n target to the default Apache Mynewt \n bootloader (\n@apache-mynewt-core/apps/boot\n)\n\n\nSet the board s
upport package for the target to \n \n@mynewt_arduino_zero/hw/bsp/arduino_zero\n. This is a reference to the downloaded \n Arduino Zero support from Github.\n\n\nUse the \"optimized\" build profile for the \narduino_boot\n target. This\n instructs Newt to generate smaller and more efficient code for this target.\n This setting is necessary due to the bootloader's strict size constraints.\n\n\nTells the Board Support Package to enable support for the Arduino Zero Pro or the Arduino Zero. Set it to \narduino_zero\n or \narduino_zero_pro\n depending on the board you have.\n\n\n\n\n\n\nBuild your bootloader\n\n\nOnce you've configured the bootloader target, the next step is to build the bootloader for your Arduino. You can do this by using the \nnewt build\n command:\n\n\n$ newt build arduino_boot \nCompiling asprintf.c\nCompiling atoi.c\nCompiling atol.c\nCompiling atoll.c\nCompiling bsearch.c\nCompiling bzero.c\nCompiling calloc.c\nCompiling fgets.c\nCompiling inline.c\n
\nsnip\n\nApp successfully built: myproject/bin/arduino_boot/apps/boot/boot.elf\n\n\n\n\n\nIf this command finishes successfully, you have successfully built the Arduino \nbootloader, and the next step is to build your application for the Arduino \nboard.\n\n\n\n\nBuild your blinky app\n\n\nTo create and download your application, you create another target, this one pointing to the application you want to download to the Arduino board. In this tutorial, we will use the default application that comes with your project, \napps/blinky\n:\n\n\nNote\n: Remember to set features to \narduino_zero\n if your board is Arduino Zero and not a Pro!\n\n\n$ newt target create arduino_blinky \nTarget targets/arduino_blinky successfully created\n$ newt target set arduino_blinky app=apps/blinky \nTarget targets/arduino_blinky successfully set target.app to apps/blinky\n$ newt target set arduino_blinky bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero\nTarget targets/arduino_blinky successfully set targe
t.bsp to @mynewt_arduino_zero/hw/bsp/arduino_zero\n$ newt target set arduino_blinky build_profile=debug \nTarget targets/arduino_blinky successfully set target.build_profile to debug\n\n$ newt target set arduino_blinky features=arduino_zero_pro \n\nTarget targets/arduino_blinky successfully set pkg.features to arduino_zero_pro\n$ \n\n\n\n\n\n\n\nYou can now build the target, with \nnewt build\n: \n\n\n$ newt build arduino_blinky \nCompiling main.c\nArchiving blinky.a\nCompiling cons_fmt.c\nCompiling cons_tty.c\nArchiving full.a\nCompiling case.c\nCompiling suite.c\nCompiling testutil.c\nArchiving testutil.a\n\nsnip\n\nApp successfully built: myproject/bin/arduino_blinky/apps/blinky/blinky.elf\n\n\n\n\n\n Congratulations! \n You have successfully built your application. Now it's time to load both the bootloader and application onto the target.\n\n\n\n\nConnect the Target\n\n\nConnect your computer to the Arduino Zero (from now on we'll call this the \ntarget) with the Micro-USB cable
through the Programming Port as shown below. \nMynewt will download and debug the target through this port. You should see a \nlittle green LED come on. That means the board has power.\n\n\nNo external debugger is required. The Arduino Zero comes with an internal\ndebugger that can be accessed by Mynewt.\n\n\nA image below shows the Arduino Zero Programming Port.\n\n\n\n\n\n\n\n\nDownload the Bootloader\n\n\nExecute the command to download the bootloader. \n\n\n \n$\n \nnewt\n \nload\n \narduino_boot\n\n\n\n\n\n\nIf the newt tool finishes without error, that means the bootloader has been \nsuccessfully loaded onto the target.\n\n\n\n\n Reminder if you are using Docker: \n When working with actual hardware, remember that each board has an ID. If you swap boards and do not refresh the USB Device Filter on the VirtualBox UI, the ID might be stale and the Docker instance may not be able to see the board correctly. For example, you may see an error message like \nError: unable to fi
nd CMSIS-DAP device\n when you try to load or run an image on the board. In that case, you need to click on the USB link in VirtualBox UI, remove the existing USB Device Filter (e.g. \"Atmel Corp. EDBG CMSIS-DAP[0101]\") by clicking on the \"Removes selected USB filter\" button, and add a new filter by clicking on the \"Adds new USB filter\" button.\n\n\n\n\nRun the Image\n\n\nNow that the bootloader is downloaded to the target, the next step is to load \nyour image onto the Arduino Zero. The easiest way to do this, is to use the \n\nnewt run\n command. \nnewt run\n will automatically rebuild your program\n(if necessary), create an image, and load it onto the target device.\n\n\nHere, we will load our \narduino_blinky\n target onto the device, and we \nshould see it run:\n\n\n$ newt run arduino_blinky 0.0.0 \nDebugging myproject/bin/arduino_blinky/apps/blinky/blinky.elf\nOpen On-Chip Debugger 0.9.0 (2015-09-23-21:46)\nLicensed under GNU GPL v2\nFor bug reports, read\n http://op
enocd.org/doc/doxygen/bugs.html\nInfo : only one transport option; autoselect \nswd\n\nadapter speed: 500 kHz\nadapter_nsrst_delay: 100\ncortex_m reset_config sysresetreq\nInfo : CMSIS-DAP: SWD Supported\nInfo : CMSIS-DAP: JTAG Supported\nInfo : CMSIS-DAP: Interface Initialised (SWD)\nInfo : CMSIS-DAP: FW Version = 01.1F.0118\nInfo : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1\nInfo : CMSIS-DAP: Interface ready\nInfo : clock speed 500 kHz\nInfo : SWD IDCODE 0x0bc11477\nInfo : at91samd21g18.cpu: hardware has 4 breakpoints, 2 watchpoints\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 \nshow copying\n\nand \nshow warranty\n for details.\nThis GDB was configured as \n--host=x86_64-apple-d
arwin10 --target=arm-none-eabi\n.\nType \nshow configuration\n 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 \nhelp\n.\nType \napropos word\n to search for commands related to \nword\n...\nReading symbols from myproject/bin/arduino_blinky/apps/blinky/blinky.elf...done.\ntarget state: halted\ntarget halted due to debug-request, current mode: Thread \nxPSR: 0x21000000 pc: 0x0000030e msp: 0x20008000\nInfo : accepting \ngdb\n connection on tcp/3333\nInfo : SAMD MCU: SAMD21G18A (256KB Flash, 32KB RAM)\n0x0000030e in ?? ()\n(gdb) r\nThe \nremote\n target does not support \nrun\n. Try \nhelp target\n or \ncontinue\n.\n(gdb) c\nContinuing.\n\n\n\n\n\n\n\nNOTE:\n The 0.0.0 specified after the target name to \nnewt run\n is the version \nof the image to load. If you are not providing remot
e upgrade, and are just \ndeveloping locally, you can provide 0.0.0 for every image version.\n\n\nIf you want the image to run without the debugger connected, simply quit the \ndebugger and restart the board. The image you programmed will come and run on the Arduino on next boot! \n\n\n\n\nWatch the LED blink\n\n\nCongratulations! You have created a Mynewt operating system running on the \nArduino Zero. The LED right next to the power LED should be blinking. It is toggled by one task running on the Mynewt OS.",
+ "text": "Running Mynewt on Arduino Zero\n\n\nThis tutorial describes how to run Mynewt OS on Arduino Zero. Follow these simple steps and your board will be blinking in no time!\n\n\nPrerequisites\n\n\nBefore tackling this tutorial, it's best to read about Mynewt in the \nIntroduction\n section of this documentation.\n\n\nEquipment\n\n\nYou will need the following equipment\n\n\n\n\nAn Arduino Zero board. NOTE: There are many flavors of Arduino. Ensure that \nyou have an Arduino Zero. See below for the versions of Arduino Zero that are\ncompatible with this tutorial\n\n\nA computer that can connect to the Arduino Zero over USB\n\n\nA USB cable (Type A to micro B) that can connect the computer to the Arduino\n\n\nThe Mynewt Release\n\n\n\n\nThis tutorial has been tested on the following three Arduino Zero boards - Zero, M0 Pro, and Zero-Pro.\n\n\n\n\n\n\n\n\nMynewt has not been tested on Arduino M0 which has no internal debugger support.\n\n\nInstall Mynewt and Newt\n\n\n
\n\nIf you have not already done so, install Newt as shown in the \nNewt install tutorial\n\n\nIf you have not already done so, create a project as shown in the Quick Start guide on how to \nCreate Your First Project\n. Skip the testing and building the project steps in that tutorial since you will be defining a target for your Arduino board in this tutorial.\n\n\n\n\n\n\nFetch External Packages\n\n\nMynewt uses source code provided directly from the chip manufacturer for \nlow level operations. Sometimes this code is licensed only for the specific manufacturer of the chipset and cannot live in the Apache Mynewt repository. That happens to be the case for the Arduino Zero board which uses Atmel SAMD21. Runtime's github repository hosts such external third-party packages and the Newt tool can fetch them.\n\n\nTo fetch the package with MCU support for Atmel SAMD21 for Arduino Zero from the Runtime git repository, you need to add \nthe repository to the \nproject.yml\n file in your bas
e project directory.\n\n\nHere is an example \nproject.yml\n file with the Arduino Zero repository\nadded. The sections with \nmynewt_arduino_zero\n that need to be added to \nyour project file are highlighted.\n\n\n$ more project.yml \nproject.name: \nmy_project\n\n\nproject.repositories:\n - apache-mynewt-core\n\n - mynewt_arduino_zero\n\n\nrepository.apache-mynewt-core:\n type: github\n vers: 0-latest\n user: apache\n repo: incubator-mynewt-core\n\n\nrepository.mynewt_arduino_zero:\n\n type: github\n\n vers: 0-latest\n\n user: runtimeinc\n\n repo: mynewt_arduino_zero\n\n$ \n\n\n\n\n\n\n\nOnce you've edited your \nproject.yml\n file, the next step is to install the \nproject dependencies, this can be done with the \nnewt install\n command \n(to see more output, provide the \n-v\n verbose option.): \n\n\n$ newt install \napache-mynewt-core\nmynewt_arduino_zero\n$\n\n\n\n\n\n\n\nCreate your bootloader target\n\n\nNext, you need to tell Newt what to buil
d. For the Arduino Zero, we are going to \ngenerate both a bootloader, and an image target.\n\n\nTo generate the bootloader target, you need to specify the following options. The output of the commands (indicating success) have been suppressed for easier readability. \n\n\n$ newt target create arduino_boot \n$ newt target set arduino_boot bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero \n$ newt target set arduino_boot app=@apache-mynewt-core/apps/boot \n$ newt target set arduino_boot build_profile=optimized\n\n\n\n\n\n\n\nIf you have an Arduino Zero Pro or M0 Pro, you have to set the following next:\n\n\n$ newt target set arduino_boot features=arduino_zero_pro \n\n\n\n\n\nIf you have an Arduino Zero, you have to set the following instead:\n\n\n$ newt target set arduino_boot features=arduino_zero \n\n\n\n\n\n\n\nThese commands do a few things: \n\n\n\n\nCreate a target named \narduino_boot\n, in order to build the Arduino Zero Bootloader.\n\n\nSet the application for the \narduino_boot
\n target to the default Apache Mynewt \n bootloader (\n@apache-mynewt-core/apps/boot\n)\n\n\nSet the board support package for the target to \n \n@mynewt_arduino_zero/hw/bsp/arduino_zero\n. This is a reference to the downloaded \n Arduino Zero support from Github.\n\n\nUse the \"optimized\" build profile for the \narduino_boot\n target. This\n instructs Newt to generate smaller and more efficient code for this target.\n This setting is necessary due to the bootloader's strict size constraints.\n\n\nTells the Board Support Package to enable support for the Arduino Zero Pro or the Arduino Zero. Set it to \narduino_zero\n or \narduino_zero_pro\n depending on the board you have.\n\n\n\n\n\n\nBuild your bootloader\n\n\nOnce you've configured the bootloader target, the next step is to build the bootloader for your Arduino. You can do this by using the \nnewt build\n command:\n\n\n$ newt build arduino_boot \nCompiling asprintf.c\nCompiling atoi.c\nCompiling atol.c\nCompil
ing atoll.c\nCompiling bsearch.c\nCompiling bzero.c\nCompiling calloc.c\nCompiling fgets.c\nCompiling inline.c\n\nsnip\n\nApp successfully built: myproject/bin/arduino_boot/apps/boot/boot.elf\n\n\n\n\n\nIf this command finishes successfully, you have successfully built the Arduino \nbootloader, and the next step is to build your application for the Arduino \nboard.\n\n\n\n\nBuild your blinky app\n\n\nTo create and download your application, you create another target, this one pointing to the application you want to download to the Arduino board. In this tutorial, we will use the default application that comes with your project, \napps/blinky\n:\n\n\nNote\n: Remember to set features to \narduino_zero\n if your board is Arduino Zero and not a Pro!\n\n\n$ newt target create arduino_blinky \nTarget targets/arduino_blinky successfully created\n$ newt target set arduino_blinky app=apps/blinky \nTarget targets/arduino_blinky successfully set target.app to apps/blinky\n$ newt target set a
rduino_blinky bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero\nTarget targets/arduino_blinky successfully set target.bsp to @mynewt_arduino_zero/hw/bsp/arduino_zero\n$ newt target set arduino_blinky build_profile=debug \nTarget targets/arduino_blinky successfully set target.build_profile to debug\n\n$ newt target set arduino_blinky features=arduino_zero_pro \n\nTarget targets/arduino_blinky successfully set pkg.features to arduino_zero_pro\n$ \n\n\n\n\n\n\n\nYou can now build the target, with \nnewt build\n: \n\n\n$ newt build arduino_blinky \nCompiling main.c\nArchiving blinky.a\nCompiling cons_fmt.c\nCompiling cons_tty.c\nArchiving full.a\nCompiling case.c\nCompiling suite.c\nCompiling testutil.c\nArchiving testutil.a\n\nsnip\n\nApp successfully built: myproject/bin/arduino_blinky/apps/blinky/blinky.elf\n\n\n\n\n\n Congratulations! \n You have successfully built your application. Now it's time to load both the bootloader and application onto the target.\n\n\n\n\nConnect the Target\n\
n\nConnect your computer to the Arduino Zero (from now on we'll call this the \ntarget) with the Micro-USB cable through the Programming Port as shown below. \nMynewt will download and debug the target through this port. You should see a \nlittle green LED come on. That means the board has power.\n\n\nNo external debugger is required. The Arduino Zero comes with an internal\ndebugger that can be accessed by Mynewt.\n\n\nA image below shows the Arduino Zero Programming Port.\n\n\n\n\n\n\n\n\nDownload the Bootloader\n\n\nExecute the command to download the bootloader. \n\n\n \n$\n \nnewt\n \nload\n \narduino_boot\n\n\n\n\n\n\nIf the newt tool finishes without error, that means the bootloader has been \nsuccessfully loaded onto the target.\n\n\n\n\n Reminder if you are using Docker: \n When working with actual hardware, remember that each board has an ID. If you swap boards and do not refresh the USB Device Filter on the VirtualBox UI, the ID might be stale and the Docker instance
may not be able to see the board correctly. For example, you may see an error message like \nError: unable to find CMSIS-DAP device\n when you try to load or run an image on the board. In that case, you need to click on the USB link in VirtualBox UI, remove the existing USB Device Filter (e.g. \"Atmel Corp. EDBG CMSIS-DAP[0101]\") by clicking on the \"Removes selected USB filter\" button, and add a new filter by clicking on the \"Adds new USB filter\" button.\n\n\n\n\nRun the Image\n\n\nNow that the bootloader is downloaded to the target, the next step is to load \nyour image onto the Arduino Zero. The easiest way to do this, is to use the \n\nnewt run\n command. \nnewt run\n will automatically rebuild your program\n(if necessary), create an image, and load it onto the target device.\n\n\nHere, we will load our \narduino_blinky\n target onto the device, and we \nshould see it run:\n\n\n$ newt run arduino_blinky 0.0.0 \nDebugging myproject/bin/arduino_blinky/apps/blinky/blinky.elf\
nOpen On-Chip Debugger 0.9.0 (2015-09-23-21:46)\nLicensed under GNU GPL v2\nFor bug reports, read\n http://openocd.org/doc/doxygen/bugs.html\nInfo : only one transport option; autoselect \nswd\n\nadapter speed: 500 kHz\nadapter_nsrst_delay: 100\ncortex_m reset_config sysresetreq\nInfo : CMSIS-DAP: SWD Supported\nInfo : CMSIS-DAP: JTAG Supported\nInfo : CMSIS-DAP: Interface Initialised (SWD)\nInfo : CMSIS-DAP: FW Version = 01.1F.0118\nInfo : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1\nInfo : CMSIS-DAP: Interface ready\nInfo : clock speed 500 kHz\nInfo : SWD IDCODE 0x0bc11477\nInfo : at91samd21g18.cpu: hardware has 4 breakpoints, 2 watchpoints\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 \nshow copying\n\nand \nshow warranty\n for details.\nThis GDB was configured as \n--host=x86_64-apple-darwin10 --target=arm-none-eabi\n.\nType \nshow configuration\n 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 \nhelp\n.\nType \napropos word\n to search for commands related to \nword\n...\nReading symbols from myproject/bin/arduino_blinky/apps/blinky/blinky.elf...done.\ntarget state: halted\ntarget halted due to debug-request, current mode: Thread \nxPSR: 0x21000000 pc: 0x0000030e msp: 0x20008000\nInfo : accepting \ngdb\n connection on tcp/3333\nInfo : SAMD MCU: SAMD21G18A (256KB Flash, 32KB RAM)\n0x0000030e in ?? ()\n(gdb) r\nThe \nremote\n target does not support \nrun\n. Try \nhelp target\n or \ncontinue\n.\n(gdb) c\nContinuing.\n\n\n\n\n\n\n\nNOTE:\n The 0.0.0 specif
ied after the target name to \nnewt run\n is the version \nof the image to load. If you are not providing remote upgrade, and are just \ndeveloping locally, you can provide 0.0.0 for every image version.\n\n\nIf you want the image to run without the debugger connected, simply quit the \ndebugger and restart the board. The image you programmed will come and run on the Arduino on next boot! \n\n\n\n\nWatch the LED blink\n\n\nCongratulations! You have created a Mynewt operating system running on the \nArduino Zero. The LED right next to the power LED should be blinking. It is toggled by one task running on the Mynewt OS.",
"title": "Blinky on Arduino Zero"
},
{
@@ -317,7 +327,7 @@
},
{
"location": "/os/tutorials/arduino_zero/#equipment",
- "text": "You will need the following equipment An Arduino Zero board. NOTE: There are many flavors of Arduino. Ensure that \nyou have an Arduino Zero. See below for the verions of Arduino Zero that are\ncompatible with this tutorial A computer that can connect to the Arduino Zero over USB A USB cable (Type A to micro B) that can connect the computer to the Arduino The Mynewt Release This tutorial has been tested on the following two Arduino Zero boards - Zero and Zero-Pro.",
+ "text": "You will need the following equipment An Arduino Zero board. NOTE: There are many flavors of Arduino. Ensure that \nyou have an Arduino Zero. See below for the versions of Arduino Zero that are\ncompatible with this tutorial A computer that can connect to the Arduino Zero over USB A USB cable (Type A to micro B) that can connect the computer to the Arduino The Mynewt Release This tutorial has been tested on the following three Arduino Zero boards - Zero, M0 Pro, and Zero-Pro. Mynewt has not been tested on Arduino M0 which has no internal debugger support.",
"title": "Equipment"
},
{
@@ -332,7 +342,7 @@
},
{
"location": "/os/tutorials/arduino_zero/#create-your-bootloader-target",
- "text": "Next, you need to tell Newt what to build. For the Arduino Zero, we are going to \ngenerate both a bootloader, and an image target. To generate the bootloader target, you need to specify the following options. The output of the commands (indicating success) have been suppressed for easier readability. $ newt target create arduino_boot \n$ newt target set arduino_boot bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero \n$ newt target set arduino_boot app=@apache-mynewt-core/apps/boot \n$ newt target set arduino_boot build_profile=optimized If you have an Arduino Zero Pro, you have to set the following next: $ newt target set arduino_boot features=arduino_zero_pro If you have an Arduino Zero, you have to set the following instead: $ newt target set arduino_boot features=arduino_zero These commands do a few things: Create a target named arduino_boot , in order to build the Arduino Zero Bootloader. Set the application for the arduino_boot target to the
default Apache Mynewt \n bootloader ( @apache-mynewt-core/apps/boot ) Set the board support package for the target to \n @mynewt_arduino_zero/hw/bsp/arduino_zero . This is a reference to the downloaded \n Arduino Zero support from Github. Use the \"optimized\" build profile for the arduino_boot target. This\n instructs Newt to generate smaller and more efficient code for this target.\n This setting is necessary due to the bootloader's strict size constraints. Tells the Board Support Package to enable support for the Arduino Zero Pro or the Arduino Zero. Set it to arduino_zero or arduino_zero_pro depending on the board you have.",
+ "text": "Next, you need to tell Newt what to build. For the Arduino Zero, we are going to \ngenerate both a bootloader, and an image target. To generate the bootloader target, you need to specify the following options. The output of the commands (indicating success) have been suppressed for easier readability. $ newt target create arduino_boot \n$ newt target set arduino_boot bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero \n$ newt target set arduino_boot app=@apache-mynewt-core/apps/boot \n$ newt target set arduino_boot build_profile=optimized If you have an Arduino Zero Pro or M0 Pro, you have to set the following next: $ newt target set arduino_boot features=arduino_zero_pro If you have an Arduino Zero, you have to set the following instead: $ newt target set arduino_boot features=arduino_zero These commands do a few things: Create a target named arduino_boot , in order to build the Arduino Zero Bootloader. Set the application for the arduino_boot tar
get to the default Apache Mynewt \n bootloader ( @apache-mynewt-core/apps/boot ) Set the board support package for the target to \n @mynewt_arduino_zero/hw/bsp/arduino_zero . This is a reference to the downloaded \n Arduino Zero support from Github. Use the \"optimized\" build profile for the arduino_boot target. This\n instructs Newt to generate smaller and more efficient code for this target.\n This setting is necessary due to the bootloader's strict size constraints. Tells the Board Support Package to enable support for the Arduino Zero Pro or the Arduino Zero. Set it to arduino_zero or arduino_zero_pro depending on the board you have.",
"title": "Create your bootloader target"
},
{
@@ -3572,7 +3582,7 @@
},
{
"location": "/os/core_os/porting/port_bsp/",
- "text": "Create a BSP for your Target\n\n\nIntroduction\n\n\nIf you are using a board or system not currently supported by Mynewt, you will need to create a BSP for the new target. If another similar BSP exists it is recommended to copy that BSP as a starting point. For example, if another BSP exists using the same MCU, start with a copy of that BSP.\n\n\nEither way, this document describes the steps necessary to create a new BSP from scratch. \n\n\nKeep your Reference Documents handy\n\n\nTo build a proper BSP, you will typically need the following:\n\n\n\n\nThe datasheet for the MCU you have chosen\n\n\nThe schematic of your board\n\n\nThe information on the CPU core within your MCU if it is not included in your MCU documentation\n\n\nThis Mynewt documentation\n\n\n\n\nName your BSP\n\n\nSelect a name for your BSP. For the remainder of this document, we'll assume the bsp is named \nmyboard\n. In general its best to select a name that describes the board/system you
are creating.\n\n\nCreate a BSP directory\n\n\nCreate a directory \nhw/bsp/myboard\n using the name chosen above. Within this BSP directory, create the following subdirectories:\n\n\nSelect a name for your BSP. For the remainder of this document, \nwell assume the bsp is named \nmyboard\n. In general its best to select a \nname that describes the board/system you are creating.\n\n\n\n\ninclude\n\n\ninclude/bsp\n\n\nsrc\n\n\n\n\nCreate a Target using Mynewt\n\n\nCreate a newt target for your test project for the BSP. To learn how to create a target, see this \nhowto\n \nTutorial\n. Once you are familiar with creating targets, move on below to create a target to use to test your BSP.\n\n\nIt is recommended that you use a simple \nproject\n like \nblinky\n to minimize time to get a working Mynewt system. For this document, we will assume the \ntarget\n is called \nmyboard_blinky\n and uses project \nblinky\n. \n\n\nSet the \nbsp\n of the project to \n/hw/bsp/myboard\n. While creati
ng your target, you will need to specify your \narch\nand \ncompiler\n. If your platform requires an architecture or compiler that are not defined in Mynewt, you will need to add them first. To add a CPU architecture see \nCPU Porting\n.\n\n\nWhen you are complete, your \ntarget\n may look similar to this.\n\n\n \n$newt\n \ntarget\n \nshow\n \n \nmyboard_blinky\n\n \narch=cortex_m0\n\n \nbsp=hw/bsp/myboard\n\n \ncompiler=arm-none-eabi-m0\n\n \ncompiler_def=debug\n\n \nname=myboard_blinky\n\n \nproject=blinky\n\n\n\n\n\n\nCreate Required Files For Compilation\n\n\nCreate the following files within the BSP directory tree. For now, they can be empty files. We will fill them out one at a time.\n\n\n\n\n\n\n\n\nFile Path Name\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\nLICENSE\n\n\nA File to present the source license for your BSP\n\n\n\n\n\n\nREADME.md\n\n\nA markdown file to write documentation for your BSP\n\n\n\n\
n\n\npkg.yml\n\n\nA package file to describe your BSP contents\n\n\n\n\n\n\ninclude/bsp/bsp.h\n\n\nA header file to include definitions required by system from the BSP\n\n\n\n\n\n\nsrc/os_bsp.c\n\n\nA C source file to provide functions required by the OS from your BSP\n\n\n\n\n\n\nsrc/sbrk.c\n\n\nA C source file to memory from your heap to the OS\n\n\n\n\n\n\nsrc/libc_stubs.c\n\n\nA C source file to provide stubs/methods required by libc\n\n\n\n\n\n\nmyboard.ld\n\n\nA linker script to provide the memory map for your linked code\n\n\n\n\n\n\n\n\nOptionally, create these files as necessary to provide all functionality from Mynewt.\n\n\n\n\n\n\n\n\nFile Path Name\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\nmyboard_boot.ld\n\n\nA linker script to provide the memory map for your bootloader\n\n\n\n\n\n\nmyboard_download.sh\n\n\nA bash script to download code into your platform\n\n\n\n\n\n\nmyboard_debug.sh\n\n\nA bash script to intiate a gdb session with your platform\n\n\n\n\n\n\nsrc/hal_bsp.c
\n\n\nA C source file to provide functions required by the HAL from your BSP\n\n\n\n\n\n\n\n\nFill Out your Package File\n\n\nEdit the package file to describe your BSP. \n\n\nThe package file must contain:\n\n\n \npkg\n.\nname\n: \nhw/bsp/myboard\n\n \npkg\n.\nlinkerscript\n: \nmyboard.ld\n\n\n\n\n\n\n\n\n\n\n\n\nAttribute\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\npkg.name\n\n\nThe name of your bsp package\n\n\n\n\n\n\npkg.linkerscript\n\n\nThe linker script that controls the memory placement of the compiled code sections from the Mynewt OS and your applications.\n\n\n\n\n\n\n\n\nThe linker script is a key component of the BSP and specifies where each section of code and data are stored within your CPU which can vary with the BSP depending on your chosen memory layout. For a tutorial on writing linker scripts, see \nCreate or Copy Linker Script(s)\n.\n\n\nThe package file typically contains:\n\n\n \npkg\n.\nlinkerscript\n.\nbootloader\n.\nOVERWRITE\n: \nmyboard_boot.ld\n\n
\npkg\n.\ndownloadscript\n: \nmyboard_download.sh\n\n \npkg\n.\ndebugscript\n: \nmyboard_debug.sh\n\n \npkg\n.\ndeps\n: \n \n-\n \nhw/mcu/mymcu/variant\n\n\n\n\n\n\nwhere \nmymcu/variant\n should be replaced with the specific MCU and variant used in your design.\n\n\nThe following table describes additional attributes relevant to the BSP \npkg.yml\n file.\n\n\n\n\n\n\n\n\nAttribute\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\npkg.linkerscript.bootloader.OVERWRITE\n\n\nA special linker for creating a bootloader for Mynewt\n\n\n\n\n\n\npkg.downloadscript\n\n\nA script that can download a flash image into your target platform\n\n\n\n\n\n\npkg.debugscript\n\n\nA script that can run the GDB debugger on your board\n\n\n\n\n\n\npkg.deps\n\n\nAny dependencies on your BSP\n\n\n\n\n\n\n\n\nThe BSP will invariably depend upon an MCU ( in this sample it's \nhw/mcu/mymcu/variant\n) since the Mynewt OS runs on an MCU within your target. If your MCU is not supported by Mynewt, see \nMCU Portin
g\n for details on how to create an MCU in Mynewt.\n\n\nThe package file may also contain:\n\n\n \npkg\n.\ncflags\n: \n-D__MY_SPECIAL_BSP_OPTIONS_\n\n \npkg\n.\ndeps\n:\n \n-\n \nlibs/cmsis-core\n\n\n\n\n\n\n\n\n\n\n\n\nAttribute\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\npkg.cflags\n\n\nAny specific compiler flags for your bsp\n\n\n\n\n\n\npkg.deps\n\n\nAny other libraries that may be required. Some architectures (like ARM) have special libraries to make BSP creation easier.\n\n\n\n\n\n\n\n\nCreate or Copy Linker Script\n\n\nIt's probably best to start with a linker script from another BSP using the same MCU. If this is not available, consult your MCU documentation and library samples to find a linker script to start with.\n\n\nTypically, a linker script has to specify the following sections for code:\n\n\n\n\n.text -- the location and alignment of the memory section to store your code\n\n\n.data -- the location and alignment of the memory section to store initialized data\n\
n\n.bss -- the location and alignment of the memory section to store uninitialized data\n\n\n.heap -- the location and alignment of the memory section to provide system memory\n\n\n\n\nThe linker script should specify the location and size of the different memory regions in your BSP and map the code sections described above into these regions. \n\n\nThe linker script should also include an ENTRY point. This is used by the debugger to know where to start the program counter when the target is debugged.\n\n\nThere may be additional requirements from the MCU or OS that you may find easiest to place in the linker script. Some specific variables that the OS and MCU depends on are :\n\n\n\n\n\n\n\n\nVariable\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\n__bss_start__\n\n\na variable located at the start of the BSS section\n\n\n\n\n\n\n__bss_end__\n\n\na variable located at the end of the BSS section\n\n\n\n\n\n\n__isr_vector\n\n\nSome CPUs map their interrupt vectors. They may need to be specifi
ed in the linker\n\n\n\n\n\n\n_user_heap_start\n\n\nthe start of the heap for unallocated memory\n\n\n\n\n\n\n_user_heap_end\n\n\nthe end of the heap for unallocated memory\n\n\n\n\n\n\n\n\nCreate an alternate linker script for the bootloader since it is typically linked to use different addresses to boot the main image. \n\n\nAdd Functions and Defines\n\n\nAt this point, it will be possible to run the \nnewt\n tool to build your target. \n\n\nYou may run into complaints from the linker script that a few Mynewt specific functions are missing. We will describe these below.\n\n\n\n\n\n\n\n\nFunction\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\nos_bsp_init()\n\n\ncode to initialize the bsp\n\n\n\n\n\n\nos_bsp_systick_init()\n\n\ncode to setup the system tick for the OS\n\n\n\n\n\n\n\n\nThere are also several libc definitions that can be stubbed in your first BSP. Examples are \n_write\n, \n_read\n, etc. that can be found in \nlibc_stubs.c\n. But you \nmust\n implement the following function
to provide memory to the OS and system.\n\n\n\n\n\n\n\n\nFunction\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\n_sbrk\n\n\nReturns memory from heap (used by malloc)\n\n\n\n\n\n\n\n\n\n\nImplement \n_sbrk()\n\n\n\n\nsbrk()\n is required by libc to get memory from the heap for things like malloc. Although not strongly BSP dependent, this is currently in the BSP to allow flexibility in providing system memory. See other BSPs for providing \nsbrk\n functionality.\n\n\n\n\nImplement \nos_bsp_init()\n\n\n\n\nos_bsp_init\n should initialize anything required by the OS by the BSP. Typically this is a very small set. \n\n\nNOTE: Currently we are making calls to \n_sbrk()\n and \nclose(0)\n from \nos_bsp_init\n to get around a linker issue where some of libc is not getting included. Please include this in your \nos_bsp_init\n.\n\n\n \n/*\n\n\n * XXX these references are here to keep the functions in for libc to find.\n\n\n */\n\n \n_sbrk\n(\n0\n);\n \n_close\n(\n0\n);\n\n\n\n\n\
n\n\nOther Unresolved Defines or Functions\n\n\n\n\nThere may be other unresolved defines or functions that are required by the specific MCU within your BSP. Below lists some sample defines.\n\n\n\n\n\n\n\n\nUndefined Variable\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\nCONSOLE_UART_PORT\n\n\nWhich communications port on your target runs the console\n\n\n\n\n\n\nLED_BLINK_PIN\n\n\nwhich pin on your target runs the blinky LED\n\n\n\n\n\n\n\n\nThe set of missing functionality depends upon the libraries and dependencies you have included in the project. That's why its best to keep your first project pretty simple then add incrementally. For example, if you include Newtron file system, you will need to define a file system map for your BSP.\n\n\nMissing functionality may take the form of \n#define\n items required to compile, or they may take the form of missing functions. \n\n\n\n\ncmsis_nvic.h\n\n\n\n\nIf you are using an ARM cortex architecture, you need to define the number of interrup
ts supported by your system. If you are not using ARM Cortex architecture this may not be required (but something else might be).\n\n\nAdd Debug Script\n\n\nThe debug script in the bsp directory allows the newt tool to automatically connect to the debugger, and create a debug session with the target. This requires knowledge of your target debug interface. Most of the Mynewt BSP targets use \nopenocd\n to perform debugging. This script typically creates an openocd connection to the target and then connects a gdb instance to this openocd connection. There are several examples in existing BSPs to follow.\n\n\nThe script must take a single argument which is the name of the image file minus the '.elf' suffix.\n\n\nThe BSP is complete without this file, but newt will be unable to establish a debug session without it.\n\n\nAdd Download Script\n\n\nSimilar to the debug script, the download script is a hook for newt to download the image to the target system. The download script also ty
pically uses openocd interface to erase flash, and progam the code into the device.\n\n\nNOTE: The download script needs to command openocd to program the image into the appropriate location, which is typically called \nFLASH_OFFSET\n in these scripts. This location has to match the linker script location of the image link address. For example, if your linker links the code to be run at \n0xC000\n your download script should download the image to the same\naddress in the correct flash. \n\n\nAdd License and Documentation\n\n\nThe \nLICENSE\n file is an ASCII text file that describes the source license for this\npackage.\n\n\nThe \nREADME.md\n is a \nmarkdown\n\n file that contains any documentation you \nwant to provide for the BSP.",
+ "text": "Create a BSP for your Target\n\n\nIntroduction\n\n\nIf you are using a board or system not currently supported by Mynewt, you will need to create a BSP for the new target. If another similar BSP exists it is recommended to copy that BSP as a starting point. For example, if another BSP exists using the same MCU, start with a copy of that BSP.\n\n\nEither way, this document describes the steps necessary to create a new BSP from scratch. \n\n\nKeep your Reference Documents handy\n\n\nTo build a proper BSP, you will typically need the following:\n\n\n\n\nThe datasheet for the MCU you have chosen\n\n\nThe schematic of your board\n\n\nThe information on the CPU core within your MCU if it is not included in your MCU documentation\n\n\nThis Mynewt documentation\n\n\n\n\nName your BSP\n\n\nSelect a name for your BSP. For the remainder of this document, we'll assume the bsp is named \nmyboard\n. In general its best to select a name that describes the board/system you
are creating.\n\n\nCreate a BSP directory\n\n\nCreate a directory \nhw/bsp/myboard\n using the name chosen above. Within this BSP directory, create the following subdirectories:\n\n\nSelect a name for your BSP. For the remainder of this document, \nwell assume the bsp is named \nmyboard\n. In general its best to select a \nname that describes the board/system you are creating.\n\n\n\n\ninclude\n\n\ninclude/bsp\n\n\nsrc\n\n\n\n\nCreate a Target using Mynewt\n\n\nCreate a newt target for your test project for the BSP. To learn how to create a target, see this \nhowto\n \nTutorial\n. Once you are familiar with creating targets, move on below to create a target to use to test your BSP.\n\n\nIt is recommended that you use a simple \nproject\n like \nblinky\n to minimize time to get a working Mynewt system. For this document, we will assume the \ntarget\n is called \nmyboard_blinky\n and uses project \nblinky\n. \n\n\nSet the \nbsp\n of the project to \n/hw/bsp/myboard\n. While creati
ng your target, you will need to specify your \narch\nand \ncompiler\n. If your platform requires an architecture or compiler that are not defined in Mynewt, you will need to add them first. To add a CPU architecture see \nCPU Porting\n.\n\n\nWhen you are complete, your \ntarget\n may look similar to this.\n\n\n \n$newt\n \ntarget\n \nshow\n \n \nmyboard_blinky\n\n \narch=cortex_m0\n\n \nbsp=hw/bsp/myboard\n\n \ncompiler=arm-none-eabi-m0\n\n \ncompiler_def=debug\n\n \nname=myboard_blinky\n\n \nproject=blinky\n\n\n\n\n\n\nCreate Required Files For Compilation\n\n\nCreate the following files within the BSP directory tree. For now, they can be empty files. We will fill them out one at a time.\n\n\n\n\n\n\n\n\nFile Path Name\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\nLICENSE\n\n\nA File to present the source license for your BSP\n\n\n\n\n\n\nREADME.md\n\n\nA markdown file to write documentation for your BSP\n\n\n\n\
n\n\npkg.yml\n\n\nA package file to describe your BSP contents\n\n\n\n\n\n\ninclude/bsp/bsp.h\n\n\nA header file to include definitions required by system from the BSP\n\n\n\n\n\n\ninclude/bsp/bsp_sysid.h\n\n\nA header file to enumerate the devices in your BSP\n\n\n\n\n\n\nsrc/os_bsp.c\n\n\nA C source file to provide functions required by the OS from your BSP\n\n\n\n\n\n\nsrc/sbrk.c\n\n\nA C source file to memory from your heap to the OS\n\n\n\n\n\n\nsrc/libc_stubs.c\n\n\nA C source file to provide stubs/methods required by libc\n\n\n\n\n\n\nmyboard.ld\n\n\nA linker script to provide the memory map for your linked code\n\n\n\n\n\n\n\n\nOptionally, create these files as necessary to provide all functionality from Mynewt.\n\n\n\n\n\n\n\n\nFile Path Name\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\nmyboard_boot.ld\n\n\nA linker script to provide the memory map for your bootloader\n\n\n\n\n\n\nmyboard_download.sh\n\n\nA bash script to download code into your platform\n\n\n\n\n\n\nmyboard_debug
.sh\n\n\nA bash script to intiate a gdb session with your platform\n\n\n\n\n\n\nsrc/hal_bsp.c\n\n\nA C source file to provide functions required by the HAL from your BSP\n\n\n\n\n\n\n\n\nFill Out your Package File\n\n\nEdit the package file to describe your BSP. \n\n\nThe package file must contain:\n\n\n \npkg\n.\nname\n: \nhw/bsp/myboard\n\n \npkg\n.\nlinkerscript\n: \nmyboard.ld\n\n\n\n\n\n\n\n\n\n\n\n\nAttribute\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\npkg.name\n\n\nThe name of your bsp package\n\n\n\n\n\n\npkg.linkerscript\n\n\nThe linker script that controls the memory placement of the compiled code sections from the Mynewt OS and your applications.\n\n\n\n\n\n\n\n\nThe linker script is a key component of the BSP and specifies where each section of code and data are stored within your CPU which can vary with the BSP depending on your chosen memory layout. For a tutorial on writing linker scripts, see \nCreate or Copy Linker Script(s)\n.\n\n\nThe package file typically conta
ins:\n\n\n \npkg\n.\nlinkerscript\n.\nbootloader\n.\nOVERWRITE\n: \nmyboard_boot.ld\n\n \npkg\n.\ndownloadscript\n: \nmyboard_download.sh\n\n \npkg\n.\ndebugscript\n: \nmyboard_debug.sh\n\n \npkg\n.\ndeps\n: \n \n-\n \nhw/mcu/mymcu/variant\n\n\n\n\n\n\nwhere \nmymcu/variant\n should be replaced with the specific MCU and variant used in your design.\n\n\nThe following table describes additional attributes relevant to the BSP \npkg.yml\n file.\n\n\n\n\n\n\n\n\nAttribute\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\npkg.linkerscript.bootloader.OVERWRITE\n\n\nA special linker for creating a bootloader for Mynewt\n\n\n\n\n\n\npkg.downloadscript\n\n\nA script that can download a flash image into your target platform\n\n\n\n\n\n\npkg.debugscript\n\n\nA script that can run the GDB debugger on your board\n\n\n\n\n\n\npkg.deps\n\n\nAny dependencies on your BSP\n\n\n\n\n\n\n\n\nThe BSP will invariably depend upon an MCU ( in this sample it's \nhw/mcu/mymcu/variant\n) since the Mynewt OS
runs on an MCU within your target. If your MCU is not supported by Mynewt, see \nMCU Porting\n for details on how to create an MCU in Mynewt.\n\n\nThe package file may also contain:\n\n\n \npkg\n.\ncflags\n: \n-D__MY_SPECIAL_BSP_OPTIONS_\n\n \npkg\n.\ndeps\n:\n \n-\n \nlibs/cmsis-core\n\n\n\n\n\n\n\n\n\n\n\n\nAttribute\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\npkg.cflags\n\n\nAny specific compiler flags for your bsp\n\n\n\n\n\n\npkg.deps\n\n\nAny other libraries that may be required. Some architectures (like ARM) have special libraries to make BSP creation easier.\n\n\n\n\n\n\n\n\nCreate or Copy Linker Script\n\n\nIt's probably best to start with a linker script from another BSP using the same MCU. If this is not available, consult your MCU documentation and library samples to find a linker script to start with.\n\n\nTypically, a linker script has to specify the following sections for code:\n\n\n\n\n.text -- the location and alignment of the memory section to store your cod
e\n\n\n.data -- the location and alignment of the memory section to store initialized data\n\n\n.bss -- the location and alignment of the memory section to store uninitialized data\n\n\n.heap -- the location and alignment of the memory section to provide system memory\n\n\n\n\nThe linker script should specify the location and size of the different memory regions in your BSP and map the code sections described above into these regions. \n\n\nThe linker script should also include an ENTRY point. This is used by the debugger to know where to start the program counter when the target is debugged.\n\n\nThere may be additional requirements from the MCU or OS that you may find easiest to place in the linker script. Some specific variables that the OS and MCU depends on are :\n\n\n\n\n\n\n\n\nVariable\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\n__bss_start__\n\n\na variable located at the start of the BSS section\n\n\n\n\n\n\n__bss_end__\n\n\na variable located at the end of the BSS section\n\n\
n\n\n\n\n__isr_vector\n\n\nSome CPUs map their interrupt vectors. They may need to be specified in the linker\n\n\n\n\n\n\n_user_heap_start\n\n\nthe start of the heap for unallocated memory\n\n\n\n\n\n\n_user_heap_end\n\n\nthe end of the heap for unallocated memory\n\n\n\n\n\n\n\n\nCreate an alternate linker script for the bootloader since it is typically linked to use different addresses to boot the main image. \n\n\nAdd Functions and Defines\n\n\nAt this point, it will be possible to run the \nnewt\n tool to build your target. \n\n\nYou may run into complaints from the linker script that a few Mynewt specific functions are missing. We will describe these below.\n\n\n\n\n\n\n\n\nFunction\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\nos_bsp_init()\n\n\ncode to initialize the bsp\n\n\n\n\n\n\nos_bsp_systick_init()\n\n\ncode to setup the system tick for the OS\n\n\n\n\n\n\n\n\nThere are also several libc definitions that can be stubbed in your first BSP. Examples are \n_write\n, \n_read\n,
etc. that can be found in \nlibc_stubs.c\n. But you \nmust\n implement the following function to provide memory to the OS and system.\n\n\n\n\n\n\n\n\nFunction\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\n_sbrk\n\n\nReturns memory from heap (used by malloc)\n\n\n\n\n\n\n\n\n\n\nImplement \n_sbrk()\n\n\n\n\nsbrk()\n is required by libc to get memory from the heap for things like malloc. Although not strongly BSP dependent, this is currently in the BSP to allow flexibility in providing system memory. See other BSPs for providing \nsbrk\n functionality.\n\n\n\n\nImplement \nos_bsp_init()\n\n\n\n\nos_bsp_init\n should initialize anything required by the OS by the BSP. Typically this is a very small set. \n\n\nNOTE: Currently we are making calls to \n_sbrk()\n and \nclose(0)\n from \nos_bsp_init\n to get around a linker issue where some of libc is not getting included. Please include this in your \nos_bsp_init\n.\n\n\n \n/*\n\n\n * XXX these references are here to keep the functions
in for libc to find.\n\n\n */\n\n \n_sbrk\n(\n0\n);\n \n_close\n(\n0\n);\n\n\n\n\n\n\n\nOther Unresolved Defines or Functions\n\n\n\n\nThere may be other unresolved defines or functions that are required by the specific MCU within your BSP. Below lists some sample defines.\n\n\n\n\n\n\n\n\nUndefined Variable\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\nCONSOLE_UART_PORT\n\n\nWhich communications port on your target runs the console\n\n\n\n\n\n\nLED_BLINK_PIN\n\n\nwhich pin on your target runs the blinky LED\n\n\n\n\n\n\n\n\nThe set of missing functionality depends upon the libraries and dependencies you have included in the project. That's why its best to keep your first project pretty simple then add incrementally. For example, if you include Newtron file system, you will need to define a file system map for your BSP.\n\n\nMissing functionality may take the form of \n#define\n items required to compile, or they may take the form of missing functions. \n\n\n\n\ncmsis_nvic.h\n\
n\n\n\nIf you are using an ARM cortex architecture, you need to define the number of interrupts supported by your system. If you are not using ARM Cortex architecture this may not be required (but something else might be).\n\n\nAdd Debug Script\n\n\nThe debug script in the bsp directory allows the newt tool to automatically connect to the debugger, and create a debug session with the target. This requires knowledge of your target debug interface. Most of the Mynewt BSP targets use \nopenocd\n to perform debugging. This script typically creates an openocd connection to the target and then connects a gdb instance to this openocd connection. There are several examples in existing BSPs to follow.\n\n\nThe script must take a single argument which is the name of the image file minus the '.elf' suffix.\n\n\nThe BSP is complete without this file, but newt will be unable to establish a debug session without it.\n\n\nAdd Download Script\n\n\nSimilar to the debug script, the download scrip
t is a hook for newt to download the image to the target system. The download script also typically uses openocd interface to erase flash, and progam the code into the device.\n\n\nNOTE: The download script needs to command openocd to program the image into the appropriate location, which is typically called \nFLASH_OFFSET\n in these scripts. This location has to match the linker script location of the image link address. For example, if your linker links the code to be run at \n0xC000\n your download script should download the image to the same\naddress in the correct flash. \n\n\nAdd License and Documentation\n\n\nThe \nLICENSE\n file is an ASCII text file that describes the source license for this\npackage.\n\n\nThe \nREADME.md\n is a \nmarkdown\n\n file that contains any documentation you \nwant to provide for the BSP.",
"title": "BSP Porting"
},
{
@@ -3607,7 +3617,7 @@
},
{
"location": "/os/core_os/porting/port_bsp/#create-required-files-for-compilation",
- "text": "Create the following files within the BSP directory tree. For now, they can be empty files. We will fill them out one at a time. File Path Name Description LICENSE A File to present the source license for your BSP README.md A markdown file to write documentation for your BSP pkg.yml A package file to describe your BSP contents include/bsp/bsp.h A header file to include definitions required by system from the BSP src/os_bsp.c A C source file to provide functions required by the OS from your BSP src/sbrk.c A C source file to memory from your heap to the OS src/libc_stubs.c A C source file to provide stubs/methods required by libc myboard.ld A linker script to provide the memory map for your linked code Optionally, create these files as necessary to provide all functionality from Mynewt. File Path Name Description myboard_boot.ld A linker script to provide the memory map for your bootloader myboard_download.s
h A bash script to download code into your platform myboard_debug.sh A bash script to intiate a gdb session with your platform src/hal_bsp.c A C source file to provide functions required by the HAL from your BSP",
+ "text": "Create the following files within the BSP directory tree. For now, they can be empty files. We will fill them out one at a time. File Path Name Description LICENSE A File to present the source license for your BSP README.md A markdown file to write documentation for your BSP pkg.yml A package file to describe your BSP contents include/bsp/bsp.h A header file to include definitions required by system from the BSP include/bsp/bsp_sysid.h A header file to enumerate the devices in your BSP src/os_bsp.c A C source file to provide functions required by the OS from your BSP src/sbrk.c A C source file to memory from your heap to the OS src/libc_stubs.c A C source file to provide stubs/methods required by libc myboard.ld A linker script to provide the memory map for your linked code Optionally, create these files as necessary to provide all functionality from Mynewt. File Path Name Description myboard_boot.ld A li
nker script to provide the memory map for your bootloader myboard_download.sh A bash script to download code in
<TRUNCATED>