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/03/06 01:00:02 UTC
[4/5] incubator-mynewt-site git commit: This closes #32. HAL
documentation added - API, overview, skeleton,
UART. Also minor edits to Arduino zero project.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/2b796b62/mkdocs/search_index.json
----------------------------------------------------------------------
diff --git a/mkdocs/search_index.json b/mkdocs/search_index.json
index a4a0bf2..faf029d 100644
--- a/mkdocs/search_index.json
+++ b/mkdocs/search_index.json
@@ -67,7 +67,7 @@
},
{
"location": "/os/get_started/project1/",
- "text": "Blinky, Your Hello World!\n\n\nObjective\n\n\nLearn how to use packages from a default application repository of Mynewt to build your first \nHello World\n application (Blinky) on a target board. Once built using \nnewt\n tool, this application will blink the LED lights on the target board. Fun stuff!\n\n\nThis tutorial will guide to achieve the following: \n\n\n\n\nSet up the environment on your computer to use Mynewt OS and newt tool. \n\n\nDownload packages for building and testing the project \non a simulated target\n.\n\n\nDownload packages and use tools to create a runtime image for a board to make its LED blink. You have two choices here:\n\n\nDownload an image to SRAM\n, or \n\n\nDownload it to flash\n.\n\n\n\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 with Mac OS (Mac: OS X Yosemite Version 10.10.5) or Linux box (Ubuntu 14.10: Utopic Unicorn)\n\n\nAn account on Github repository and \ngit\n installed on your computer.\n\n\n\n\nAlso, we assume that you're familiar with UNIX shells.\n\n\nLet's gets started!\n\n\nSet up toolchain for Mac\n\n\n\n\nInstall gcc/libc that will produce 32-bit executables, using \nbrew\n. \n\n\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\nInstall the PX4 Toolchain and check the version installed. ARM maintains a pre-built GNU toolchain with a GCC source
branch targeted at Embedded ARM Processors, namely Cortex-R/Cortex-M processor families. After installing, ensure 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\n\n $ brew tap PX4/homebrew-px4\n $ brew update\n $ brew install gcc-arm-none-eabi-49\n $ arm-none-eabi-gcc --version \n arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288]\n Copyright (C) 2014 Free Software Foundation, Inc.\n This is free software; see the source for copying conditions. There is NO\n warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n $ ls -al /usr/local/bin/arm-none-eabi-gdb\n lrwxr-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\n\nNote: If no version is specified, brew will install the latest version available. Mynewt OS 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\nInstall 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, debug, and test embedded target devices, including the Olimex board. For more on OpenOCD go to \nhttp://openocd.org\n.\n\n\n\n\n $ brew install open-ocd\n $ which openocd\n /usr/local/bin/openocd\n $ ls -l $(which openocd)\n lrwxr-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\nAt this point you have installed all the necessary software to build and test
code on a simluator for the Mac OS.\n* Proceed to the \nBuild test code on simulator\n section.\n\n\nSet up toolchain for Linux\n\n\n\n\nInstall gcc/ ibc that will produce 32-bit executables: \n\n\n\n\n $ sudo apt-get install gcc-multilib libc6-i386\n\n\n\n\n\n\nFor the LED project on the Olimex hardware, you should 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\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-get install gcc-arm-none-eabi\n\n\n\n\n\n\n\n\nAnd finally, 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, debug your program and test embedded target dev
ices which, including the Olimex board.\n\n\nIf you are running Ubuntu 15.x, then you are in luck and you can simply run: \n\n\n\n\n\n\n $ sudo apt-get install openocd \n\n\n\n\nFor this project, 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\nAt this point you have installed all the necessary software to build and test code on a simluator for Linux. Proceed to the \nBuild test code on simulator\n section.\n\n\n\n\nInstall newt tool\n\n\nThere are two ways to install the \nnewt\n tool on your computer. The easy way (and the recommeded way for this project) is to download the respective \nnewt\n binaries from the links below:\n\n Mac OS \n\n Linux\n\n\nInclude the \nnewt\n in your $PATH.\n\n\nOr if you're an adventurer then you can set up the environment on your computer, install the Go language, and b
uild the \nnewt\n tool from source as explained in the tutorials in the Newt Tool Manual. See \nInstall newt from source on Mac\n and \nInstall newt from source on Linux\n.\n\n\nBuild test code on simulator\n\n\n1. Clone the larva repository from the Apache git repository into a local directory named \nlarva\n.\n\n\n $ cd ~/dev \n $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva\n $ ls\n\n go larva\n $ ls larva\n DISCLAIMER NOTICE app.yml compiler hw net project sys\n LICENSE README.md autotargets fs libs pkg-list.yml scripts\n\n\n\n\n2. Create a target using the newt tool. \n\n\n $ cd larva\n $ newt target create sim_test\n Creating target sim_test\n Target sim_test sucessfully created!\n $ newt target show\n sim_test\n name: sim_test\n arch: sim\n\n\n\n\n3. Now continue to populate and build out
the sim project.\n\n\n $ newt target set sim_test project=test\n Target sim_test successfully set project to test\n $ newt target set sim_test compiler_def=debug\n Target sim_test successfully set compiler_def to debug\n $ newt target set sim_test bsp=hw/bsp/native\n Target sim_test successfully set bsp to hw/bsp/native\n $ newt target set sim_test compiler=sim\n Target sim_test successfully set compiler to sim\n $ newt target show sim_test\n sim_test\n arch=sim\n bsp=hw/bsp/native\n compiler=sim\n compiler_def=debug\n name=sim_test\n project=test\n\n\n\n\n4. Configure \nnewt\n to use the gnu build tools native to OS X or Linux. In order for sim to work properly, it needs the 32-bit gcc (gcc-5). Replace \n~/dev/larva/compiler/sim/compiler.yml\n with the \ncompiler/sim/osx-compiler.yml\n or \nlinux-compiler.yml\n file, depending on the system. On a
Windows machine, follow the instruction for the Linux machine as you are running 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\n\nFor a Linux machine:\n\n\n $ cp compiler/sim/linux-compiler.yml compiler/sim/compiler.yml\n\n\n\n\n5. Next, build the packages for the sim project using the \nnewt\n tool. For extra details, specify the VERBOSE option.\n\n\n $ newt target build sim_test\n Building target sim_test (project = test)\n ...\n ...\n Successfully run!\n\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\n 2015/09/29 09:46:12 [INFO] Building project test\n 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//bootutil...\n 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//cmsis-core...\n 2
015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//ffs..\n ...\n Successfully run!\n\n\n\n\n6. Run the test suite executable inside this project and enjoy your first successful test!\n\n\n $ 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 ...\n ...\n [pass] cbmem_test_suite/cbmem_test_case_3\n\n\n\n\nUse SRAM to make LED blink\n\n\nIf you wish to build the image to run from the onboard SRAM on Olimex board, follow the steps below:\n\n\nPreparing the Software\n\n\n\n\n\n\nMake sure the PATH environment variable includes the $HOME/dev/go/bin directory. \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. Go to ~/dev and clone th
e larva repository from the apache git repository into a local directory named \nlarva\n.\n\n\n\n\n\n\n $ cd ~/dev \n $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva\n $ ls\n\n go larva\n $ ls larva\n DISCLAIMER NOTICE app.yml compiler hw net project sys\n LICENSE README.md autotargets fs libs pkg-list.yml scripts\n\n\n\n\n\n\n\n\nChange directory to ~dev/larva directory and build the \nblinky\n project inside larva, using the \nnewt\n tool. Starting with the target name, assign specific aspects of the project, as shown below, to pull the appropriate packages and build the right bundle or list for the board. For example, we set the architecture (arch), compiler, board support package (bsp), project, and compiler mode.\n\n\n(Remember 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\n\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 arch=cortex_m4\n bsp=hw/bsp/olimex_stm32-e407_devboard\n compiler=arm-none-eabi-m4\n compiler_def=debug\n name=blinky\n project=blinky\n\n\n\n\n\n\nNe
xt, let's build the image with the above values assigned. By default, the linker script within the \nhw/bsp/olimex_stm32-e407_devboard\n package builds an image for flash memory, which we don't want; instead, we want an image for the SRAM, so you need to switch that script with \nrun_from_sram.ld\n. \n\n\n\n\n\n(We are working to simplify this scheme whereby an executable for a project will correctly elect the linker scripts and generate the relevant image. For example, the scheme will key on project identity such as bootloader, RAM, Flash (default) and build accordingly. \n.)\n\n\nAfer you build the target, you can find the executable *blinky.elf* in the project directory *~/dev/larva/project/blinky/bin/blinky.*\n\n\n\n $ cd ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard\n $ diff olimex_stm32-e407_devboard.ld run_from_sram.ld\n (some diff will be displayed)\n $ cp run_from_sram.ld olimex_stm32-e407_devboard.ld\n $ cd ~/dev/larva/project/blinky/\n
$ newt target build blinky\n Building target blinky (project = blinky)\n Compiling case.c\n Compiling suite.c\n ...\n Successfully run!\n $ ls bin/blinky\n blinky.elf blinky.elf.bin blinky.elf.cmd blinky.elf.lst blinky.elf.map\n\n\n\n\n\n\nCheck if you have all the scripts needed to launch OpenOCD and interact with the project's specific hardware. Depending on your system (Ubuntu or 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 they exist, you are all set and can proceed to prepare the hardware. Otherwise check the \n~/dev/larva/hw/bsp/olimex_stm32-e407_devboard\n directory for a file named \nf407.cfg\n. Used by OpenOCD, this config enables us to interact with this specific hardware. \n\n\n\n\nYou are all set if you see the file.\n\n\n $ ls ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard\n bin include oli
mex_stm32-e407_devboard_download.sh run_from_loader.ld\n boot-olimex_stm32-e407_devboard.ld olimex_stm32-e407_devboard.ld pkg.yml run_from_sram.ld\n f407.cfg olimex_stm32-e407_devboard_debug.sh run_from_flash.ld src\n\n\n\n\nPrepare 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. Note that because the markings on the board may not always be accurate, when in doubt, you should always refer to the manual for the correct positioning. Since the jumpers are a pair, they should move together, and as such, the pair is responsible for the boot mode when bootloader is present. \nTo locate the bootloader, the board searches in three places: User Flash Memory, System Memory or the Embedded SRAM. For this Blinky project, we will configure it to boot from SRAM by jumpering \nB0_1\n and \nB1_1\n.\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\nEnsure that you are in the blinky project directory with the \nblinky.elf\n executable. Run the debug command in the \nnewt\n tool. You'll see some status messages as shown below. In case you need to halt the debugging session, you can issue an \n-c \"reset halt\"\n command.\n\n\n\n\n $ cd ~/dev/larva/project/blinky/bin/blinky\n $ newt target debug blinky\n Debugging with /Users/aditihilbert/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_debug.sh blinky\n Debugging /Users/aditihilbert/dev/larva/project/blinky/bin/blinky/blinky.elf\n GNU gdb (GNU Tools for ARM Embedded Processors) 7
.8.0.20150604-cvs\n Copyright (C) 2014 Free Software Foundation, Inc.\n License GPLv3+: GNU GPL version 3 or later \nhttp://gnu.org/licenses/gpl.html\n\n ...\n (info)\n ...\n target state: halted\n target halted due to debug-request, current mode: Thread \n xPSR: 0x01000000 pc: 0x20000250 msp: 0x10010000\n Info : accepting 'gdb' connection from 3333\n Info : device id = 0x10036413\n Info : flash size = 1024kbytes\n Reset_Handler () at startup_STM32F40x.s:199\n 199 ldr r1, =__etext\n\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. For example, \n\n\n (gdb) set $msp=0x10010000\n\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
\n Loading section .text, size 0x4294 lma 0x20000000\n Loading section .ARM.extab, size 0x24 lma 0x20004294\n Loading section .ARM.exidx, size 0xd8 lma 0x200042b8\n Loading section .data, size 0x874 lma 0x20004390\n Start address 0x20000250, load size 19460\n Transfer rate: 81 KB/sec, 2432 bytes/write.\n (gdb) c\n Continuing.\n\n\n\n\n\n\nVoil\u00e0! The board's LED should be blinking at 1 Hz. Success!\n\n\n\n\nUse flash to make LED blink\n\n\nIf you wish to build the image to run from the onboard flash memory on Olimex board, follow the steps below:\n\n\n\n\nConfigure the board to boot from flash by moving the two jumpers together to \nB0_0\n and \nB1_0\n. Refer to the pictures of the board under the section titled \n\"Prepare 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\nIf you skipped the first option for the project \n(downloading an ima
ge to SRAM)\n, then skip this step. Otherwise, continue with this step. \n\n\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 (some diff will be displayed)\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\nIn order to run the image from flash, you need to build the bootloader as well. The bootloader does the initial set 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 \nbin2image\n 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\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 bsp=hw/bsp/native\n compiler=sim\n compiler_def=debug\n name=bin2img\n project=bin2img\n\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 boot_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 arch=cortex_m4\n bsp=hw/bsp/olimex_stm32-e407_devboard\n compiler=arm-none-eabi-m4\n compiler_def=optimized\n name=boot_olimex\n project=boot\n\n\n\n\n\n\nNow let's build all the three targets now.\n\n\n\n\n $ newt target build bin2img\n Building target bin2img (project = bin2img)\n Building project bin2img\n ...\n Successfully run!\n $ newt target build boot_olimex\n Building target boot_olimex (project = boot)\n Building project boot\n ...\n Successfully run!\n $ newt target build blinky\n Building target blinky (project = blinky)\n Building project blinky\n Successfully run!\n\n\n\n\n\n\nGo to the project directory and download the bootloader and the image t
o flash ... in a flash! \n\n\n\n\n $ cd ~/dev/larva/project/blinky/bin/blinky\n $ newt target download boot_olimex\n Downloading with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_download.sh\n $ newt target download blinky\n Downloading with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_download.sh\n\n\n\n\n\n\n\n\nVoil\u00e0! The LED should be blinking! Success!\n\n\n\n\n\n\nBut wait...not so fast. 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, severing the debug connection to the JTAG port. 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\n\n\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 target debug blinky\n instead of \nnewt target download blinky\n.\n\n\n $ newt target debug blinky\n Debugging with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_debug.sh blinky\n Debugging ~/dev/larva/project/blinky/bin/blinky/blinky.elf\n GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs\n Copyright (C) 2014 Free Software Foundation, Inc.\n License GPLv3+: GNU GPL version 3 or later \nhttp://gnu.org/licenses/gpl.html\n\n ...\n (info)\n ...\n target state: halted\n target halted due to debug-request, current mode: Thread \n xPSR: 0x01000000 pc: 0x08000250 msp: 0x10010000\n Info : accepting 'gdb' connection from 3333\n Info : device id = 0x10036413\n Info : flash size = 1024kbytes\n Reset_Handler () at startup_STM32F40x.s:199\n 199 ldr r1, =__etext\n (gdb)\n\n\n\n\nNote #2: If you want to erase the fla
sh 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 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\n erased sectors 0 through 4 on flash bank 0 in 2.296712s\n (gdb) monitor mdw 0x08000000 16\n 0x08000000: 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\n\n\n\nConclusion\n\n\nIn summation, you achieved and learned a fair amount in this hands-on tutorial. If this is your first time to embedded systems, this must feel like the best hands-on and low-level \"Hello World\" progam ever. \n\n\nGood, we have more fun tutorials for you to get your hands dirty. Be bold and try other Blinky-like \nTutorials\n.\n\n\nIf you see anything missing or want to send us feeback, please do so by signing up for appropriate mailing lists on our \nCommunity Page\n\n\nKeep on hacking and blinking!",
+ "text": "Blinky, Your Hello World!\n\n\nObjective\n\n\nLearn how to use packages from a default application repository of Mynewt to build your first \nHello World\n application (Blinky) on a target board. Once built using \nnewt\n tool, this application will blink the LED lights on the target board. Fun stuff!\n\n\nThis tutorial will guide to achieve the following: \n\n\n\n\nSet up the environment on your computer to use Mynewt OS and newt tool. \n\n\nDownload packages for building and testing the project \non a simulated target\n.\n\n\nDownload packages and use tools to create a runtime image for a board to make its LED blink. You have two choices here:\n\n\nDownload an image to SRAM\n, or \n\n\nDownload it to flash\n.\n\n\n\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 with Mac OS (Mac: OS X Yosemite Version 10.10.5) or Linux box (Ubuntu 14.10: Utopic Unicorn)\n\n\nAn account on Github repository and \ngit\n installed on your computer.\n\n\n\n\nAlso, we assume that you're familiar with UNIX shells.\n\n\nLet's gets started!\n\n\nSet up toolchain for Mac\n\n\n\n\nInstall gcc/libc that will produce 32-bit executables, using \nbrew\n. \n\n\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\nInstall the PX4 Toolchain and check the version installed. ARM maintains a pre-built GNU toolchain with a GCC source
branch targeted at Embedded ARM Processors, namely Cortex-R/Cortex-M processor families. After installing, ensure 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\n\n $ brew tap PX4/homebrew-px4\n $ brew update\n $ brew install gcc-arm-none-eabi-49\n $ arm-none-eabi-gcc --version \n arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288]\n Copyright (C) 2014 Free Software Foundation, Inc.\n This is free software; see the source for copying conditions. There is NO\n warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n $ ls -al /usr/local/bin/arm-none-eabi-gdb\n lrwxr-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\n\nNote: If no version is specified, brew will install the latest version available. Mynewt OS 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\nInstall 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, debug, and test embedded target devices, including the Olimex board. For more on OpenOCD go to \nhttp://openocd.org\n.\n\n\n\n\n $ brew install open-ocd\n $ which openocd\n /usr/local/bin/openocd\n $ ls -l $(which openocd)\n lrwxr-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\nAt this point you have installed all the necessary software to build and test
code on a simluator for the Mac OS.\n* Proceed to the \nBuild test code on simulator\n section.\n\n\nSet up toolchain for Linux\n\n\n\n\nInstall gcc/ ibc that will produce 32-bit executables: \n\n\n\n\n $ sudo apt-get install gcc-multilib libc6-i386\n\n\n\n\n\n\nFor the LED project on the Olimex hardware, you should 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\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-get install gcc-arm-none-eabi\n\n\n\n\n\n\n\n\nAnd finally, 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, debug your program and test embedded target dev
ices which, including the Olimex board.\n\n\nIf you are running Ubuntu 15.x, then you are in luck and you can simply run: \n\n\n\n\n\n\n $ sudo apt-get install openocd \n\n\n\n\nFor this project, 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\nAt this point you have installed all the necessary software to build and test code on a simluator for Linux. Proceed to the \nBuild test code on simulator\n section.\n\n\n\n\nInstall newt tool\n\n\nThere are two ways to install the \nnewt\n tool on your computer. The easy way (and the recommeded way for this project) is to download the respective \nnewt\n binaries from the links below:\n\n Mac OS \n\n Linux\n\n\nInclude the \nnewt\n in your $PATH.\n\n\nOr if you're an adventurer then you can set up the environment on your computer, install the Go language, and b
uild the \nnewt\n tool from source as explained in the tutorials in the Newt Tool Manual. See \nInstall newt from source on Mac\n and \nInstall newt from source on Linux\n.\n\n\nBuild test code on simulator\n\n\n1. Clone the larva repository from the Apache git repository into a local directory named \nlarva\n.\n\n\n $ cd ~/dev \n $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva\n $ ls\n\n go larva\n $ ls larva\n DISCLAIMER NOTICE app.yml compiler hw net project sys\n LICENSE README.md autotargets fs libs pkg-list.yml scripts\n\n\n\n\n2. Create a target using the newt tool. \n\n\n $ cd larva\n $ newt target create sim_test\n Creating target sim_test\n Target sim_test sucessfully created!\n $ newt target show\n sim_test\n name: sim_test\n arch: sim\n\n\n\n\n3. Now continue to populate and build out
the sim target. \n\n\n $ newt target set sim_test project=test\n Target sim_test successfully set project to test\n $ newt target set sim_test compiler_def=debug\n Target sim_test successfully set compiler_def to debug\n $ newt target set sim_test bsp=hw/bsp/native\n Target sim_test successfully set bsp to hw/bsp/native\n $ newt target set sim_test compiler=sim\n Target sim_test successfully set compiler to sim\n $ newt target show sim_test\n sim_test\n arch=sim\n bsp=hw/bsp/native\n compiler=sim\n compiler_def=debug\n name=sim_test\n project=test\n\n\n\n\n4. Configure \nnewt\n to use the gnu build tools native to OS X or Linux. In order for sim to work properly, it needs the 32-bit gcc (gcc-5). Replace \n~/dev/larva/compiler/sim/compiler.yml\n with the \ncompiler/sim/osx-compiler.yml\n or \nlinux-compiler.yml\n file, depending on the system. On a
Windows machine, follow the instruction for the Linux machine as you are running 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\n\nFor a Linux machine:\n\n\n $ cp compiler/sim/linux-compiler.yml compiler/sim/compiler.yml\n\n\n\n\n5. Next, build the packages for the sim project using the \nnewt\n tool. You should see lots of console output while \nnewt\n is resolving dependencies and compiling the source code. After a minute, it should complete with \nthe \nSuccessfully run!\n text.\n\n\n $ newt target build sim_test\n Building target sim_test (project = test)\n ...\n ...\n Successfully run!\n\n\n\n\nFor extra details, specify the VERBOSE option.\n\n\n $newt -l VERBOSE target build sim_test\n 2015/09/29 09:46:12 [INFO] Building project test\n 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//bootutil...
\n 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//cmsis-core...\n 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//ffs..\n ...\n Successfully run!\n\n\n\n\n6. Run the test suite executable inside this project and enjoy your first successful test!\n\n\n $ 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 ...\n ...\n [pass] cbmem_test_suite/cbmem_test_case_3\n\n\n\n\nUse SRAM to make LED blink\n\n\nIf you wish to build the image to run from the onboard SRAM on Olimex board, follow the steps below:\n\n\nPreparing the Software\n\n\n\n\n\n\nMake sure the PATH environment variable includes the $HOME/dev/go/bin directory. \n\n\n\n\n\n\nIf you have cloned the larva repository for the simulator test in the previous sect
ion, you can skip this step. Otherwise, you have to create a repository for the project. Go to ~/dev and clone the larva repository from the apache git repository into a local directory named \nlarva\n.\n\n\n\n\n\n\n $ cd ~/dev \n $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva\n $ ls\n\n go larva\n $ ls larva\n DISCLAIMER NOTICE app.yml compiler hw net project sys\n LICENSE README.md autotargets fs libs pkg-list.yml scripts\n\n\n\n\n\n\n\n\nChange directory to ~dev/larva directory and build the \nblinky\n project inside larva, using the \nnewt\n tool. Starting with the target name, assign specific aspects of the project, as shown below, to pull the appropriate packages and build the right bundle or list for the board. For example, we set the architecture (arch), compiler, board support package (bsp), project, and compiler mode.\n\n\n(Remember 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\n\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 arch=cortex_m4\n bsp=hw/bsp/olimex_stm32-e407_devboard\n compiler=arm-
none-eabi-m4\n compiler_def=debug\n name=blinky\n project=blinky\n\n\n\n\n\n\nNext, let's build the image with the above values assigned. By default, the linker script within the \nhw/bsp/olimex_stm32-e407_devboard\n package builds an image for flash memory, which we don't want; instead, we want an image for the SRAM, so you need to switch that script with \nrun_from_sram.ld\n. \n\n\n\n\n\n(We are working to simplify this scheme whereby an executable for a project will correctly elect the linker scripts and generate the relevant image. For example, the scheme will key on project identity such as bootloader, RAM, Flash (default) and build accordingly. \n.)\n\n\nAfer you build the target, you can find the executable *blinky.elf* in the project directory *~/dev/larva/project/blinky/bin/blinky.*\n\n\n\n $ cd ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard\n $ diff olimex_stm32-e407_devboard.ld run_from_sram.ld\n (some diff will be disp
layed)\n $ cp run_from_sram.ld olimex_stm32-e407_devboard.ld\n $ cd ~/dev/larva/project/blinky/\n $ newt target build blinky\n Building target blinky (project = blinky)\n Compiling case.c\n Compiling suite.c\n ...\n Successfully run!\n $ ls bin/blinky\n blinky.elf blinky.elf.bin blinky.elf.cmd blinky.elf.lst blinky.elf.map\n\n\n\n\n\n\nCheck if you have all the scripts needed to launch OpenOCD and interact with the project's specific hardware. Depending on your system (Ubuntu or 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 they exist, you are all set and can proceed to prepare the hardware. Otherwise check the \n~/dev/larva/hw/bsp/olimex_stm32-e407_devboard\n directory for a file named \nf407.cfg\n. Used by OpenOCD, this config enables us to interact with this specific hardware. \n\n\n\n\nYou are all set if y
ou see the file.\n\n\n $ ls ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard\n bin include olimex_stm32-e407_devboard_download.sh run_from_loader.ld\n boot-olimex_stm32-e407_devboard.ld olimex_stm32-e407_devboard.ld pkg.yml run_from_sram.ld\n f407.cfg olimex_stm32-e407_devboard_debug.sh run_from_flash.ld src\n\n\n\n\nPrepare 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. Note that because the markings on the board may not always be accurate, when in doubt, you should always refer to the manual for the correct positioning. Since the jumpers are a pair, they should move together, and as such, the pair is responsible for the boot mode when bootloader is present. \nTo locate the bootloader, the board searches in three places: User Flash Memory, System Memory or the Embedded SRAM. For this Blinky project, we will configure it to
boot from SRAM by jumpering \nB0_1\n and \nB1_1\n.\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\nEnsure that you are in the blinky project directory with the \nblinky.elf\n executable. Run the debug command in the \nnewt\n tool. You'll see some status messages as shown below. In case you need to halt the debugging session, you can issue an \n-c \"reset halt\"\n command.\n\n\n\n\n $ cd ~/dev/larva/project/blinky/bin/blinky\n $ newt target debug blinky\n Debugging with /Users/aditihilbert/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_debug.sh blinky\n Debugging /Users/aditi
hilbert/dev/larva/project/blinky/bin/blinky/blinky.elf\n GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs\n Copyright (C) 2014 Free Software Foundation, Inc.\n License GPLv3+: GNU GPL version 3 or later \nhttp://gnu.org/licenses/gpl.html\n\n ...\n (info)\n ...\n target state: halted\n target halted due to debug-request, current mode: Thread \n xPSR: 0x01000000 pc: 0x20000250 msp: 0x10010000\n Info : accepting 'gdb' connection from 3333\n Info : device id = 0x10036413\n Info : flash size = 1024kbytes\n Reset_Handler () at startup_STM32F40x.s:199\n 199 ldr r1, =__etext\n\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. For example, \n\n\n (gdb) set $msp=0x10010000\n\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 \n Loading section .text, size 0x4294 lma 0x20000000\n Loading section .ARM.extab, size 0x24 lma 0x20004294\n Loading section .ARM.exidx, size 0xd8 lma 0x200042b8\n Loading section .data, size 0x874 lma 0x20004390\n Start address 0x20000250, load size 19460\n Transfer rate: 81 KB/sec, 2432 bytes/write.\n (gdb) c\n Continuing.\n\n\n\n\n\n\nVoil\u00e0! The board's LED should be blinking at 1 Hz. Success!\n\n\n\n\nUse flash to make LED blink\n\n\nIf you wish to build the image to run from the onboard flash memory on Olimex board, follow the steps below:\n\n\n\n\nConfigure the board to boot from flash by moving the two jumpers together to \nB0_0\n and \nB1_0\n. Refer to the pictures of the board under the section titled \n\"Prepare 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\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\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 (some diff will be displayed)\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\nIn order to run the image fro
m flash, you need to build the bootloader as well. The bootloader does the initial set 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 \nbin2image\n 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\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 $ ne
wt 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 bsp=hw/bsp/native\n compiler=sim\n compiler_def=debug\n name=bin2img\n project=bin2img\n\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 boot_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 arch=cortex_m4\n bsp=hw/bsp/olimex_stm32-e407_devboard\n compiler=arm-none-eabi-m4\n compiler_def=optimized\n name=boot_olimex\n project=boot\n\n\n\n\n\n\nNow let's build all the three targets now.\n\n\n\n\n $ newt target build bin2img\n Building target bin2img (project = bin2img)\n Building project bin2img\n ...\n Successfully run!\n $ newt target build boot_olimex\n Building target boot_olimex (project = boot)\n Building project boot\n ...\n Successfully run!\n $ newt target build blinky\n Building target blinky (project = blinky)\n Building project blink
y\n Successfully run!\n\n\n\n\n\n\nGo to the project directory and download the bootloader and the image to flash ... in a flash! \n\n\n\n\n $ cd ~/dev/larva/project/blinky/bin/blinky\n $ newt target download boot_olimex\n Downloading with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_download.sh\n $ newt target download blinky\n Downloading with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_download.sh\n\n\n\n\n\n\n\n\nVoil\u00e0! The LED should be blinking! Success!\n\n\n\n\n\n\nBut wait...not so fast. 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, severing the debug connection to the JTAG port. 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\n\n\n\n\nThe LED light will start bl
inking again. Success!\n\n\nNote #1: If you want to download the image to flash and a gdb session opened up, use \nnewt target debug blinky\n instead of \nnewt target download blinky\n.\n\n\n $ newt target debug blinky\n Debugging with ~/dev/larva/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_debug.sh blinky\n Debugging ~/dev/larva/project/blinky/bin/blinky/blinky.elf\n GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs\n Copyright (C) 2014 Free Software Foundation, Inc.\n License GPLv3+: GNU GPL version 3 or later \nhttp://gnu.org/licenses/gpl.html\n\n ...\n (info)\n ...\n target state: halted\n target halted due to debug-request, current mode: Thread \n xPSR: 0x01000000 pc: 0x08000250 msp: 0x10010000\n Info : accepting 'gdb' connection from 3333\n Info : device id = 0x10036413\n Info : flash size = 1024kbytes\n Reset_Handler () at startup_S
TM32F40x.s:199\n 199 ldr r1, =__etext\n (gdb)\n\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 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\n erased sectors 0 through 4 on flash bank 0 in 2.296712s\n (gdb) monitor mdw 0x08000000 16\n 0x08000000: 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\n\n\n\nConclusion\n\n\nIn summation, you achieved and learned a fair amount in this hands-on tutorial. If this is your first time to embedded systems, this must feel like the best hands-on and low-level \"Hello World\" progam ever. \n\n\nGood, we have more fun tutorials for you to get your hands dirty. Be bold and try other Blinky-like \ntutorials\n.\n\n\nIf you see anything missing or want to send us feeback, please do so by signing up for appropriate mailing lists on our \nCommunity Page\n\n\nKeep on hacking and blinking!",
"title": "Blinky, The First Project"
},
{
@@ -102,7 +102,7 @@
},
{
"location": "/os/get_started/project1/#build-test-code-on-simulator",
- "text": "1. Clone the larva repository from the Apache git repository into a local directory named larva . $ cd ~/dev \n $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva\n $ ls\n\n go larva\n $ ls larva\n DISCLAIMER NOTICE app.yml compiler hw net project sys\n LICENSE README.md autotargets fs libs pkg-list.yml scripts 2. Create a target using the newt tool. $ cd larva\n $ newt target create sim_test\n Creating target sim_test\n Target sim_test sucessfully created!\n $ newt target show\n sim_test\n name: sim_test\n arch: sim 3. Now continue to populate and build out the sim project. $ newt target set sim_test project=test\n Target sim_test successfully set project to test\n $ newt target set sim_test compiler_def=debug\n Target sim_test successfully
set compiler_def to debug\n $ newt target set sim_test bsp=hw/bsp/native\n Target sim_test successfully set bsp to hw/bsp/native\n $ newt target set sim_test compiler=sim\n Target sim_test successfully set compiler to sim\n $ newt target show sim_test\n sim_test\n arch=sim\n bsp=hw/bsp/native\n compiler=sim\n compiler_def=debug\n name=sim_test\n project=test 4. Configure newt to use the gnu build tools native to OS X or Linux. In order for sim to work properly, it needs the 32-bit gcc (gcc-5). Replace ~/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 running commands in a Linux VM. For a Mac OS X environment: $ cp compiler/sim/osx-compiler.yml compiler/sim/compiler.yml For a Linux machine: $
cp compiler/sim/linux-compiler.yml compiler/sim/compiler.yml 5. Next, build the packages for the sim project using the newt tool. For extra details, specify the VERBOSE option. $ newt target build sim_test\n Building target sim_test (project = test)\n ...\n ...\n Successfully run! You can specify the VERBOSE option if you want to see the gory details. $newt -l VERBOSE target build sim_test\n 2015/09/29 09:46:12 [INFO] Building project test\n 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//bootutil...\n 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//cmsis-core...\n 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//ffs..\n ...\n Successfully run! 6. Run the test suite executable inside this project and enjoy your first successful test! $ project/test/bin/sim_test/test.elf\n [pass] os_me
mpool_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 ...\n ...\n [pass] cbmem_test_suite/cbmem_test_case_3",
+ "text": "1. Clone the larva repository from the Apache git repository into a local directory named larva . $ cd ~/dev \n $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git larva\n $ ls\n\n go larva\n $ ls larva\n DISCLAIMER NOTICE app.yml compiler hw net project sys\n LICENSE README.md autotargets fs libs pkg-list.yml scripts 2. Create a target using the newt tool. $ cd larva\n $ newt target create sim_test\n Creating target sim_test\n Target sim_test sucessfully created!\n $ newt target show\n sim_test\n name: sim_test\n arch: sim 3. Now continue to populate and build out the sim target. $ newt target set sim_test project=test\n Target sim_test successfully set project to test\n $ newt target set sim_test compiler_def=debug\n Target sim_test successfully
set compiler_def to debug\n $ newt target set sim_test bsp=hw/bsp/native\n Target sim_test successfully set bsp to hw/bsp/native\n $ newt target set sim_test compiler=sim\n Target sim_test successfully set compiler to sim\n $ newt target show sim_test\n sim_test\n arch=sim\n bsp=hw/bsp/native\n compiler=sim\n compiler_def=debug\n name=sim_test\n project=test 4. Configure newt to use the gnu build tools native to OS X or Linux. In order for sim to work properly, it needs the 32-bit gcc (gcc-5). Replace ~/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 running commands in a Linux VM. For a Mac OS X environment: $ cp compiler/sim/osx-compiler.yml compiler/sim/compiler.yml For a Linux machine: $
cp compiler/sim/linux-compiler.yml compiler/sim/compiler.yml 5. Next, build the packages for the sim project using the newt tool. You should see lots of console output while newt is resolving dependencies and compiling the source code. After a minute, it should complete with \nthe Successfully run! text. $ newt target build sim_test\n Building target sim_test (project = test)\n ...\n ...\n Successfully run! For extra details, specify the VERBOSE option. $newt -l VERBOSE target build sim_test\n 2015/09/29 09:46:12 [INFO] Building project test\n 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//bootutil...\n 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//cmsis-core...\n 2015/09/29 09:46:12 [INFO] Loading Package /Users/aditihilbert/dev/larva/libs//ffs..\n ...\n Successfully run! 6. Run the test suite executable inside this proj
ect and enjoy your first successful test! $ 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 ...\n ...\n [pass] cbmem_test_suite/cbmem_test_case_3",
"title": "Build test code on simulator"
},
{
@@ -132,7 +132,7 @@
},
{
"location": "/os/get_started/project1/#conclusion",
- "text": "In summation, you achieved and learned a fair amount in this hands-on tutorial. If this is your first time to embedded systems, this must feel like the best hands-on and low-level \"Hello World\" progam ever. Good, we have more fun tutorials for you to get your hands dirty. Be bold and try other Blinky-like Tutorials . If you see anything missing or want to send us feeback, please do so by signing up for appropriate mailing lists on our Community Page Keep on hacking and blinking!",
+ "text": "In summation, you achieved and learned a fair amount in this hands-on tutorial. If this is your first time to embedded systems, this must feel like the best hands-on and low-level \"Hello World\" progam ever. Good, we have more fun tutorials for you to get your hands dirty. Be bold and try other Blinky-like tutorials . If you see anything missing or want to send us feeback, please do so by signing up for appropriate mailing lists on our Community Page Keep on hacking and blinking!",
"title": "Conclusion"
},
{
@@ -232,7 +232,7 @@
},
{
"location": "/os/tutorials/arduino_zero/",
- "text": "Running Mynewt on Arduino Zero\n\n\nThis tutorial describes how to run Mynewt OS on Arduino Zero. \n\n\nPrerequisites\n\n\nBefore tackling this tutorial, its best to read about Mynewt in the \n\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. \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\nSteps\n\n\nFollow these simple steps and you be blinking in no time.\n\n\nInstall Mynewt and Newt\n\n\nIf you have not already done so, install Newt, Mynewt and other\nprerequisites as shown \nhere\n\n\nFetch External Packages for Atmel SAMD21\n\n\nMynewt uses source code provided directly from the chip manufacturer for \nlow level operations. This code is licensed only for Atmel
parts, and \ncannot live in the Apache Mynewt repository. Fetch the package from \nthe runtime github repository\n\n\nnewt app add-pkg-list mynewt_arduino https://github.com/runtimeinc/mynewt_arduino_zero.git\n\n\n\n\nOnce that completes install the arduino_zero bsp package\n\n\nnewt pkg install hw/bsp/arduino_zero\n\n\n\n\nCreate your bootloader Target\n\n\nYou need to tell Newt what you want to build. This is done by setting up a \ntarget. You may have already seen this target definition in this \n\nExample\n\n\nnewt target import arduino_zero_bootloader\n@target=arduino_zero_bootloader\nname=arduino_zero_bootloader\nproject=boot\nbsp=hw/bsp/arduino_zero\ncompiler=arm-none-eabi-m0\nvers=0.0.1\narch=cortex_m0\ncompiler_def=optimized\n@endtargets\n\n\n\n\nIf your console blocks, you may need to do a \nctrl-D\n to complete \nthe import.\n\n\nCreate Your Image Target\n\n\nYou need to tell Newt what you want to build. This is done by setting up a \ntarget. You may have already se
en this target definition in this \n\nExample\n\n\nFor simplicity, you can just import this target. Just cut and paste\nthis into your Linux or MAC terminal from the larva directory.\n\n\nnewt target import arduino_zero_blinky \n@target=arduino_zero_blinky \nvers=0.0.1 \narch=cortex_m0 \ncompiler_def=debug \nname=arduino_zero_blinky \nbsp=hw/bsp/arduino_zero \ncompiler=arm-none-eabi-m0 \nproject=blinky \n@endtargets\n\n\n\n\nIf your console blocks, you may need to do a \nctrl-D\n to complete \nthe import.\n\n\nVerify Your Targets\n\n\nDepending on your shell you may need to do a \nCtrl-D\n to terminate the import\noperation. \n\n\nYou can do a \nnewt target show\n to see your results.\n\n\narduino_zero_blinky\n arch=cortex_m0\n bsp=hw/bsp/arduino_zero\n compiler=arm-none-eabi-m0\n compiler_def=debug\n name=arduino_zero_blinky\n project=blinky\n vers=0.0.1\narduino_zero_bootloader\n arch=cortex_m0\n bsp=hw/bsp/arduino_zero\n compiler=arm-none-eabi-m0\n
compiler_def=optimized\n name=arduino_zero_bootloader\n project=boot\n vers=0.0.1\n\n\n\n\nBuild the Bootloader\n\n\nTo Build the bootloader, use newt to do:\n\n\nnewt target build arduino_zero_bootloader\n\n\n\n\nYou should see lots of console output while newt is resolving dependencies\nand compiling the source code. After a minute, it should complete with \nthe following text.\n\n\n. . .\nArchiving libarduino_zero.a\nCompiling boot.c\nBuilding project boot\nLinking boot.elf\nSuccessfully run!\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. Mynewt will\ndownload and debug the target through this port.\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\nDownload the Bootloader\n\n\nExecute the command to downl
oad the bootloader. \n\n\nnewt target download arduino_zero_bootloader\n\n\n\n\nThe newt tool should respond with. Then 10-15 seconds later it will return a \nprompt indicating success.\n\n\nDownloading with .../arduino_zero_download.sh\n\n\n\n\nBuild the Target\n\n\nTo Build the target, use newt to do:\n\n\nnewt target build arduino_zero_blinky\n\n\n\n\nYou should see lots of console output while newt is resolving dependencies\nand compiling the source code. After a minute, it should complete with \nthe following text.\n\n\nArchiving libarduino_zero.a\nCompiling main.c\nBuilding project blinky\nLinking blinky.elf\nSuccessfully run!\n\n\n\n\nBuild the Downloadable Image\n\n\nThis command attaches the image descriptor header with the specicifed version\nnumber and prepares the image for download.\n\n\nnewt target create-image arduino_zero_blinky 1.2.3\n\n\n\n\nDownload the Image\n\n\nExecute the command to download the image. \n\n\nnewt target download arduino_zero_blinky\n\n\n\n\nT
he newt tool should respond with. Then 10-15 seconds later it will return a \nprompt indicating success.\n\n\nDownloading with .../arduino_zero_download.sh\n\n\n\n\nWatch the LED blink\n\n\nCongratulations!. You have create a Mynewt operating system running on the \nArduino Zero. The LED 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. \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. \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\nSteps\n\n\nFollow these simple steps and your board will be blinking in no time!\n\n\nInstall Mynewt and Newt\n\n\nIf you have not already done so, install Newt as shown in the \nNewt install tutorial\n and cloned the Mynewt OS repository as shown in the \nGet Started tutorial for Blinky\n\n\nFetch External Packages for Atmel SAMD21\n\n\nMynewt uses source code provided directly fr
om the chip manufacturer for \nlow level operations. This code is licensed only for Atmel parts, and \ncannot live in the Apache Mynewt repository. Fetch the package from \nthe runtime github repository\n\n\nnewt app add-pkg-list mynewt_arduino https://github.com/runtimeinc/mynewt_arduino_zero.git\n\n\n\n\nOnce that completes, install the arduino_zero bsp package.\n\n\nnewt pkg install hw/bsp/arduino_zero\n\n\n\n\nCreate your bootloader Target\n\n\nYou need to tell Newt what you want to build. This is done by setting up a \ntarget. It's easy - simply cut and paste the entire definition below. You may have already seen how to set up a target definition one attribute (variable) at a time or by importing the entire definition in one command in this \n\nExample\n or in the \nManual\n.\n\n\nnewt target import arduino_zero_bootloader\n@target=arduino_zero_bootloader\nname=arduino_zero_bootloader\nproject=boot\nbsp=hw/bsp/arduino_zero\ncompiler=arm-none-eabi-m0\nvers=0.0.1\narch=cortex_m
0\ncompiler_def=optimized\n@endtargets\n\n\n\n\nIf your console blocks, you may need to do a \nctrl-D\n to complete \nthe import.\n\n\nCreate Your Image Target\n\n\nYou need to tell Newt what you want to build. This is done by setting up a \ntarget. You may have already seen this target definition in this \n\nExample\n\n\nFor simplicity, you can just import this target. Just cut and paste\nthis into your Linux or MAC terminal from the larva directory.\n\n\nnewt target import arduino_zero_blinky \n@target=arduino_zero_blinky \nvers=0.0.1 \narch=cortex_m0 \ncompiler_def=debug \nname=arduino_zero_blinky \nbsp=hw/bsp/arduino_zero \ncompiler=arm-none-eabi-m0 \nproject=blinky \n@endtargets\n\n\n\n\nIf your console blocks, you may need to do a \nctrl-D\n to complete \nthe import.\n\n\nVerify Your Targets\n\n\nDepending on your shell you may need to do a \nCtrl-D\n to terminate the import\noperation. \n\n\nYou can do a \nnewt target show\n to see your results.\n\n\narduino_zero_blinky\n
arch=cortex_m0\n bsp=hw/bsp/arduino_zero\n compiler=arm-none-eabi-m0\n compiler_def=debug\n name=arduino_zero_blinky\n project=blinky\n vers=0.0.1\narduino_zero_bootloader\n arch=cortex_m0\n bsp=hw/bsp/arduino_zero\n compiler=arm-none-eabi-m0\n compiler_def=optimized\n name=arduino_zero_bootloader\n project=boot\n vers=0.0.1\n\n\n\n\nBuild the Bootloader\n\n\nTo Build the bootloader, use newt to do:\n\n\nnewt target build arduino_zero_bootloader\n\n\n\n\nYou should see lots of console output while newt is resolving dependencies\nand compiling the source code. After a minute, it should complete with \nthe following text.\n\n\n. . .\nArchiving libarduino_zero.a\nCompiling boot.c\nBuilding project boot\nLinking boot.elf\nSuccessfully run!\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. Mynewt will\ndownload and debug th
e target through this port. You should see a little 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\nDownload the Bootloader\n\n\nExecute the command to download the bootloader. \n\n\nnewt target download arduino_zero_bootloader\n\n\n\n\nThe newt tool should respond with. Then 10-15 seconds later it will return a \nprompt indicating success.\n\n\nDownloading with .../arduino_zero_download.sh\n\n\n\n\nBuild the Target\n\n\nTo Build the target, use newt to do:\n\n\nnewt target build arduino_zero_blinky\n\n\n\n\nYou should see lots of console output while newt is resolving dependencies\nand compiling the source code. After a minute, it should complete with \nthe following text.\n\n\nArchiving libarduino_zero.a\nCompiling main.c\nBuilding project blinky\nLinking blinky.elf\nSuccessfully run!\n\n\
n\n\nBuild the Downloadable Image\n\n\nThis command attaches the image descriptor header with the specified version\nnumber and prepares the image for download.\n\n\nnewt target create-image arduino_zero_blinky 1.2.3\n\n\n\n\nDownload the Image\n\n\nExecute the command to download the image. \n\n\nnewt target download arduino_zero_blinky\n\n\n\n\nThe newt tool should respond with the following message. Then 10-15 seconds later it will return a prompt indicating success.\n\n\nDownloading with .../arduino_zero_download.sh\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"
},
{
@@ -242,7 +242,7 @@
},
{
"location": "/os/tutorials/arduino_zero/#prerequisites",
- "text": "Before tackling this tutorial, its best to read about Mynewt in the Introduction section of this documentation.",
+ "text": "Before tackling this tutorial, it's best to read about Mynewt in the Introduction section of this documentation.",
"title": "Prerequisites"
},
{
@@ -252,22 +252,22 @@
},
{
"location": "/os/tutorials/arduino_zero/#steps",
- "text": "Follow these simple steps and you be blinking in no time.",
+ "text": "Follow these simple steps and your board will be blinking in no time!",
"title": "Steps"
},
{
"location": "/os/tutorials/arduino_zero/#install-mynewt-and-newt",
- "text": "If you have not already done so, install Newt, Mynewt and other\nprerequisites as shown here",
+ "text": "If you have not already done so, install Newt as shown in the Newt install tutorial and cloned the Mynewt OS repository as shown in the Get Started tutorial for Blinky",
"title": "Install Mynewt and Newt"
},
{
"location": "/os/tutorials/arduino_zero/#fetch-external-packages-for-atmel-samd21",
- "text": "Mynewt uses source code provided directly from the chip manufacturer for \nlow level operations. This code is licensed only for Atmel parts, and \ncannot live in the Apache Mynewt repository. Fetch the package from \nthe runtime github repository newt app add-pkg-list mynewt_arduino https://github.com/runtimeinc/mynewt_arduino_zero.git Once that completes install the arduino_zero bsp package newt pkg install hw/bsp/arduino_zero",
+ "text": "Mynewt uses source code provided directly from the chip manufacturer for \nlow level operations. This code is licensed only for Atmel parts, and \ncannot live in the Apache Mynewt repository. Fetch the package from \nthe runtime github repository newt app add-pkg-list mynewt_arduino https://github.com/runtimeinc/mynewt_arduino_zero.git Once that completes, install the arduino_zero bsp package. newt pkg install hw/bsp/arduino_zero",
"title": "Fetch External Packages for Atmel SAMD21"
},
{
"location": "/os/tutorials/arduino_zero/#create-your-bootloader-target",
- "text": "You need to tell Newt what you want to build. This is done by setting up a \ntarget. You may have already seen this target definition in this Example newt target import arduino_zero_bootloader\n@target=arduino_zero_bootloader\nname=arduino_zero_bootloader\nproject=boot\nbsp=hw/bsp/arduino_zero\ncompiler=arm-none-eabi-m0\nvers=0.0.1\narch=cortex_m0\ncompiler_def=optimized\n@endtargets If your console blocks, you may need to do a ctrl-D to complete \nthe import.",
+ "text": "You need to tell Newt what you want to build. This is done by setting up a \ntarget. It's easy - simply cut and paste the entire definition below. You may have already seen how to set up a target definition one attribute (variable) at a time or by importing the entire definition in one command in this Example or in the Manual . newt target import arduino_zero_bootloader\n@target=arduino_zero_bootloader\nname=arduino_zero_bootloader\nproject=boot\nbsp=hw/bsp/arduino_zero\ncompiler=arm-none-eabi-m0\nvers=0.0.1\narch=cortex_m0\ncompiler_def=optimized\n@endtargets If your console blocks, you may need to do a ctrl-D to complete \nthe import.",
"title": "Create your bootloader Target"
},
{
@@ -287,7 +287,7 @@
},
{
"location": "/os/tutorials/arduino_zero/#connect-the-target",
- "text": "Connect your computer to the Arduino Zero (from now on we'll call this the \ntarget) with the Micro-USB cable through the Programming Port. Mynewt will\ndownload and debug the target through this port. No external debugger is required. The Arduino Zero comes with an internal\ndebugger that can be accessed by Mynewt. A image below shows the Arduino Zero Programming Port.",
+ "text": "Connect your computer to the Arduino Zero (from now on we'll call this the \ntarget) with the Micro-USB cable through the Programming Port. Mynewt will\ndownload and debug the target through this port. You should see a little green LED come on. That means the board has power. No external debugger is required. The Arduino Zero comes with an internal\ndebugger that can be accessed by Mynewt. A image below shows the Arduino Zero Programming Port.",
"title": "Connect the Target"
},
{
@@ -302,17 +302,17 @@
},
{
"location": "/os/tutorials/arduino_zero/#build-the-downloadable-image",
- "text": "This command attaches the image descriptor header with the specicifed version\nnumber and prepares the image for download. newt target create-image arduino_zero_blinky 1.2.3",
+ "text": "This command attaches the image descriptor header with the specified version\nnumber and prepares the image for download. newt target create-image arduino_zero_blinky 1.2.3",
"title": "Build the Downloadable Image"
},
{
"location": "/os/tutorials/arduino_zero/#download-the-image",
- "text": "Execute the command to download the image. newt target download arduino_zero_blinky The newt tool should respond with. Then 10-15 seconds later it will return a \nprompt indicating success. Downloading with .../arduino_zero_download.sh",
+ "text": "Execute the command to download the image. newt target download arduino_zero_blinky The newt tool should respond with the following message. Then 10-15 seconds later it will return a prompt indicating success. Downloading with .../arduino_zero_download.sh",
"title": "Download the Image"
},
{
"location": "/os/tutorials/arduino_zero/#watch-the-led-blink",
- "text": "Congratulations!. You have create a Mynewt operating system running on the \nArduino Zero. The LED is toggled by one task running on the Mynewt OS.",
+ "text": "Congratulations! 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": "Watch the LED blink"
},
{
@@ -1692,7 +1692,7 @@
},
{
"location": "/os/core_os/mbuf/mbuf/",
- "text": "Mbufs\n\n\nThe mbuf (short for memory buffer) is a common concept in networking stacks. The mbuf is used to hold packet data as it traverses the stack. The mbuf also generally stores header information or other networking stack information that is carried around with the packet. The mbuf and its associated library of functions were developed to make common networking stack operations (like stripping and adding protocol headers) efficient and as copy-free as possible.\n\n\nIn its simplest form, an mbuf is a memory block with some space reserved for internal information and a pointer which is used to \"chain\" memory blocks together in order to create a \"packet\". This is a very important aspect of the mbuf: the ability to chain mbufs together to create larger \"packets\" (chains of mbufs).\n\n\nWhy use mbufs?\n\n\nThe main reason is to conserve memory. Consider a networking protocol that generally sends small packets but occasionally sends large ones. The Blueto
oth Low Energy (BLE) protocol is one such example. A flat buffer would need to be sized so that the maximum packet size could be contained by the buffer. With the mbuf, a number of mbufs can be chained together so that the occasional large packet can be handled while leaving more packet buffers available to the networking stack for smaller packets.\n\n\nPacket Header mbuf\n\n\nNot all mbufs are created equal. The first mbuf in a chain of mbufs is a special mbuf called a \"packet header mbuf\". The reason that this mbuf is special is that it contains the length of all the data contained by the chain of mbufs (the packet length, in other words). The packet header mbuf may also contain a user defined structure (called a \"user header\") so that networking protocol specific information can be conveyed to various layers of the networking stack. Any mbufs that are part of the packet (i.e. in the mbuf chain but not the first one) are \"normal\" (i.e. non-packet header) mbufs. A normal mbuf
does not have any packet header or user packet header structures in them; they only contain the basic mbuf header (\nstruct os_mbuf\n). Figure 1 illustrates these two types of mbufs. Note that the numbers/text in parentheses denote the size of the structures/elements (in bytes) and that MBLEN is the memory block length of the memory pool used by the mbuf pool.\n\n\n\n\nNormal mbuf\n\n\nNow let's take a deeper dive into the mbuf structure. Figure 2 illustrates a normal mbuf and breaks out the various fields in the \nos_mbuf\n structure. \n\n\n\n\nThe \nom_data\n field is a pointer to where the data starts inside the data buffer. Typically, mbufs that are allocated from the mbuf pool (discussed later) have their om_data pointer set to the start of the data buffer but there are cases where this may not be desirable (added a protocol header to a packet, for example). \n\n\nThe \nom_flags\n field is a set of flags used internally by the mbuf library. Currently, no flags have been define
d. \n\n\nThe \nom_pkthdr_len\n field is the total length of all packet headers in the mbuf. For normal mbufs this is set to 0 as there is no packet or user packet headers. For packet header mbufs, this would be set to the length of the packet header structure (16) plus the size of the user packet header (if any). Note that it is this field which differentiates packet header mbufs from normal mbufs (i.e. if \nom_pkthdr_len\n is zero, this is a normal mbuf; otherwise it is a packet header mbuf). \n\n\nThe \nom_len\n field contains the amount of user data in the data buffer. When initially allocated, this field is 0 as there is no user data in the mbuf. \n\n\nThe \nomp_pool\n field is a pointer to the pool from which this mbuf has been allocated. This is used internally by the mbuf library. \n\n\nThe \nomp_next\n field is a linked list element which is used to chain mbufs.\n\n\n\n\nFigure 2 also shows a normal mbuf with actual values in the \nos_mbuf\n structure. This mbuf starts at ad
dress 0x1000 and is 256 bytes in total length. In this example, the user has copied 33 bytes into the data buffer starting at address 0x1010 (this is where om_data points). Note that the packet header length in this mbuf is 0 as it is not a packet header mbuf.\n\n\n\n\nFigure 3 illustrates the packet header mbuf along with some chained mbufs (i.e a \"packet\"). In this example, the user header structure is defined to be 8 bytes. Note that in figure 3 we show a number of different mbufs with varying \nom_data\n pointers and lengths since we want to show various examples of valid mbufs. For all the mbufs (both packet header and normal ones) the total length of the memory block is 128 bytes.\n\n\n\n\nMbuf pools\n\n\nMbufs are collected into \"mbuf pools\" much like memory blocks. The mbuf pool itself contains a pointer to a memory pool. The memory blocks in this memory pool are the actual mbufs; both normal and packet header mbufs. Thus, the memory block (and corresponding memory pool)
must be sized correctly. In other words, the memory blocks which make up the memory pool used by the mbuf pool must be at least: sizeof(struct os_mbuf) + sizeof(struct os_mbuf_pkthdr) + sizeof(struct user_defined_header) + desired minimum data buffer length. For example, if the developer wants mbufs to contain at least 64 bytes of user data and they have a user header of 12 bytes, the size of the memory block would be (at least): 64 + 12 + 16 + 8, or 100 bytes. Yes, this is a fair amount of overhead. However, the flexibility provided by the mbuf library usually outweighs overhead concerns.\n\n\nCreate mbuf pool\n\n\nCreating an mbuf pool is fairly simple: create a memory pool and then create the mbuf pool using that memory pool. Once the developer has determined the size of the user data needed per mbuf (this is based on the application/networking stack and is outside the scope of this discussion) and the size of the user header (if any), the memory blocks can be sized. In the exam
ple shown below, the application requires 64 bytes of user data per mbuf and also allocates a user header (called struct user_hdr). Note that we do not show the user header data structure as there really is no need; all we need to do is to account for it when creating the memory pool. In the example, we use the macro \nMBUF_PKTHDR_OVERHEAD\n to denote the amount of packet header overhead per mbuf and \nMBUF_MEMBLOCK_OVERHEAD\n to denote the total amount of overhead required per memory block. The macro \nMBUF_BUF_SIZE\n is used to denote the amount of payload that the application requires (aligned on a 32-bit boundary in this case). All this leads to the total memory block size required, denoted by the macro \nMBUF_MEMBLOCK_OVERHEAD\n.\n\n\n\n#define MBUF_PKTHDR_OVERHEAD sizeof(struct os_mbuf_pkthdr) + sizeof(struct user_hdr)\n#define MBUF_MEMBLOCK_OVERHEAD sizeof(struct os_mbuf) + MBUF_PKTHDR_OVERHEAD\n\n#define MBUF_NUM_MBUFS (32)\n#define MBUF_PAYLOAD_SIZE (64)\n#define
MBUF_BUF_SIZE OS_ALIGN(MBUF_PAYLOAD_SIZE, 4)\n#define MBUF_MEMBLOCK_SIZE (MBUF_BUF_SIZE + MBUF_MEMBLOCK_OVERHEAD)\n#define MBUF_MEMPOOL_SIZE OS_MEMPOOL_SIZE(MBUF_NUM_MBUFS, MBUF_MEMBLOCK_SIZE)\n\nstruct os_mbuf_pool g_mbuf_pool; \nstruct os_mempool g_mbuf_mempool;\nos_membuf_t g_mbuf_buffer[MBUF_MEMPOOL_SIZE];\n\nvoid\ncreate_mbuf_pool(void)\n{\n int rc;\n\n rc = os_mempool_init(\ng_mbuf_mempool, MBUF_NUM_MBUFS, \n MBUF_MEMBLOCK_SIZE, \ng_mbuf_buffer[0], \nmbuf_pool\n);\n assert(rc == 0);\n\n rc = os_mbuf_pool_init(\ng_mbuf_pool, \ng_mbuf_mempool, MBUF_MEMBLOCK_SIZE, \n MBUF_NUM_MBUFS);\n assert(rc == 0);\n}\n\n\n\n\n\nUsing mbufs\n\n\nThe following examples illustrate typical mbuf usage. There are two basic mbuf allocation API: \nos_mbuf_get()\n and \nos_mbuf_get_pkthdr()\n. The first API obtains a normal mbuf whereas the latter obtains a packet header mbuf. Typically, application developers use \nos_mbuf_g
et_pkthdr()\n and rarely, if ever, need to call \nos_mbuf_get()\n as the rest of the mbuf API (e.g. \nos_mbuf_append()\n, \nos_mbuf_copyinto()\n, etc.) typically deal with allocating and chaining mbufs. It is recommended to use the provided API to copy data into/out of mbuf chains and/or manipulate mbufs.\n\n\nIn \nexample1\n, the developer creates a packet and then sends the packet to a networking interface. The code sample also provides an example of copying data out of an mbuf as well as use of the \"pullup\" api (another very common mbuf api).\n\n\n\nvoid\nmbuf_usage_example1(uint8_t *mydata, int mydata_length)\n{\n int rc;\n struct os_mbuf *om;\n\n /* get a packet header mbuf */\n om = os_mbuf_get_pkthdr(\ng_mbuf_pool, sizeof(struct user_hdr));\n if (om) {\n /* \n * Copy user data into mbuf. NOTE: if mydata_length is greater than the\n * mbuf payload size (64 bytes using above example), mbufs are allocated\n * and chained together t
o accommodate the total packet length.\n */\n rc = os_mbuf_copyinto(om, 0, mydata, len);\n if (rc) {\n /* Error! Could not allocate enough mbufs for total packet length */\n return -1;\n }\n\n /* Send packet to networking interface */\n send_pkt(om);\n }\n}\n\n\n\n\nIn \nexample2\n we show use of the pullup api as this illustrates some of the typical pitfalls developers encounter when using mbufs. The first pitfall is one of alignment/padding. Depending on the processor and/or compiler, the sizeof() a structure may vary. Thus, the size of \nmy_protocol_header\n may be different inside the packet data of the mbuf than the size of the structure on the stack or as a global variable, for instance. While some networking protcols may align protocol information on convenient processor boundaries many others try to conserve bytes \"on the air\" (i.e inside the packet data). Typical methods used to deal with this are \"packi
ng\" the structure (i.e. force compiler to not pad) or creating protocol headers that do not require padding. \nexample2\n assumes that one of these methods was used when defining the \nmy_protocol_header\n structure.\n\n\nAnother common pitfall occurs around endianness. A network protocol may be little endian or big endian; it all depends on the protocol specification. Processors also have an endianness; this means that the developer has to be careful that the processor endianness and the protocol endianness are handled correctly. In \nexample2\n, some common networking functions are used: \nntohs()\n and \nntohl()\n. These are shorthand for \"network order to host order, short\" and \"network order to host order, long\". Basically, these functions convert data of a certain size (i.e. 16 bits, 32 bits, etc) to the endianness of the host. Network byte order is big-endian (most significant byte first), so these functions convert big-endian byte order to host order (thus, the implemen
tation of these functions is host dependent). Note that the BLE networking stack \"on the air\" format is least signigicant byte first (i.e. little endian), so a \"bletoh\" function would have to take little endian format and convert to host format.\n\n\nA long story short: the developer must take care when copying structure data to/from mbufs and flat buffers!\n\n\nA final note: these examples assume the same mbuf struture and definitions used in the first example. \n\n\nvoid\nmbuf_usage_example2(struct mbuf *rxpkt)\n{\n int rc;\n uint8_t packet_data[16];\n struct mbuf *om;\n struct my_protocol_header *phdr;\n\n /* Make sure that \nmy_protocol_header\n bytes are contiguous in mbuf */\n om = os_mbuf_pullup(\ng_mbuf_pool, sizeof(struct my_protocol_header));\n if (!om) {\n /* Not able to pull up data into contiguous area */\n return -1;\n }\n\n /* \n * Get the protocol in
<TRUNCATED>