| <!-- |
| Documentation/_templates/layout.html |
| |
| Licensed to the Apache Software Foundation (ASF) under one or more |
| contributor license agreements. See the NOTICE file distributed with |
| this work for additional information regarding copyright ownership. The |
| ASF licenses this file to you under the Apache License, Version 2.0 (the |
| "License"); you may not use this file except in compliance with the |
| License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, WITHOUT |
| WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the |
| License for the specific language governing permissions and limitations |
| under the License. |
| --> |
| |
| |
| |
| <!DOCTYPE html> |
| <html class="writer-html5" lang="en"> |
| <head> |
| <meta charset="utf-8" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" /> |
| |
| <meta name="viewport" content="width=device-width, initial-scale=1.0" /> |
| <title>Resources — NuttX latest documentation</title> |
| <link rel="stylesheet" type="text/css" href="../_static/pygments.css" /> |
| <link rel="stylesheet" type="text/css" href="../_static/css/theme.css" /> |
| <link rel="stylesheet" type="text/css" href="../_static/copybutton.css" /> |
| <link rel="stylesheet" type="text/css" href="../_static/custom.css" /> |
| |
| |
| <link rel="shortcut icon" href="../_static/favicon.ico"/> |
| <script src="../_static/jquery.js"></script> |
| <script src="../_static/_sphinx_javascript_frameworks_compat.js"></script> |
| <script data-url_root="../" id="documentation_options" src="../_static/documentation_options.js"></script> |
| <script src="../_static/doctools.js"></script> |
| <script src="../_static/sphinx_highlight.js"></script> |
| <script src="../_static/clipboard.min.js"></script> |
| <script src="../_static/copybutton.js"></script> |
| <script src="../_static/js/theme.js"></script> |
| <link rel="index" title="Index" href="../genindex.html" /> |
| <link rel="search" title="Search" href="../search.html" /> |
| <link rel="next" title="Getting Started" href="../quickstart/index.html" /> |
| <link rel="prev" title="Trademarks" href="trademarks.html" /> |
| </head> |
| |
| <body class="wy-body-for-nav"> |
| <div class="wy-grid-for-nav"> |
| <nav data-toggle="wy-nav-shift" class="wy-nav-side"> |
| <div class="wy-side-scroll"> |
| <div class="wy-side-nav-search" > |
| |
| <a href="../index.html" class="icon icon-home"> NuttX |
| |
| |
| |
| </a> |
| |
| <!-- this version selector is quite ugly, should be probably replaced by something |
| more modern --> |
| |
| <div class="version-selector"> |
| <select onchange="javascript:location.href = this.value;"> |
| |
| <option value="../../latest" selected="selected">latest</option> |
| |
| <option value="../../10.0.0" >10.0.0</option> |
| |
| <option value="../../10.0.1" >10.0.1</option> |
| |
| <option value="../../10.1.0" >10.1.0</option> |
| |
| <option value="../../10.2.0" >10.2.0</option> |
| |
| <option value="../../10.3.0" >10.3.0</option> |
| |
| <option value="../../11.0.0" >11.0.0</option> |
| |
| <option value="../../12.0.0" >12.0.0</option> |
| |
| <option value="../../12.1.0" >12.1.0</option> |
| |
| <option value="../../12.2.0" >12.2.0</option> |
| |
| <option value="../../12.2.1" >12.2.1</option> |
| |
| <option value="../../12.3.0" >12.3.0</option> |
| |
| <option value="../../12.4.0" >12.4.0</option> |
| |
| <option value="../../12.5.0" >12.5.0</option> |
| |
| <option value="../../12.5.1" >12.5.1</option> |
| |
| <option value="../../12.6.0" >12.6.0</option> |
| |
| <option value="../../12.7.0" >12.7.0</option> |
| |
| <option value="../../12.8.0" >12.8.0</option> |
| |
| <option value="../../12.9.0" >12.9.0</option> |
| |
| <option value="../../12.10.0" >12.10.0</option> |
| |
| <option value="../../12.11.0" >12.11.0</option> |
| |
| </select> |
| </div> |
| |
| |
| <div role="search"> |
| <form id="rtd-search-form" class="wy-form" action="../search.html" method="get"> |
| <input type="text" name="q" placeholder="Search docs" aria-label="Search docs" /> |
| <input type="hidden" name="check_keywords" value="yes" /> |
| <input type="hidden" name="area" value="default" /> |
| </form> |
| </div> |
| |
| </div><div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="Navigation menu"> |
| <p class="caption" role="heading"><span class="caption-text">Table of Contents</span></p> |
| <ul class="current"> |
| <li class="toctree-l1"><a class="reference internal" href="../index.html">Home</a></li> |
| <li class="toctree-l1 current"><a class="reference internal" href="index.html">Introduction</a><ul class="current"> |
| <li class="toctree-l2"><a class="reference internal" href="about.html">About Apache NuttX</a></li> |
| <li class="toctree-l2"><a class="reference internal" href="development_environments.html">Development Environments</a></li> |
| <li class="toctree-l2"><a class="reference internal" href="licensing.html">Licensing</a></li> |
| <li class="toctree-l2"><a class="reference internal" href="trademarks.html">Trademarks</a></li> |
| <li class="toctree-l2 current"><a class="current reference internal" href="#">Resources</a><ul> |
| <li class="toctree-l3"><a class="reference internal" href="#legacy-readme">Legacy README</a><ul> |
| <li class="toctree-l4"><a class="reference internal" href="#apache-nuttx">APACHE NUTTX</a></li> |
| <li class="toctree-l4"><a class="reference internal" href="#introduction">INTRODUCTION</a></li> |
| <li class="toctree-l4"><a class="reference internal" href="#community">COMMUNITY</a><ul> |
| <li class="toctree-l5"><a class="reference internal" href="#getting-help">Getting Help</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#mailing-lists">Mailing Lists</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#reporting-security-issues">Reporting Security Issues</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#issue-tracker">Issue Tracker</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#source-code">Source Code</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#website-source-code">Website Source Code</a></li> |
| </ul> |
| </li> |
| <li class="toctree-l4"><a class="reference internal" href="#environments">ENVIRONMENTS</a><ul> |
| <li class="toctree-l5"><a class="reference internal" href="#installing-cygwin">Installing Cygwin</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#using-msys">Using MSYS</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#ubuntu-bash-under-windows-10">Ubuntu Bash under Windows 10</a></li> |
| </ul> |
| </li> |
| <li class="toctree-l4"><a class="reference internal" href="#installation">INSTALLATION</a><ul> |
| <li class="toctree-l5"><a class="reference internal" href="#download-and-unpack">Download and Unpack</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#semi-optional-apps-package">Semi-Optional apps/ Package</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#installation-directories-with-spaces-in-the-path">Installation Directories with Spaces in the Path</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#downloading-from-repositories">Downloading from Repositories</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#related-repositories">Related Repositories</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#notes-about-header-files">Notes about Header Files</a></li> |
| </ul> |
| </li> |
| <li class="toctree-l4"><a class="reference internal" href="#configuring-nuttx">CONFIGURING NUTTX</a><ul> |
| <li class="toctree-l5"><a class="reference internal" href="#instantiating-canned-configurations">Instantiating “Canned” Configurations</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#refreshing-configurations">Refreshing Configurations</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#nuttx-configuration-tool">NuttX Configuration Tool</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#finding-selections-in-the-configuration-menus">Finding Selections in the Configuration Menus</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#reveal-hidden-configuration-options">Reveal Hidden Configuration Options</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#make-sure-that-you-are-on-the-right-platform">Make Sure that You are on the Right Platform</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#comparing-two-configurations">Comparing Two Configurations</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#making-defconfig-files">Making <code class="docutils literal notranslate"><span class="pre">defconfig</span></code> Files</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#incompatibilities-with-older-configurations">Incompatibilities with Older Configurations</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#nuttx-configuration-tool-under-dos">NuttX Configuration Tool under DOS</a></li> |
| </ul> |
| </li> |
| <li class="toctree-l4"><a class="reference internal" href="#toolchains">TOOLCHAINS</a><ul> |
| <li class="toctree-l5"><a class="reference internal" href="#cross-development-toolchains">Cross-Development Toolchains</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#nuttx-buildroot-toolchain">NuttX Buildroot Toolchain</a></li> |
| </ul> |
| </li> |
| <li class="toctree-l4"><a class="reference internal" href="#shells">SHELLS</a></li> |
| <li class="toctree-l4"><a class="reference internal" href="#building-nuttx">BUILDING NUTTX</a><ul> |
| <li class="toctree-l5"><a class="reference internal" href="#building">Building</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#re-building">Re-building</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#build-targets-and-options">Build Targets and Options</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#native-windows-build">Native Windows Build</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#installing-gnuwin32">Installing GNUWin32</a></li> |
| </ul> |
| </li> |
| <li class="toctree-l4"><a class="reference internal" href="#cygwin-build-problems">CYGWIN BUILD PROBLEMS</a><ul> |
| <li class="toctree-l5"><a class="reference internal" href="#performance">Performance</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#strange-path-problems">Strange Path Problems</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#window-native-toolchain-issues">Window Native Toolchain Issues</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#general-pre-built-toolchain-issues">General Pre-built Toolchain Issues</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#building-original-linux-boards-in-cygwin">Building Original Linux Boards in Cygwin</a></li> |
| <li class="toctree-l5"><a class="reference internal" href="#recovering-from-bad-configurations">Recovering from Bad Configurations</a></li> |
| </ul> |
| </li> |
| <li class="toctree-l4"><a class="reference internal" href="#documentation">DOCUMENTATION</a></li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| </ul> |
| </li> |
| <li class="toctree-l1"><a class="reference internal" href="../quickstart/index.html">Getting Started</a></li> |
| <li class="toctree-l1"><a class="reference internal" href="../contributing/index.html">Contributing</a></li> |
| <li class="toctree-l1"><a class="reference internal" href="inviolables.html">The Inviolable Principles of NuttX</a></li> |
| <li class="toctree-l1"><a class="reference internal" href="../platforms/index.html">Supported Platforms</a></li> |
| <li class="toctree-l1"><a class="reference internal" href="../components/index.html">OS Components</a></li> |
| <li class="toctree-l1"><a class="reference internal" href="../applications/index.html">Applications</a></li> |
| <li class="toctree-l1"><a class="reference internal" href="../implementation/index.html">Implementation Details</a></li> |
| <li class="toctree-l1"><a class="reference internal" href="../reference/index.html">API Reference</a></li> |
| <li class="toctree-l1"><a class="reference internal" href="../faq/index.html">FAQ</a></li> |
| <li class="toctree-l1"><a class="reference internal" href="../guides/index.html">Guides</a></li> |
| <li class="toctree-l1"><a class="reference internal" href="../glossary.html">Glossary</a></li> |
| <li class="toctree-l1"><a class="reference internal" href="../logos/index.html">NuttX Logos</a></li> |
| </ul> |
| |
| </div> |
| </div> |
| </nav> |
| |
| <section data-toggle="wy-nav-shift" class="wy-nav-content-wrap"><nav class="wy-nav-top" aria-label="Mobile navigation menu" > |
| <i data-toggle="wy-nav-top" class="fa fa-bars"></i> |
| <a href="../index.html">NuttX</a> |
| </nav> |
| |
| <div class="wy-nav-content"> |
| <div class="rst-content"> |
| <div role="navigation" aria-label="Page navigation"> |
| <ul class="wy-breadcrumbs"> |
| <li><a href="../index.html" class="icon icon-home" aria-label="Home"></a></li> |
| <li class="breadcrumb-item"><a href="index.html">Introduction</a></li> |
| <li class="breadcrumb-item active">Resources</li> |
| <li class="wy-breadcrumbs-aside"> |
| <a href="../_sources/introduction/resources.rst.txt" rel="nofollow"> View page source</a> |
| </li> |
| </ul> |
| <hr/> |
| </div> |
| <div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article"> |
| <div itemprop="articleBody"> |
| |
| <section id="resources"> |
| <h1>Resources<a class="headerlink" href="#resources" title="Permalink to this heading"></a></h1> |
| <div class="admonition note"> |
| <p class="admonition-title">Note</p> |
| <p>this should be revised</p> |
| </div> |
| <p>Here’s a list of Apache NuttX resources that you might find helpful:</p> |
| <blockquote> |
| <div><ul class="simple"> |
| <li><p>Apache NuttX</p> |
| <ul> |
| <li><p><a class="reference external" href="https://nuttx.apache.org">Apache NuttX website</a></p></li> |
| <li><p><a class="reference external" href="https://cwiki.apache.org/confluence/display/NUTTX/Nuttx">Apache NuttX online documentation</a></p></li> |
| <li><p><a class="reference external" href="https://nuttx.apache.org/community/">Apache NuttX mailing list</a> – a very active mailing list, the place to get help with your application or any questions you have about NuttX.</p></li> |
| <li><p><a class="reference external" href="https://www.youtube.com/channel/UC0QciIlcUnjJkL5yJJBmluw/videos">Apache NuttX YouTube channel</a> – Alan Carvalho de Assis’s YouTube channel on NuttX. It’s a source of a lot of great practical information.</p></li> |
| <li><p><a class="reference external" href="https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard">Apache NuttX Coding Standard</a> — How code should look when you submit new files or modify existing ones.</p></li> |
| <li><p><a class="reference external" href="https://cwiki.apache.org/confluence/display/NUTTX/Code+Contribution+Workflow">Apache NuttX Code Contribution Guidelines</a> — The full workflow to follow for submitting code with all the details.</p></li> |
| </ul> |
| </li> |
| <li><p>Git</p> |
| <ul> |
| <li><p><a class="reference external" href="https://github.github.com/training-kit/downloads/github-git-cheat-sheet.pdf">Git Cheat Sheet (by GitHub)</a></p></li> |
| <li><p><a class="reference external" href="https://git-scm.com/book/en/v2">Git Book (online)</a></p></li> |
| </ul> |
| </li> |
| </ul> |
| </div></blockquote> |
| <section id="legacy-readme"> |
| <h2>Legacy README<a class="headerlink" href="#legacy-readme" title="Permalink to this heading"></a></h2> |
| <section id="apache-nuttx"> |
| <h3>APACHE NUTTX<a class="headerlink" href="#apache-nuttx" title="Permalink to this heading"></a></h3> |
| <ul class="simple"> |
| <li><p>Introduction</p></li> |
| <li><p>Community</p> |
| <ul> |
| <li><p>Getting Help</p></li> |
| <li><p>Mailing Lists</p></li> |
| <li><p>Issue Tracker</p></li> |
| <li><p>Source Code</p></li> |
| <li><p>Website Source Code</p></li> |
| </ul> |
| </li> |
| <li><p>Environments</p> |
| <ul> |
| <li><p>Installing Cygwin</p></li> |
| <li><p>Ubuntu Bash under Windows 10</p></li> |
| <li><p>Using macOS</p></li> |
| </ul> |
| </li> |
| <li><p>Installation</p> |
| <ul> |
| <li><p>Download and Unpack</p></li> |
| <li><p>Semi-Optional apps/ Package</p></li> |
| <li><p>Installation Directories with Spaces in the Path</p></li> |
| <li><p>Downloading from Repositories</p></li> |
| <li><p>Related Repositories</p></li> |
| <li><p>Notes about Header Files</p></li> |
| </ul> |
| </li> |
| <li><p>Configuring NuttX</p> |
| <ul> |
| <li><p>Instantiating “Canned” Configurations</p></li> |
| <li><p>Refreshing Configurations</p></li> |
| <li><p>NuttX Configuration Tool</p></li> |
| <li><p>Finding Selections in the Configuration Menus</p></li> |
| <li><p>Reveal Hidden Configuration Options</p></li> |
| <li><p>Make Sure that You are on the Right Platform</p></li> |
| <li><p>Comparing Two Configurations</p></li> |
| <li><p>Making defconfig Files</p></li> |
| <li><p>Incompatibilities with Older Configurations</p></li> |
| <li><p>NuttX Configuration Tool under DOS</p></li> |
| </ul> |
| </li> |
| <li><p>Toolchains</p> |
| <ul> |
| <li><p>Cross-Development Toolchains</p></li> |
| <li><p>NuttX Buildroot Toolchain</p></li> |
| </ul> |
| </li> |
| <li><p>Shells</p></li> |
| <li><p>Building NuttX</p> |
| <ul> |
| <li><p>Building</p></li> |
| <li><p>Re-building</p></li> |
| <li><p>Build Targets and Options</p></li> |
| <li><p>Native Windows Build</p></li> |
| <li><p>Installing GNUWin32</p></li> |
| </ul> |
| </li> |
| <li><p>Cygwin Build Problems</p> |
| <ul> |
| <li><p>Strange Path Problems</p></li> |
| <li><p>Window Native Toolchain Issues</p></li> |
| </ul> |
| </li> |
| <li><p>Documentation</p></li> |
| </ul> |
| </section> |
| <section id="introduction"> |
| <h3>INTRODUCTION<a class="headerlink" href="#introduction" title="Permalink to this heading"></a></h3> |
| <p>Apache NuttX is a real-time operating system (RTOS) with an emphasis on |
| standards compliance and small footprint. Scalable from 8-bit to 64-bit |
| microcontroller environments, the primary governing standards in NuttX are |
| POSIX and ANSI standards. Additional standard APIs from Unix and other |
| common RTOSs (such as VxWorks) are adopted for functionality not available |
| under these standards, or for functionality that is not appropriate for |
| deeply-embedded environments (such as fork()).</p> |
| <p>Extensive documentation can be found on the project wiki: |
| <a class="reference external" href="https://cwiki.apache.org/NUTTX/NuttX">https://cwiki.apache.org/NUTTX/NuttX</a></p> |
| <p>For brevity, many parts of the documentation will refer to Apache NuttX as |
| simply NuttX.</p> |
| </section> |
| <section id="community"> |
| <h3>COMMUNITY<a class="headerlink" href="#community" title="Permalink to this heading"></a></h3> |
| <p>Every volunteer project obtains its strength from the people involved in |
| it. We invite you to participate as much or as little as you choose.</p> |
| <p>We encourage you to:</p> |
| <ul class="simple"> |
| <li><p>Use our project and provide feedback.</p></li> |
| <li><p>Provide us with use-cases.</p></li> |
| <li><p>Report bugs and submit patches.</p></li> |
| <li><p>Contribute code or documentation.</p></li> |
| </ul> |
| <section id="getting-help"> |
| <h4>Getting Help<a class="headerlink" href="#getting-help" title="Permalink to this heading"></a></h4> |
| <p>The best place to get help is the developer’s mailing list. Please see |
| the following section:</p> |
| </section> |
| <section id="mailing-lists"> |
| <h4>Mailing Lists<a class="headerlink" href="#mailing-lists" title="Permalink to this heading"></a></h4> |
| <p>Get help using NuttX or contribute to the project on our mailing lists:</p> |
| <ul class="simple"> |
| <li><p><a class="reference external" href="mailto:dev%40nuttx.apache.org">dev<span>@</span>nuttx<span>.</span>apache<span>.</span>org</a> is for people who want to contribute code to NuttX.</p> |
| <ul> |
| <li><p>To subscribe, send an email to <a class="reference external" href="mailto:dev-subscribe%40nuttx.apache.org">dev-subscribe<span>@</span>nuttx<span>.</span>apache<span>.</span>org</a>.</p></li> |
| <li><p>To unsubscribe, send an email to <a class="reference external" href="mailto:dev-unsubscribe%40nuttx.apache.org">dev-unsubscribe<span>@</span>nuttx<span>.</span>apache<span>.</span>org</a>.</p></li> |
| <li><p>View the archives at: |
| <a class="reference external" href="https://www.mail-archive.com/dev@nuttx.apache.org/">https://www.mail-archive.com/dev@nuttx.apache.org/</a></p></li> |
| </ul> |
| </li> |
| <li><p><a class="reference external" href="mailto:commits%40nuttx.apache.org">commits<span>@</span>nuttx<span>.</span>apache<span>.</span>org</a> is a read-only list that notifies subscribers |
| about commit messages and patches to NuttX.</p> |
| <ul> |
| <li><p>To subscribe, send an email to <a class="reference external" href="mailto:commits-subscribe%40nuttx.apache.org">commits-subscribe<span>@</span>nuttx<span>.</span>apache<span>.</span>org</a>.</p></li> |
| <li><p>To unsubscribe, send an email to <a class="reference external" href="mailto:commits-unsubscribe%40nuttx.apache.org">commits-unsubscribe<span>@</span>nuttx<span>.</span>apache<span>.</span>org</a>.</p></li> |
| <li><p>View the archives at: |
| <a class="reference external" href="https://www.mail-archive.com/commits@nuttx.apache.org/">https://www.mail-archive.com/commits@nuttx.apache.org/</a></p></li> |
| </ul> |
| </li> |
| </ul> |
| </section> |
| <section id="reporting-security-issues"> |
| <h4>Reporting Security Issues<a class="headerlink" href="#reporting-security-issues" title="Permalink to this heading"></a></h4> |
| <p>Found a vulnerability? See our security policy |
| <a class="reference external" href="https://github.com/apache/nuttx/blob/master/.github/SECURITY.md">here</a>.</p> |
| </section> |
| <section id="issue-tracker"> |
| <h4>Issue Tracker<a class="headerlink" href="#issue-tracker" title="Permalink to this heading"></a></h4> |
| <section id="bug-reports"> |
| <h5>Bug Reports:<a class="headerlink" href="#bug-reports" title="Permalink to this heading"></a></h5> |
| <p>Found bug? Send an email to the dev list: <a class="reference external" href="mailto:dev%40nuttx.apache.org">dev<span>@</span>nuttx<span>.</span>apache<span>.</span>org</a></p> |
| <p>Before submitting an issue, please:</p> |
| <ul class="simple"> |
| <li><p>Verify that the bug does in fact exist.</p></li> |
| <li><p>Search the mailing list archives to verify there is no existing issue |
| reporting the bug you’ve found.</p></li> |
| <li><p>Consider tracking down the bug yourself in the NuttX source code and |
| submitting a patch along with your bug report. This is a great time |
| saver for the NuttX developers and helps ensure the bug will be fixed |
| quickly.</p></li> |
| </ul> |
| </section> |
| <section id="feature-requests"> |
| <h5>Feature Requests:<a class="headerlink" href="#feature-requests" title="Permalink to this heading"></a></h5> |
| <p>Enhancement requests for new features are also welcome. The more concrete |
| and rational the request is, the greater the chance it will incorporated |
| into future releases.</p> |
| </section> |
| </section> |
| <section id="source-code"> |
| <h4>Source Code<a class="headerlink" href="#source-code" title="Permalink to this heading"></a></h4> |
| <p>The project sources are in two Git repositories. The core OS is in nuttx |
| and the apps repository is in nuttx-apps. These are housed in GitBox on |
| ASF servers and also mirrored at GitHub. These are kept in sync, so you |
| can use whichever option you prefer.</p> |
| <ul class="simple"> |
| <li><p>NuttX core OS repository:</p> |
| <ul> |
| <li><p>Primary: |
| <a class="reference external" href="https://gitbox.apache.org/repos/asf?p=nuttx.git">https://gitbox.apache.org/repos/asf?p=nuttx.git</a></p></li> |
| <li><p>GitHub Mirror: |
| <a class="reference external" href="https://github.com/apache/nuttx">https://github.com/apache/nuttx</a></p></li> |
| </ul> |
| </li> |
| <li><p>Apps repository:</p> |
| <ul> |
| <li><p>Primary: |
| <a class="reference external" href="https://gitbox.apache.org/repos/asf?p=nuttx-apps.git">https://gitbox.apache.org/repos/asf?p=nuttx-apps.git</a></p></li> |
| <li><p>GitHub Mirror: |
| <a class="reference external" href="https://github.com/apache/nuttx-apps">https://github.com/apache/nuttx-apps</a></p></li> |
| </ul> |
| </li> |
| </ul> |
| </section> |
| <section id="website-source-code"> |
| <h4>Website Source Code<a class="headerlink" href="#website-source-code" title="Permalink to this heading"></a></h4> |
| <p>The project website sources are accessible via the website source code |
| repository which is also mirrored in GitHub:</p> |
| <ul class="simple"> |
| <li><p>Primary: |
| <a class="reference external" href="https://gitbox.apache.org/repos/asf?p=nuttx-website.git">https://gitbox.apache.org/repos/asf?p=nuttx-website.git</a></p></li> |
| <li><p>GitHub Mirror: |
| <a class="reference external" href="https://github.com/apache/nuttx-website">https://github.com/apache/nuttx-website</a></p></li> |
| </ul> |
| </section> |
| </section> |
| <section id="environments"> |
| <h3>ENVIRONMENTS<a class="headerlink" href="#environments" title="Permalink to this heading"></a></h3> |
| <p>NuttX requires a POSIX development environment such as you would find under |
| Linux or macOS. NuttX may also be installed and built on Windows system |
| if you also provide such a POSIX development environment. Options for a |
| POSIX development environment under Windows include:</p> |
| <ul> |
| <li><p>An installation of Linux on a virtual machine (VM) in Windows. I have |
| not been happy using a VM myself. I have had stability problems with |
| open source VMs and commercial VMs cost more than I want to spend. |
| Sharing files with Linux running in a VM is awkward; sharing devices |
| connected to the Windows box with Linux in a VM is, at the very least, |
| confusing; Using Windows tools (such as Segger J-Link) with files |
| built under the Linux VM is not a possibility.</p></li> |
| <li><p>The Cygwin environment. Instructions for installation of Cygwin on a |
| Windows system are provided in the following paragraph, “Installing |
| Cygwin”. Cygwin is a mature, well-tested, and very convenient |
| environment. It is especially convenient if you need to |
| integrate with Windows tools and files. Downsides are that the |
| installation time is very long and the compile times are slow.</p></li> |
| <li><p>Ubuntu/Bash shell under Windows 10. This is a new option under |
| Windows 10. See the section “Ubuntu Bash under Windows 10” below. |
| This is an improvement over Cygwin if your concern is compile time; |
| its build performance is comparable to native Linux, certainly better |
| than the Cygwin build time. It also installs in a tiny fraction of |
| the time as Cygwin, perhaps 20 minutes for the basic Ubuntu install |
| (vs. more than a day for the complete Cygwin install).</p> |
| <p>There have been even more recent ports of Linux environment to |
| Windows. I need to update this section to include some mention of |
| these alternatives.</p> |
| </li> |
| <li><p>The MSYS environment. MSYS derives from an older version of Cygwin |
| simplified and adapted to work more naturally in the Windows |
| environment. See <a class="reference external" href="http://www.mingw.org/wiki/MSYS">http://www.mingw.org/wiki/MSYS</a> if you are |
| interested in using MSYS. The advantages of the MSYS environment is |
| that it is better integrted with the native Windows environment and |
| lighter weight; it uses only a minimal number of add-on POSIX-land |
| tools.</p> |
| <p>The download link in that Wiki takes you to the SourceForge download |
| site. The SourceForge MSYS project has been stagnant for some time. |
| The MSYS project has more recently moved to |
| <a class="reference external" href="http://odsn.net/projects/sfnet_mingwbundle">http://odsn.net/projects/sfnet_mingwbundle</a>. Downloads of current .zip |
| files are available there but no instructions for the installation.</p> |
| </li> |
| <li><p>MSYS2 appears to be a re-write of MSYS based on a newer version of |
| Cygwin. Is it available at <a class="reference external" href="https://www.msys2.org">https://www.msys2.org</a>. A windows |
| installer is available at that site along with very good installation |
| instructions. The download is relatively quick (at least compared to |
| Cygwin) and the ‘pacman’ package management tool supports supports |
| simple system updates. For example, ‘pacman -S git’ will install the |
| GIT command line utilities.</p></li> |
| <li><p>Other POSIX environments. Check out:</p> |
| <ul class="simple"> |
| <li><p>UnxUtils: <a class="reference external" href="https://sourceforge.net/projects/unxutils/">https://sourceforge.net/projects/unxutils/</a>, |
| <a class="reference external" href="https://en.wikipedia.org/wiki/UnxUtils">https://en.wikipedia.org/wiki/UnxUtils</a></p></li> |
| <li><p>MobaXterm: <a class="reference external" href="https://mobaxterm.mobatek.net/">https://mobaxterm.mobatek.net/</a></p></li> |
| <li><p>Gow: <a class="reference external" href="https://github.com/bmatzelle/gow/wiki">https://github.com/bmatzelle/gow/wiki</a></p></li> |
| </ul> |
| <p><strong>Disclaimer</strong>: In principle, these should work. However, I have never |
| used any of these environments and cannot guarantee that there is |
| not some less-than-obvious issues.</p> |
| </li> |
| </ul> |
| <p>NuttX can also be installed and built on a native Windows system, but with |
| some potential tool-related issues (see the discussion “Native Windows |
| Build” under “Building NuttX” below). GNUWin32 is used to provide |
| compatible native windows tools.</p> |
| <section id="installing-cygwin"> |
| <h4>Installing Cygwin<a class="headerlink" href="#installing-cygwin" title="Permalink to this heading"></a></h4> |
| <p>Installing Cygwin on your Windows PC is simple, but time consuming. See |
| <a class="reference external" href="http://www.cygwin.com/">http://www.cygwin.com/</a> for installation instructions. Basically you just |
| need to download a tiny setup.exe program and it does the real, network |
| installation for you.</p> |
| <p>Some Cygwin installation tips:</p> |
| <ol class="arabic simple"> |
| <li><p>Install at <code class="docutils literal notranslate"><span class="pre">C:\cygwin</span></code></p></li> |
| <li><p>Install <strong>everything</strong>: “Only the minimal base packages from the |
| Cygwin distribution are installed by default. Clicking on categories |
| and packages in the setup.exe package installation screen will |
| provide you with the ability to control what is installed or updated. |
| Clicking on the “Default” field next to the “All” category will |
| provide you with the opportunity to install every Cygwin package. |
| Be advised that this will download and install hundreds of megabytes |
| to your computer.”</p></li> |
| </ol> |
| <p>If you use the “default” installation, you will be missing many |
| of the Cygwin utilities that you will need to build NuttX. The |
| build will fail in numerous places because of missing packages.</p> |
| <p>NOTE: The last time I installed <strong>everything</strong>, the download was |
| about 5GiB. The server I selected was also very slow so it took |
| over a day to do the whole install!</p> |
| <p>NOTE: You don’t really have to install <strong>everything</strong> but I cannot |
| answer the question “Then what should I install?” I don’t know |
| the answer to that and so will continue to recommend installing |
| <strong>everything</strong>.</p> |
| <p>You should certainly be able to omit “Science”, “Math”, and |
| “Publishing”. You can try omitting KDE, Gnome, GTK, and other |
| graphics packages if you don’t plan to use them.</p> |
| <p>Perhaps a minimum set would be those packages listed below for the |
| “Ubuntu Bash under Windows 10” installation?</p> |
| <p><strong>UPDATE</strong>: Sergey Frolov had success with the following minimal |
| Cygwin configuration:</p> |
| <ol class="arabic"> |
| <li><p>After starting the Cygwin installer, keep the recommended |
| packages that are pre-selected in the default configuration.</p></li> |
| <li><p>Using the installation tools, add the following packages:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>make (GNU make) bison libgmp3-dev |
| gcc-core byacc libmpfr-dev |
| gcc-g++ gperf libmpc-dev |
| flex gdb automake-1.15 |
| libncurses-dev libgmp-dev curl |
| </pre></div> |
| </div> |
| </li> |
| </ol> |
| <p>After installing Cygwin, you will get lots of links for installed |
| tools and shells. I use the RXVT native shell. It is fast and reliable |
| and does not require you to run the Cygwin X server (which is neither |
| fast nor reliable). Unless otherwise noted, the rest of these |
| instructions assume that you are at a bash command line prompt in |
| either Linux or in Cygwin shell.</p> |
| </section> |
| <section id="using-msys"> |
| <h4>Using MSYS<a class="headerlink" href="#using-msys" title="Permalink to this heading"></a></h4> |
| <p>MSYS is an environment the derives from Cygwin. Thus, most things said |
| about Cygwin apply equally to MSYS. This section will, then, focus on |
| the differences when using MSYS, specifically MSYS2.</p> |
| <p>Here is it assumed that you have already downloaded and installed MSYS2 |
| from https://www.msys2.org using the windows installer available at that |
| location. It is also assumed that you have brought in the necessary |
| tools using the ‘pacman’ package management tool Tools needed including:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>pacman -S git |
| pacman -S make |
| pacman -S gcc |
| pacman -S gdb |
| </pre></div> |
| </div> |
| <p>And possibly others depending upon your usage. Then you will need to |
| build and install kconfig-frontends per the instructions of the top-level |
| README.txt file in the tools repository. This requires the following |
| additional tools:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>pacman -S bison |
| pacman -S curl |
| pacman -S gperf |
| pacman -S ncurses-devel |
| pacman -S automake-wrapper |
| pacman -S autoconf |
| pacman -S pkg-config |
| </pre></div> |
| </div> |
| <p>Because of some versioning issues, I had to run ‘aclocal’ prior to |
| running the kconfig-frontends configure script. See “Configuring NuttX” |
| below for further information.</p> |
| <p>Unlike Cygwin, MSYS does not support symbolic links. The ‘ln -s’ command |
| will, in fact, copy a directory! This means that you Make.defs file will |
| have to include definitions like:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>ifeq ($(CONFIG_WINDOWS_MSYS),y) |
| DIRLINK = $(TOPDIR)/tools/copydir.sh |
| DIRUNLINK = $(TOPDIR)/tools/unlink.sh |
| endif |
| </pre></div> |
| </div> |
| <p>This will force the directory copies to work in a way that can be handled |
| by the NuttX build system. NOTE: The default link.sh script has been |
| updated so that is should now be MSYS2 compatible. The above is preferred |
| but no longer necessary in the Make.defs file.</p> |
| <p>To build the simulator under MSYS, you also need:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>pacman -S zlib-devel |
| </pre></div> |
| </div> |
| <p>It appears that you cannot use directory names with spaces in them like |
| “/c/Program\ Files (86)” in the MSYS path variable. I worked around this |
| by create Windows junctions like this:</p> |
| <ol class="arabic"> |
| <li><p>Open the a windows command terminal,</p></li> |
| <li><p>cd to <code class="docutils literal notranslate"><span class="pre">c:\msys64</span></code>, then</p></li> |
| <li><p><code class="docutils literal notranslate"><span class="pre">mklink</span> <span class="pre">/j</span> <span class="pre">programfiles</span> <span class="pre">"C:/Program\</span> <span class="pre">Files"</span></code> and</p></li> |
| <li><p><code class="docutils literal notranslate"><span class="pre">mklink</span> <span class="pre">/j</span> <span class="pre">programfiles86</span> <span class="pre">"C:/Program\</span> <span class="pre">Files\</span> <span class="pre">\(x86\)"</span></code></p> |
| <p>They then show up as <code class="docutils literal notranslate"><span class="pre">/programfiles</span></code> and <code class="docutils literal notranslate"><span class="pre">/programfiles86</span></code> with the MSYS2 |
| sandbox. Those paths can then be used with the PATH variable. I had |
| to do something similar for the path to the GNU Tools “ARM Embedded |
| Toolchain” which also has spaces in the path name.</p> |
| </li> |
| </ol> |
| </section> |
| <section id="ubuntu-bash-under-windows-10"> |
| <h4>Ubuntu Bash under Windows 10<a class="headerlink" href="#ubuntu-bash-under-windows-10" title="Permalink to this heading"></a></h4> |
| <p>A better version of a command-line only Ubuntu under Windows 10 (beta) |
| has recently been made available from Microsoft.</p> |
| <section id="installation-for-ubuntu-bash-under-windows-10"> |
| <h5>Installation for Ubuntu Bash under Windows 10<a class="headerlink" href="#installation-for-ubuntu-bash-under-windows-10" title="Permalink to this heading"></a></h5> |
| <p>Installation instructions abound on the Internet complete with screen |
| shots. I will attempt to duplicate those instructions in full here. |
| Here are the simplified installation steps:</p> |
| <ul> |
| <li><p>Open <em>Settings</em>.</p></li> |
| <li><p>Click on <em>Update & security</em>.</p></li> |
| <li><p>Click on <em>For Developers</em>.</p></li> |
| <li><p>Under <em>Use developer features</em>, select the <em>Developer mode</em> option to |
| setup the environment to install Bash.</p></li> |
| <li><p>A message box should pop up. Click <em>Yes</em> to turn on developer mode.</p></li> |
| <li><p>After the necessary components install, you’ll need to restart your |
| computer.</p> |
| <p>Once your computer reboots:</p> |
| </li> |
| <li><p>Open <em>Control Panel</em>.</p></li> |
| <li><p>Click on <em>Programs</em>.</p></li> |
| <li><p>Click on <em>Turn Windows features on or off</em>.</p></li> |
| <li><p>A list of features will pop up, check the <em>Windows Subsystem for Linux |
| (beta)</em> option.</p></li> |
| <li><p>Click <em>OK</em>.</p></li> |
| <li><p>Once the components installed on your computer, click the <em>Restart |
| now</em> button to complete the task.</p> |
| <p>After your computer restarts, you will notice that Bash will not appear in |
| the <em>Recently added</em> list of apps, this is because Bash isn’t actually |
| installed yet. Now that you have setup the necessary components, use the |
| following steps to complete the installation of Bash:</p> |
| </li> |
| <li><p>Open <em>Start</em>, do a search for <code class="docutils literal notranslate"><span class="pre">bash.exe</span></code>, and press <em>Enter</em>.</p></li> |
| <li><p>On the command prompt, type <code class="docutils literal notranslate"><span class="pre">y</span></code> and press Enter to download and install |
| Bash from the Windows Store. This will take awhile.</p></li> |
| <li><p>Then you’ll need to create a default UNIX user account. This account |
| doesn’t have to be the same as your Windows account. Enter the |
| username in the required field and press Enter (you can’t use the |
| username <code class="docutils literal notranslate"><span class="pre">admin</span></code>).</p></li> |
| <li><p>Close the <code class="docutils literal notranslate"><span class="pre">bash.exe</span></code> command prompt.</p></li> |
| </ul> |
| <p>Now that you completed the installation and setup, you can open the Bash |
| tool from the Start menu like you would with any other app.</p> |
| </section> |
| <section id="accessing-windows-files-from-ubuntu"> |
| <h5>Accessing Windows Files from Ubuntu<a class="headerlink" href="#accessing-windows-files-from-ubuntu" title="Permalink to this heading"></a></h5> |
| <p>File systems will be mounted under <code class="docutils literal notranslate"><span class="pre">/mnt</span></code> so for example <code class="docutils literal notranslate"><span class="pre">C:\Program</span> <span class="pre">Files</span></code> |
| appears at <code class="docutils literal notranslate"><span class="pre">/mnt/c/Program</span> <span class="pre">Files</span></code>. This is as opposed to Cygwin where |
| the same directory would appear at <code class="docutils literal notranslate"><span class="pre">/cygdrive/c/Program</span> <span class="pre">Files</span></code>.</p> |
| <p>With these differences (perhaps a few other Windows quirks) the Ubuntu |
| install works just like Ubuntu running natively on your PC.</p> |
| <p>A good tip for file sharing is to use symbolic links within your Ubuntu |
| home directory. For example, suppose you have your <code class="docutils literal notranslate"><span class="pre">projects</span></code> directory |
| at <code class="docutils literal notranslate"><span class="pre">C:\Documents\projects</span></code>. Then you can set up a link to the <code class="docutils literal notranslate"><span class="pre">projects/</span></code> |
| directory in your Ubuntu directory like:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>ln -s /mnt/c/Documents/projects projects |
| </pre></div> |
| </div> |
| </section> |
| <section id="accessing-ubuntu-files-from-windows"> |
| <h5>Accessing Ubuntu Files From Windows<a class="headerlink" href="#accessing-ubuntu-files-from-windows" title="Permalink to this heading"></a></h5> |
| <p>In Ubuntu Userspace for Windows, the Ubuntu file system root directory is |
| at:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>%localappdata%\lxss\rootfs |
| </pre></div> |
| </div> |
| <p>Or</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>C:\Users\Username\AppData\Local\lxss\rootfs |
| </pre></div> |
| </div> |
| <p>However, I am unable to see my files under the rootfs\home directory. |
| After some looking around, I find the home directory |
| <code class="docutils literal notranslate"><span class="pre">%localappdata%\lxss\home</span></code>.</p> |
| <p>With that trick access to the <code class="docutils literal notranslate"><span class="pre">/home</span></code> directory, you should actually be |
| able to use Windows tools outside of the Ubuntu sandbox with versions of |
| NuttX built within the sandbox using that path.</p> |
| </section> |
| <section id="executing-windows-tools-from-ubuntu"> |
| <h5>Executing Windows Tools from Ubuntu<a class="headerlink" href="#executing-windows-tools-from-ubuntu" title="Permalink to this heading"></a></h5> |
| <p>You can also execute Windows tools from within the Ubuntu sandbox:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>/mnt/c/Program\ Files\ \(x86\)/Microchip/xc32/v1.43/bin/xc32-gcc.exe --version |
| Unable to translate current working directory. Using C:\WINDOWS\System32 |
| xc32-gcc.exe (Microchip Technology) 4.8.3 MPLAB XC32 Compiler v1.43 Build date: Mar 1 2017 |
| ... |
| </pre></div> |
| </div> |
| <p>The error message indicates that there are more issues: You cannot mix |
| Windows tools that use Windows style paths in an environment that uses |
| POSIX paths. I think you would have to use Linux tools only from within |
| the Ubuntu sandbox.</p> |
| </section> |
| <section id="install-ubuntu-software"> |
| <h5>Install Ubuntu Software<a class="headerlink" href="#install-ubuntu-software" title="Permalink to this heading"></a></h5> |
| <p>Use <code class="docutils literal notranslate"><span class="pre">sudo</span> <span class="pre">apt-get</span> <span class="pre">install</span> <span class="pre"><package</span> <span class="pre">name></span></code>. As examples, this is how |
| you would get GIT:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>sudo apt-get install git |
| </pre></div> |
| </div> |
| <p>This will get you a compiler for your host PC:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>sudo apt-get install gcc |
| </pre></div> |
| </div> |
| <p>This will get you an ARM compiler for your target:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>sudo apt-get install gcc-arm-none-eabi |
| </pre></div> |
| </div> |
| <p><strong>NOTE</strong>: That is just an example. I am not sure if apt-get will give you a |
| current or usable compiler. You should carefully select your toolchain |
| for the needs of your project.</p> |
| <p>You will also need to get the kconfig-frontends configuration as |
| described below under <em>NuttX Configuration Tool</em>. In order to build the |
| kconfig-frontends configuration tool you will also need: <code class="docutils literal notranslate"><span class="pre">make</span></code>, <code class="docutils literal notranslate"><span class="pre">gperf</span></code>, |
| <code class="docutils literal notranslate"><span class="pre">flex</span></code>, <code class="docutils literal notranslate"><span class="pre">bison</span></code>, and <code class="docutils literal notranslate"><span class="pre">libncurses-dev</span></code>.</p> |
| <p>That is enough to do a basic NuttX build.</p> |
| </section> |
| <section id="integrating-with-windows-tools"> |
| <h5>Integrating with Windows Tools<a class="headerlink" href="#integrating-with-windows-tools" title="Permalink to this heading"></a></h5> |
| <p>If you want to integrate with Windows native tools, then you would need |
| deal with the same kind of craziness as with integrating Cygwin with |
| native toolchains, see the section <em>Cygwin Build Problems</em> below.</p> |
| <p>However, there is currently no build support for using Windows native |
| tools with Ubuntu under Windows. This tool combination is made to work |
| with Cygwin through the use of the <code class="docutils literal notranslate"><span class="pre">cygpath</span> <span class="pre">-w</span></code> tool that converts paths |
| from say <code class="docutils literal notranslate"><span class="pre">/cydrive/c/Program</span> <span class="pre">Files</span></code> to <code class="docutils literal notranslate"><span class="pre">C:\Program</span> <span class="pre">Files</span></code>. There is, |
| however, no corresponding tool to convert <code class="docutils literal notranslate"><span class="pre">/mnt/c/Program</span> <span class="pre">Files</span></code> in the |
| Ubuntu environment.</p> |
| </section> |
| <section id="graphics-support"> |
| <h5>Graphics Support<a class="headerlink" href="#graphics-support" title="Permalink to this heading"></a></h5> |
| <p>The Ubuntu version support by Microsoft is a command-line only version. |
| There is no support for Linux graphics utilities.</p> |
| <p>This limitation is not a limitation of Ubuntu, however, only in what |
| Microsoft is willing to support. If you install a X-Server, then you |
| can also use basic graphics utilities. See for example:</p> |
| <p><a class="reference external" href="http://www.howtogeek.com/261575/how-to-run-graphical-linux-desktop-applications-from-windows-10s-bash-shell/">http://www.howtogeek.com/261575/how-to-run-graphical-linux-desktop-applications-from-windows-10s-bash-shell/</a></p> |
| <p>Many Linux graphics programs would, however, also require a graphics |
| framework like GTK or Qt. So this might be a trip down the rabbit hole.</p> |
| </section> |
| <section id="using-macos"> |
| <h5>Using macOS<a class="headerlink" href="#using-macos" title="Permalink to this heading"></a></h5> |
| <p>You need to install at least the following tools specific to macOS.</p> |
| <ul class="simple"> |
| <li><p>flock (used by APPDIR build logic)</p></li> |
| </ul> |
| <p>A macOS port is available at: <a class="reference external" href="https://github.com/discoteq/flock">https://github.com/discoteq/flock</a></p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>brew tap discoteq/discoteq |
| brew install flock |
| </pre></div> |
| </div> |
| <p>If you want to build the sim:</p> |
| <ul> |
| <li><p>Xcode (the native compiler and the rest of the toolchain)</p></li> |
| <li><p>ELF toolchain (if you want to build modules for CONFIG_LIBC_MODLIB)</p> |
| <p>brew install x86_64-elf-gcc</p> |
| </li> |
| </ul> |
| </section> |
| </section> |
| </section> |
| <section id="installation"> |
| <h3>INSTALLATION<a class="headerlink" href="#installation" title="Permalink to this heading"></a></h3> |
| <p>There are two ways to get NuttX: You may download released, stable |
| tarballs from either the project website. Or you may get NuttX by |
| cloning the GIT repositories. Let’s consider the released tarballs |
| first:</p> |
| <section id="download-and-unpack"> |
| <h4>Download and Unpack<a class="headerlink" href="#download-and-unpack" title="Permalink to this heading"></a></h4> |
| <p>Download and unpack the NuttX tarball. If you are reading this, then |
| you have probably already done that. After unpacking, you will end |
| up with a directory called nuttx-version (where version is the NuttX |
| version number). You might want to rename that directory nuttx to |
| match the various instructions in the documentation and some scripts |
| in the source tree.</p> |
| <ul> |
| <li><p>Download location:</p> |
| <p><a class="reference external" href="https://nuttx.apache.org/download/">https://nuttx.apache.org/download/</a></p> |
| </li> |
| <li><p>Legacy download locations:</p> |
| <p><a class="reference external" href="https://bitbucket.org/nuttx/nuttx/downloads">https://bitbucket.org/nuttx/nuttx/downloads</a> |
| <a class="reference external" href="https://sourceforge.net/projects/nuttx/files/nuttx/">https://sourceforge.net/projects/nuttx/files/nuttx/</a></p> |
| </li> |
| </ul> |
| </section> |
| <section id="semi-optional-apps-package"> |
| <h4>Semi-Optional apps/ Package<a class="headerlink" href="#semi-optional-apps-package" title="Permalink to this heading"></a></h4> |
| <p>All NuttX libraries and example code used to be in included within |
| the NuttX source tree. As of NuttX-6.0, this application code was |
| moved into a separate tarball, the apps tarball. If you are just |
| beginning with NuttX, then you will want to download the versioned |
| apps tarball along with the NuttX tarball. If you already have your |
| own product application directory, then you may not need the apps |
| tarball.</p> |
| <p>It is called “Semi-optional” because if you don’t have some <code class="docutils literal notranslate"><span class="pre">apps/</span></code> |
| directory, NuttX will <em>fail</em> to build! You do not necessarily need |
| to use the NuttX apps tarball but may, instead, provide your own |
| custom application directory. Such a custom directory would need |
| to include a valid Makefile to support the build and a valid Kconfig |
| file to support the configuration. More about these files later.</p> |
| <p>Download then unpack the apps tarball in the same directory where you |
| unpacked the NuttX tarball. After you unpack the apps tarball, you |
| will have a new directory called apps-version (where the version |
| should exactly match the version of the NuttX tarball). Again, you |
| might want to rename the directory to simply apps/ to match what |
| you read in the documentation</p> |
| <p>After unpacking (and renaming) the apps tarball, you will have two |
| directories side by side like this:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span> | |
| +----+----+ |
| | | |
| nuttx/ apps/ |
| </pre></div> |
| </div> |
| <p>This is important because the NuttX build will expect to find the |
| apps directory in that (default) location. That default location |
| can be changed by modifying your NuttX configuration file, but that |
| is another story.</p> |
| </section> |
| <section id="installation-directories-with-spaces-in-the-path"> |
| <h4>Installation Directories with Spaces in the Path<a class="headerlink" href="#installation-directories-with-spaces-in-the-path" title="Permalink to this heading"></a></h4> |
| <p>The nuttx build directory should reside in a path that contains no |
| spaces in any higher level directory name. For example, under |
| Cygwin, your home directory might be formed from your first and last |
| names like: <code class="docutils literal notranslate"><span class="pre">/home/First</span> <span class="pre">Last</span></code>. That will cause strange errors when |
| the make system tries to build.</p> |
| <p>[Actually, that problem is probably not too difficult to fix. Some |
| Makefiles probably just need some paths within double quotes]</p> |
| <p>I work around spaces in the home directory name, by creating a |
| new directory that does not contain any spaces, such as <code class="docutils literal notranslate"><span class="pre">/home/nuttx</span></code>. |
| Then I install NuttX in <code class="docutils literal notranslate"><span class="pre">/home/nuttx</span></code> and always build from |
| <code class="docutils literal notranslate"><span class="pre">/home/nuttx/nuttx-code</span></code>.</p> |
| </section> |
| <section id="downloading-from-repositories"> |
| <h4>Downloading from Repositories<a class="headerlink" href="#downloading-from-repositories" title="Permalink to this heading"></a></h4> |
| <section id="cloning-the-repository"> |
| <h5>Cloning the Repository<a class="headerlink" href="#cloning-the-repository" title="Permalink to this heading"></a></h5> |
| <p><strong>BEFORE</strong> cloning repositories on any Windows platform do the following GIT |
| command:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git config --global core.autocrlf false |
| </pre></div> |
| </div> |
| <p>That will avoid conversions of linefeeds (newlines, \n) to carriage |
| return plus linefeed sequences (\r\n)</p> |
| <p>The current NuttX du jour is available in from a GIT repository. Here are |
| instructions for cloning the core NuttX RTOS (corresponding to the nuttx |
| tarball discussed above):</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git clone https://gitbox.apache.org/repos/asf/nuttx.git nuttx |
| </pre></div> |
| </div> |
| <p>-or-</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git clone https://github.com/apache/nuttx.git nuttx |
| </pre></div> |
| </div> |
| <p>And the semi-optional apps/ application directory and be cloned like:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git clone https://gitbox.apache.org/repos/asf/nuttx-apps.git apps |
| </pre></div> |
| </div> |
| <p>-or-</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git clone https://github.com/apache/nuttx-apps.git apps |
| </pre></div> |
| </div> |
| <p>That will give you the same directory structure like this:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span> | |
| +----+----+ |
| | | |
| nuttx/ apps/ |
| </pre></div> |
| </div> |
| </section> |
| <section id="configuring-the-clones"> |
| <h5>Configuring the Clones<a class="headerlink" href="#configuring-the-clones" title="Permalink to this heading"></a></h5> |
| <p>The following steps need to be performed for each of the repositories. |
| After changing to the clone directory:</p> |
| <p>Set your identity:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git config --global user.name "My Name" |
| git config --global user.email my.name@example.com |
| </pre></div> |
| </div> |
| <p>Colorized diffs are much easier to read:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git config --global color.branch auto |
| git config --global color.diff auto |
| git config --global color.interactive auto |
| git config --global color.status auto |
| </pre></div> |
| </div> |
| <p>Checkout other settings</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git config --list |
| </pre></div> |
| </div> |
| </section> |
| <section id="cloning-nuttx-inside-cygwin"> |
| <h5>Cloning NuttX Inside Cygwin<a class="headerlink" href="#cloning-nuttx-inside-cygwin" title="Permalink to this heading"></a></h5> |
| <p>If you are cloning the NuttX repository, it is recommended to avoid |
| automatic end of lines conversions by git. These conversions may break |
| some scripts like configure.sh. Before cloning, do the following:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>git config --global core.autocrlf false |
| </pre></div> |
| </div> |
| </section> |
| </section> |
| <section id="related-repositories"> |
| <h4>Related Repositories<a class="headerlink" href="#related-repositories" title="Permalink to this heading"></a></h4> |
| <p>These are standalone repositories:</p> |
| <ul> |
| <li><p><a class="reference external" href="https://gitbox.apache.org/repos/asf/nuttx-apps">https://gitbox.apache.org/repos/asf/nuttx-apps</a> |
| or |
| <a class="reference external" href="https://github.com/apache/nuttx-apps.git">https://github.com/apache/nuttx-apps.git</a></p> |
| <p>This directory holds an optional package of applications and libraries |
| can be used with the NuttX RTOS. There is a README.txt file there that |
| will provide more information about that package.</p> |
| </li> |
| <li><p><a class="reference external" href="https://bitbucket.org/nuttx/nxwidgets">https://bitbucket.org/nuttx/nxwidgets</a></p> |
| <p>This is the NuttX C++ graphics support. This includes NxWM, the tiny |
| NuttX Window Manager.</p> |
| </li> |
| <li><p><a class="reference external" href="https://bitbucket.org/nuttx/uclibc">https://bitbucket.org/nuttx/uclibc</a></p> |
| <p>This repository contains a version of the uClibc++ C++ library. This code |
| originates from <a class="reference external" href="http://cxx.uclibc.org/">http://cxx.uclibc.org/</a> and has been adapted for NuttX by the |
| RGMP team (<a class="reference external" href="http://rgmp.sourceforge.net/wiki/index.php/Main_Page">http://rgmp.sourceforge.net/wiki/index.php/Main_Page</a>).</p> |
| </li> |
| <li><p><a class="reference external" href="https://bitbucket.org/nuttx/buildroot">https://bitbucket.org/nuttx/buildroot</a></p> |
| <p>A environment that you can to use to build a custom, NuttX GNU toolchain.</p> |
| </li> |
| <li><p><a class="reference external" href="https://bitbucket.org/nuttx/tools">https://bitbucket.org/nuttx/tools</a></p> |
| <p>There are snapshots of some tools here that you will need to work with |
| NuttX: kconfig-frontends, genromfs, and others.</p> |
| </li> |
| </ul> |
| </section> |
| <section id="notes-about-header-files"> |
| <h4>Notes about Header Files<a class="headerlink" href="#notes-about-header-files" title="Permalink to this heading"></a></h4> |
| <section id="other-c-library-header-files"> |
| <h5>Other C-Library Header Files<a class="headerlink" href="#other-c-library-header-files" title="Permalink to this heading"></a></h5> |
| <p>When a GCC toolchain is built, it must be built against a C library. |
| The compiler together with the contents of the C library completes the |
| C language definition and provides the complete C development |
| environment. NuttX provides its own, built-in C library. So the |
| complete, consistent C language definition for use with NuttX comes from |
| the combination of the compiler and the header files provided by the |
| NuttX C library.</p> |
| <p>When a GCC toolchain is built, it incorporates the C library header |
| files into the compiler internal directories and, in this way, the C |
| library really becomes a part of the toolchain. If you use the NuttX |
| buildroot toolchain as described below under “NuttX Buildroot |
| Toolchain”, your GCC toolchain will build against the NuttX C library |
| and will incorporate the NuttX C library header files as part of the |
| toolchain.</p> |
| <p>If you use some other, third-party tool chain, this will not be the |
| case, however. Those toolchains were probably built against some |
| other, incompatible C library distribution (such as newlib). Those |
| tools will have incorporated the incompatible C library header files |
| as part of the toolchain. These incompatible header files must <em>not</em> |
| be used with NuttX because they will conflict with definitions in the |
| NuttX built-in C-Library. For such toolchains that include header |
| files from a foreign C-Library, NuttX must be compiled without using |
| the standard header files that are distributed with your toolchain. |
| This prevents including conflicting, incompatible header files such |
| as stdio.h.</p> |
| <p>The math.h and stdarg.h are probably the two most trouble some header |
| files to deal with. These troublesome header files are discussed in |
| more detail below.</p> |
| </section> |
| <section id="header-files-provided-by-your-toolchain"> |
| <h5>Header Files Provided by Your Toolchain<a class="headerlink" href="#header-files-provided-by-your-toolchain" title="Permalink to this heading"></a></h5> |
| <p>Certain header files, such as <code class="docutils literal notranslate"><span class="pre">setjmp.h</span></code>, <code class="docutils literal notranslate"><span class="pre">stdarg.h</span></code>, and <code class="docutils literal notranslate"><span class="pre">math.h</span></code>, may still |
| be needed from your toolchain and your compiler may not, however, be able |
| to find these if you compile NuttX without using standard header files |
| (i.e., with <code class="docutils literal notranslate"><span class="pre">-nostdinc</span></code>). If that is the case, one solution is to copy |
| those header file from your toolchain into the NuttX include directory.</p> |
| </section> |
| <section id="duplicated-header-files"> |
| <h5>Duplicated Header Files<a class="headerlink" href="#duplicated-header-files" title="Permalink to this heading"></a></h5> |
| <p>There are also a few header files that can be found in the <code class="docutils literal notranslate"><span class="pre">nuttx/include</span></code> |
| directory which are duplicated by the header files from your toolchain. |
| stdint.h and stdbool.h are examples. If you prefer to use the <code class="docutils literal notranslate"><span class="pre">stdint.h</span></code> |
| and <code class="docutils literal notranslate"><span class="pre">stdbool.h</span></code> header files from your toolchain, those could be copied |
| into the <code class="docutils literal notranslate"><span class="pre">nuttx/include/</span></code> directory. Using most other header files from |
| your toolchain would probably cause errors.</p> |
| </section> |
| <section id="math-h"> |
| <h5>math.h<a class="headerlink" href="#math-h" title="Permalink to this heading"></a></h5> |
| <p>Even though you should not use a foreign C-Library, you may still need |
| to use other, external libraries with NuttX. In particular, you may |
| need to use the math library, libm.a. NuttX supports a generic, built-in |
| math library that can be enabled using <code class="docutils literal notranslate"><span class="pre">CONFIG_LIBM=y</span></code>. However, you may |
| still want to use a higher performance external math library that has |
| been tuned for your CPU. Sometimes such tuned math libraries are |
| bundled with your toolchain.</p> |
| <p>The math library header file, <code class="docutils literal notranslate"><span class="pre">math.h</span></code>, is a then special case. If you do |
| nothing, the standard math.h header file that is provided with your |
| toolchain will be used.</p> |
| <p>If you have a custom, architecture specific math.h header file, then |
| that header file should be placed at <code class="docutils literal notranslate"><span class="pre">arch/<cpu>/include/math.h</span></code>. There |
| is a stub <code class="docutils literal notranslate"><span class="pre">math.h</span></code> header file located at <code class="docutils literal notranslate"><span class="pre">include/nuttx/lib/math.h</span></code>. This stub |
| header file can be used to “redirect” the inclusion to an architecture- |
| specific math.h header file. If you add an architecture specific math.h |
| header file then you should also define <code class="docutils literal notranslate"><span class="pre">CONFIG_ARCH_MATH_H=y</span></code> in your |
| NuttX Configuration file. If <code class="docutils literal notranslate"><span class="pre">CONFIG_ARCH_MATH_H</span></code> is selected, then the |
| top-level Makefile will copy the stub math.h header file from |
| <code class="docutils literal notranslate"><span class="pre">include/nuttx/lib/math.h</span></code> to <code class="docutils literal notranslate"><span class="pre">include/math.h</span></code> where it will become the system |
| <code class="docutils literal notranslate"><span class="pre">math.h</span></code> header file. The stub <code class="docutils literal notranslate"><span class="pre">math.h</span></code> header file does nothing other |
| than to include that architecture-specific <code class="docutils literal notranslate"><span class="pre">math.h</span></code> header file as the |
| system <code class="docutils literal notranslate"><span class="pre">math.h</span></code> header file.</p> |
| </section> |
| <section id="float-h"> |
| <h5>float.h<a class="headerlink" href="#float-h" title="Permalink to this heading"></a></h5> |
| <p>If you enable the generic, built-in math library, then that math library |
| will expect your toolchain to provide the standard <code class="docutils literal notranslate"><span class="pre">float.h</span></code> header file. |
| The float.h header file defines the properties of your floating point |
| implementation. It would always be best to use your toolchain’s <code class="docutils literal notranslate"><span class="pre">float.h</span></code> |
| header file but if none is available, a default <code class="docutils literal notranslate"><span class="pre">float.h</span></code> header file will |
| be provided if this option is selected. However, there is no assurance |
| that the settings in this <code class="docutils literal notranslate"><span class="pre">float.h</span></code> are actually correct for your platform!</p> |
| </section> |
| <section id="stdarg-h"> |
| <h5>stdarg.h<a class="headerlink" href="#stdarg-h" title="Permalink to this heading"></a></h5> |
| <p>In most cases, the correct version of stdarg.h is the version provided |
| with your toolchain. However, sometimes there are issues with |
| using your toolchains <code class="docutils literal notranslate"><span class="pre">stdarg.h</span></code>. For example, it may attempt to draw in |
| header files that do not exist in NuttX or perhaps the header files that |
| it uses are not compatible with the NuttX header files. In those cases, |
| you can use an architecture-specific <code class="docutils literal notranslate"><span class="pre">stdarg.h</span></code> header file by defining |
| <code class="docutils literal notranslate"><span class="pre">CONFIG_ARCH_STDARG_H=y</span></code>.</p> |
| <p>See the discussion above for the <code class="docutils literal notranslate"><span class="pre">math.h</span></code> header. This setting works |
| exactly the same for the <code class="docutils literal notranslate"><span class="pre">stdarg.h</span></code> header file.</p> |
| </section> |
| </section> |
| </section> |
| <section id="configuring-nuttx"> |
| <h3>CONFIGURING NUTTX<a class="headerlink" href="#configuring-nuttx" title="Permalink to this heading"></a></h3> |
| <section id="instantiating-canned-configurations"> |
| <h4>Instantiating “Canned” Configurations<a class="headerlink" href="#instantiating-canned-configurations" title="Permalink to this heading"></a></h4> |
| <section id="configure-sh-and-configure-bat"> |
| <h5><code class="docutils literal notranslate"><span class="pre">configure.sh</span></code> and <code class="docutils literal notranslate"><span class="pre">configure.bat</span></code><a class="headerlink" href="#configure-sh-and-configure-bat" title="Permalink to this heading"></a></h5> |
| <p>“Canned” NuttX configuration files are retained in:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>boards/<arch-name>/<chip-name>/<board-name>/configs/<config-dir> |
| </pre></div> |
| </div> |
| <p>Where <code class="docutils literal notranslate"><span class="pre"><board-name></span></code> is the name of your development board and <code class="docutils literal notranslate"><span class="pre"><config-dir></span></code> |
| is the name of the sub-directory containing a specific configuration for |
| that board. <code class="docutils literal notranslate"><span class="pre"><arch-name></span></code> and <code class="docutils literal notranslate"><span class="pre"><chip-name></span></code> refer to characteristics of the |
| MCU used on the board: <code class="docutils literal notranslate"><span class="pre"><arch-name></span></code> is the CPU architecture implemented |
| by the MCU; <code class="docutils literal notranslate"><span class="pre"><chip-name></span></code> identifies the MCU chip family. Only a few |
| steps are required to instantiate a NuttX configuration, but to make the |
| configuration even easier there are scripts available in the tools/ |
| sub-directory combines those simple steps into one command.</p> |
| <p>There is one tool for use with any Bash-like shell that does configuration |
| steps. It is used as follows:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>tools/configure.sh <board-name>:<config-dir> |
| </pre></div> |
| </div> |
| <p>There is an alternative Windows batch file that can be used in the windows |
| native environment like:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>tools\configure.bat <board-name>:<config-dir> |
| </pre></div> |
| </div> |
| <p>And, to make sure that other platforms are supported, there is also a |
| C program at tools/configure.c that can be compiled to establish the |
| board configuration.</p> |
| <p>See <code class="docutils literal notranslate"><span class="pre">tools/README.txt</span></code> for more information about these scripts.</p> |
| <p>General information about configuring NuttX can be found in:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>{TOPDIR}/boards/README.txt |
| {TOPDIR}/boards/<arch-name>/<chip-name>/<board-name>/README.txt |
| </pre></div> |
| </div> |
| </section> |
| <section id="the-hidden-configuration-scripts"> |
| <h5>The Hidden Configuration Scripts:<a class="headerlink" href="#the-hidden-configuration-scripts" title="Permalink to this heading"></a></h5> |
| <p>As mentioned above, there are only a few simple steps to instantiating a |
| NuttX configuration. Those steps are hidden by the configuration scripts |
| but are summarized below:</p> |
| <ol class="arabic"> |
| <li><p>Copy Files</p> |
| <p>Configuring NuttX requires only copying two files from the |
| <code class="docutils literal notranslate"><span class="pre"><config-dir></span></code> to the directory where you installed NuttX (TOPDIR):</p> |
| <ul> |
| <li><p>Copy <code class="docutils literal notranslate"><span class="pre">boards/<arch-name>/<chip-name>/<board-name>/configs/<config-dir>/Make.def</span></code> to <code class="docutils literal notranslate"><span class="pre">{TOPDIR}/Make.defs</span></code></p> |
| <p>OR</p> |
| </li> |
| <li><p>Copy <code class="docutils literal notranslate"><span class="pre">boards/<arch-name>/<chip-name>/<board-name>/scripts/Make.def</span></code> |
| to <code class="docutils literal notranslate"><span class="pre">{TOPDIR}/Make.defs</span></code></p> |
| <p>Make.defs describes the rules needed by your tool chain to compile |
| and link code. You may need to modify this file to match the |
| specific needs of your toolchain. NOTE that a configuration may |
| have its own unique Make.defs file in its configuration directory or |
| it may use a common Make.defs file for the board in the scripts/ |
| directory. The first takes precedence.</p> |
| </li> |
| <li><p>Copy <code class="docutils literal notranslate"><span class="pre">boards/<arch-name>/<chip-name>/<board-name>/configs/<config-dir>/defconfig</span></code> to <code class="docutils literal notranslate"><span class="pre">{TOPDIR}/.config</span></code></p> |
| <p>The defconfig file holds the actual build configuration. This |
| file is included by all other make files to determine what is |
| included in the build and what is not. This file is also used |
| to generate a C configuration header at <code class="docutils literal notranslate"><span class="pre">include/nuttx/config.h</span></code>.</p> |
| </li> |
| <li><p>Copy other, environment-specific files to <code class="docutils literal notranslate"><span class="pre">{TOPDIR}</span></code></p> |
| <p>This might include files like .gdbinit or IDE configuration files |
| like .project or .cproject.</p> |
| </li> |
| </ul> |
| </li> |
| <li><p>Refresh the Configuration</p> |
| <p>New configuration setting may be added or removed. Existing settings |
| may also change there values or options. This must be handled by |
| refreshing the configuration as described below.</p> |
| <p>NOTE: NuttX uses only compressed defconfig files. For the NuttX |
| defconfig files, this refreshing step is <em>NOT</em> optional; it is also |
| necessary to uncompress and regenerate the full making file. This is |
| discussed further below.</p> |
| </li> |
| </ol> |
| </section> |
| </section> |
| <section id="refreshing-configurations"> |
| <h4>Refreshing Configurations<a class="headerlink" href="#refreshing-configurations" title="Permalink to this heading"></a></h4> |
| <p>Configurations can get out of date. As new configuration settings are |
| added or removed or as dependencies between configuration settings |
| change, the contents of a default configuration can become out of synch |
| with the build systems. Hence, it is a good practice to “refresh” each |
| configuration after configuring and before making. To refresh the |
| configuration, use the NuttX Configuration Tool like this:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>make oldconfig |
| </pre></div> |
| </div> |
| <p>AFTER you have instantiated the NuttX configuration as described above. |
| The configuration step copied the .config file into place in the top-level |
| NuttX directory; ‘make oldconfig’ step will then operate on that .config |
| file to bring it up-to-date.</p> |
| <p>If your configuration is out of date, you will be prompted by ‘make oldconfig’ |
| to resolve the issues detected by the configuration tool, that is, to |
| provide values for the new configuration options in the build system. Doing |
| this can save you a lot of problems down the road due to obsolete settings in |
| the default board configuration file. The NuttX configuration tool is |
| discussed in more detail in the following paragraph.</p> |
| <p>Confused about what the correct value for a new configuration item should |
| be? Enter ? in response to the ‘make oldconfig’ prompt and it will show |
| you the help text that goes with the option.</p> |
| <p>If you don’t want to make any decisions are willing to just accept the |
| recommended default value for each new configuration item, an even easier |
| way is:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>make olddefconfig |
| </pre></div> |
| </div> |
| <p>The olddefconfig target will simply bring your configuration up to date with |
| the current Kconfig files, setting any new options to the default value. |
| No questions asked.</p> |
| </section> |
| <section id="nuttx-configuration-tool"> |
| <h4>NuttX Configuration Tool<a class="headerlink" href="#nuttx-configuration-tool" title="Permalink to this heading"></a></h4> |
| <p>An automated tool has been incorporated to support re-configuration |
| of NuttX. This tool is based on the kconfig-frontends application available |
| at <a class="reference external" href="https://bitbucket.org/nuttx/tools/src/master/kconfig-frontends/">https://bitbucket.org/nuttx/tools/src/master/kconfig-frontends/</a>. (This |
| is a snapshot of the old <a class="reference external" href="http://ymorin.is-a-geek.org/projects/kconfig-frontends">http://ymorin.is-a-geek.org/projects/kconfig-frontends</a> |
| which is no longer available.) This application provides a tool called |
| <code class="docutils literal notranslate"><span class="pre">kconfig-mconf</span></code> that is used by the NuttX top-level Makefile. The following |
| make target is provided:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>make menuconfig |
| </pre></div> |
| </div> |
| <p>This make target will bring up NuttX configuration menus.</p> |
| <p><strong>WARNING</strong>: Never do <code class="docutils literal notranslate"><span class="pre">make</span> <span class="pre">menuconfig</span></code> on a configuration that has |
| not been converted to use the kconfig-frontends tools! This will |
| damage your configuration (see |
| <a class="reference external" href="https://cwiki.apache.org/confluence/display/NUTTX/Converting+Legacy+Configurations+to+Use+kconfig-mconf">https://cwiki.apache.org/confluence/display/NUTTX/Converting+Legacy+Configurations+to+Use+kconfig-mconf</a>).</p> |
| <p>NuttX also supports kconfiglib(https://github.com/ulfalizer/Kconfiglib) by default, |
| which is a Kconfig tool implemented in Python 2/3. Compared with kconfig-frontends, |
| kconfiglib provides NuttX with the possibility of multi-platform support(configure |
| NuttX in Winodws native/Visual Studio), and also kconfiglib has a stronger Kconfig |
| syntax check, this will help developers to avoid some Kconfig syntax errors. |
| Install kconfiglib via following command:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>pip install kconfiglib |
| </pre></div> |
| </div> |
| <p>If you are a working on Windows, which also need the support of windows-curses:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>pip install windows-curses |
| </pre></div> |
| </div> |
| <p><strong>NOTE</strong>: It should be noted that kconfiglib does not support <strong>modules</strong> attributes. |
| (<a class="reference external" href="https://github.com/ulfalizer/Kconfiglib/blob/master/kconfiglib.py#L3239-L3254">https://github.com/ulfalizer/Kconfiglib/blob/master/kconfiglib.py#L3239-L3254</a>, |
| the community seems to have stopped updating), if the features depends on |
| <code class="docutils literal notranslate"><span class="pre">CONFIG_BUILD_LOADABLE</span></code>, kconfiglib may not be a good choice.</p> |
| <p>How do we tell a new configuration from an old one? See “Incompatibilities |
| with Older Configurations” below.</p> |
| <p>The <code class="docutils literal notranslate"><span class="pre">menuconfig</span></code> make target depends on two things:</p> |
| <ol class="arabic"> |
| <li><p>The Kconfig configuration data files that appear in almost all |
| NuttX directories. These data files are the part that is still |
| under development (patches are welcome!). The Kconfig files |
| contain configuration information for the configuration settings |
| relevant to the directory in which the Kconfig file resides.</p> |
| <p>NOTE: For a description of the syntax of this configuration file, |
| see kconfig-language.txt in the tools repository at |
| <a class="reference external" href="https://bitbucket.org/nuttx/tools">https://bitbucket.org/nuttx/tools</a></p> |
| </li> |
| <li><p>The <code class="docutils literal notranslate"><span class="pre">kconfig-mconf</span></code> tool. <code class="docutils literal notranslate"><span class="pre">kconfig-mconf</span></code> is part of the |
| kconfig-frontends package. You can download that package from the |
| snapshot in the tools repository at <a class="reference external" href="https://bitbucket.org/nuttx/tools">https://bitbucket.org/nuttx/tools</a>.</p> |
| <p>Building kconfig-frontends under Linux may be as simple as |
| <code class="docutils literal notranslate"><span class="pre">configure;</span> <span class="pre">make;</span> <span class="pre">make</span> <span class="pre">install</span></code> but there may be some build |
| complexities, especially if you are building under Cygwin. See |
| the more detailed build instructions in the top-level README.txt |
| file of the tools repository at <a class="reference external" href="https://bitbucket.org/nuttx/tools">https://bitbucket.org/nuttx/tools</a>.</p> |
| <p>The <code class="docutils literal notranslate"><span class="pre">make</span> <span class="pre">install</span></code> step will, by default, install the <code class="docutils literal notranslate"><span class="pre">kconfig-mconf</span></code> |
| tool at <code class="docutils literal notranslate"><span class="pre">/usr/local/bin/mconf</span></code>. Where ever you choose to |
| install <code class="docutils literal notranslate"><span class="pre">kconfig-mconf</span></code>, make certain that your PATH variable includes |
| a path to that installation directory.</p> |
| <p>The kconfig-frontends tools will not build in a native Windows |
| environment directly “out-of-the-box”. For the Windows native |
| case, you can use the modified version of kconfig-frontends |
| that can be found at</p> |
| <p><a class="reference external" href="http://uvc.de/posts/linux-kernel-configuration-tool-kconfig-under-windows.html">http://uvc.de/posts/linux-kernel-configuration-tool-kconfig-under-windows.html</a></p> |
| <p>or a more recent port that can be found at</p> |
| <p><a class="reference external" href="http://reclonelabs.com/more-kconfig-awesomeness-for-windows/">http://reclonelabs.com/more-kconfig-awesomeness-for-windows/</a>.</p> |
| </li> |
| </ol> |
| <p>The basic configuration order is “bottom-up”:</p> |
| <ul class="simple"> |
| <li><p>Select the build environment,</p></li> |
| <li><p>Select the processor,</p></li> |
| <li><p>Select the board,</p></li> |
| <li><p>Select the supported peripherals</p></li> |
| <li><p>Configure the device drivers,</p></li> |
| <li><p>Configure the application options on top of this.</p></li> |
| </ul> |
| <p>This is pretty straight forward for creating new configurations |
| but may be less intuitive for modifying existing configurations.</p> |
| <p>Another ncurses-based tool that is an option to kconfig-mconf is |
| kconfig-nconf. The differences are primary in in the aesthetics of the |
| UI. If you have kconfig-nconf built, then you can invoke that front end |
| with:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span> make nconfig |
| </pre></div> |
| </div> |
| <p>If you have an environment that supports the Qt or GTK graphical systems |
| (probably KDE or gnome, respectively, or Cygwin under Windows with Qt or |
| GTK installed), then you can also build the graphical kconfig-frontends, |
| kconfig-qconf and kconfig-gconf. In these case, you can start the |
| graphical configurator with either:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span> make qconfig |
| </pre></div> |
| </div> |
| <p>or</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span> make gconfig |
| </pre></div> |
| </div> |
| <p>Some keyboard shortcuts supported by kconfig-mconf, the tool that runs |
| when you do ‘make menuconfig’:</p> |
| <ul class="simple"> |
| <li><p><code class="docutils literal notranslate"><span class="pre">?</span></code> will bring up the mconfig help display.</p></li> |
| <li><p><code class="docutils literal notranslate"><span class="pre">/</span></code> can be used find configuration selections.</p></li> |
| <li><p><code class="docutils literal notranslate"><span class="pre">Z</span></code> can be used to reveal hidden configuration options</p></li> |
| </ul> |
| <p>These last two shortcuts are described further in the following |
| paragraphs.</p> |
| </section> |
| <section id="finding-selections-in-the-configuration-menus"> |
| <h4>Finding Selections in the Configuration Menus<a class="headerlink" href="#finding-selections-in-the-configuration-menus" title="Permalink to this heading"></a></h4> |
| <p>The NuttX configuration options have gotten complex and it can be very |
| difficult to find options in the menu trees if you are not sure where |
| to look. The “basic configuration order” describe above can help to |
| narrow things down.</p> |
| <p>But if you know exactly what configuration setting you want to select, |
| say <code class="docutils literal notranslate"><span class="pre">CONFIG_XYZ</span></code>, but not where to find it, then the <code class="docutils literal notranslate"><span class="pre">make</span> <span class="pre">menuconfig</span></code> |
| version of the tool offers some help: By pressing the ‘/’ key, the |
| tool will bring up a menu that will allow you to search for a |
| configuration item. Just enter the string <code class="docutils literal notranslate"><span class="pre">CONFIG_XYZ</span></code> and press ENTER. |
| It will show you not only where to find the configuration item, but |
| also all of the dependencies related to the configuration item.</p> |
| </section> |
| <section id="reveal-hidden-configuration-options"> |
| <h4>Reveal Hidden Configuration Options<a class="headerlink" href="#reveal-hidden-configuration-options" title="Permalink to this heading"></a></h4> |
| <p>If you type <code class="docutils literal notranslate"><span class="pre">Z</span></code>, then <code class="docutils literal notranslate"><span class="pre">kconfig-mconf</span></code> will change what is displayed. |
| Normally, only enabled features that have all of their dependencies met |
| are displayed. That is, of course, not very useful if you would like to |
| discover new options or if you are looking for an option and do not |
| realize that the dependencies have not yet been selected and, hence, it |
| is not displayed.</p> |
| <p>But if you enter <code class="docutils literal notranslate"><span class="pre">Z</span></code>, then every option will be shown, whether or not its |
| dependencies have been met. You can then see everything that could be |
| selected with the right dependency selections. These additional options |
| will be shown the <code class="docutils literal notranslate"><span class="pre">-</span></code> for the selection and for the value (since it |
| cannot be selected and has no value). About all you do is to select |
| the <code class="docutils literal notranslate"><span class="pre"><Help></span></code> option to see what the dependencies are.</p> |
| </section> |
| <section id="make-sure-that-you-are-on-the-right-platform"> |
| <h4>Make Sure that You are on the Right Platform<a class="headerlink" href="#make-sure-that-you-are-on-the-right-platform" title="Permalink to this heading"></a></h4> |
| <p>Saved configurations may run on Linux, Cygwin (32- or 64-bit), or other |
| platforms. The platform characteristics can be changed use <code class="docutils literal notranslate"><span class="pre">make</span> <span class="pre">menuconfig</span></code>. Sometimes this can be confusing due to the differences |
| between the platforms. Enter <code class="docutils literal notranslate"><span class="pre">sethost.sh</span></code></p> |
| <p>sethost.sh is a simple script that changes a configuration to your |
| host platform. This can greatly simplify life if you use many different |
| configurations. For example, if you are running on Linux and you |
| configure like this:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>tools/configure.sh board:configuration |
| </pre></div> |
| </div> |
| <p>The you can use the following command to both (1) make sure that the |
| configuration is up to date, AND (2) the configuration is set up |
| correctly for Linux:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>tools/sethost.sh -l |
| </pre></div> |
| </div> |
| <p>Or, if you are on a Windows/Cygwin 64-bit platform:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>tools/sethost.sh -c |
| </pre></div> |
| </div> |
| <p>Or, for MSYS/MSYS2:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>tools/sethost.sh -g |
| </pre></div> |
| </div> |
| <p>Other options are available from the help option built into the |
| script. You can see all options with:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>tools/sethost.sh -h |
| </pre></div> |
| </div> |
| <p>Recently, the options to the configure.sh (and configure.bat) scripts have |
| been extended so that you both setup the configuration, select for the host |
| platform that you use, and uncompress and refresh the defconfig file all in |
| one command like:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>tools/configure.sh -l board:configuration |
| </pre></div> |
| </div> |
| <p>For a Linux host or for a Windows/Cygwin host:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>tools/configure.sh -c board:configuration |
| </pre></div> |
| </div> |
| <p>Other options are available from the help option built into the |
| script. You can see all options with:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>tools/configure.sh -h |
| </pre></div> |
| </div> |
| </section> |
| <section id="comparing-two-configurations"> |
| <h4>Comparing Two Configurations<a class="headerlink" href="#comparing-two-configurations" title="Permalink to this heading"></a></h4> |
| <p>If you try to compare two configurations using ‘diff’, you will probably |
| not be happy with the result. There are superfluous things added to |
| the configuration files that make comparisons with the human eye |
| difficult.</p> |
| <p>There is a tool at nuttx/tools/cmpconfig.c that can be built to simplify |
| these comparisons. The output from this difference tool will show only |
| the meaningful differences between two configuration files. This tool is |
| built as follows:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>cd nuttx/tools |
| make -f Makefile.host |
| </pre></div> |
| </div> |
| <p>This will create a program called ‘cmpconfig’ or ‘comconfig.exe’ on Windows.</p> |
| <p>Why would you want to compare two configuration files? Here are a few |
| of the reasons why I do this</p> |
| <ol class="arabic simple"> |
| <li><p>When I create a new configuration I usually base it on an older |
| configuration and I want to know, “What are the options that I need to |
| change to add the new feature to the older configurations?” For example, |
| suppose that I have a boardA/nsh configuration and I want to create a |
| boardA/nxwm configuration. Suppose I already have boardB/nsh and |
| boardB/nxwm configurations. Then by comparing the boardB/nsh with the |
| boardB/nxwm I can see the modifications that I would need to make to my |
| boardA/nsh to create a new boardA/nxwm.</p></li> |
| <li><p>But the most common reason that I use the ‘cmpconfig’ program is to |
| check the results of “refreshing” a configuration with ‘make oldconfig’ |
| (see the paragraph “Refreshing Configurations” above). The ‘make |
| oldconfig’ command will make changes to my configuration and using |
| ‘cmpconfig’, I can see precisely what those changes were and if any |
| should be of concern to me.</p></li> |
| <li><p>The ‘cmpconfig’ tool can also be useful when converting older, legacy |
| manual configurations to the current configurations based on the |
| kconfig-frontends tools. See the following paragraph.</p></li> |
| </ol> |
| </section> |
| <section id="making-defconfig-files"> |
| <h4>Making <code class="docutils literal notranslate"><span class="pre">defconfig</span></code> Files<a class="headerlink" href="#making-defconfig-files" title="Permalink to this heading"></a></h4> |
| <section id="config-files-as-defconfig-files"> |
| <h5><code class="docutils literal notranslate"><span class="pre">.config</span></code> Files as <code class="docutils literal notranslate"><span class="pre">defconfig</span></code> Files:<a class="headerlink" href="#config-files-as-defconfig-files" title="Permalink to this heading"></a></h5> |
| <p>The minimum <code class="docutils literal notranslate"><span class="pre">defconfig</span></code> file is simply the generated <code class="docutils literal notranslate"><span class="pre">.config</span></code> file with |
| CONFIG_APPS_DIR setting removed or commented out. That setting provides |
| the name and location of the <code class="docutils literal notranslate"><span class="pre">apps/</span></code> directory relative to the <code class="docutils literal notranslate"><span class="pre">nuttx</span></code> build |
| directory. The default is <code class="docutils literal notranslate"><span class="pre">../apps/</span></code>, however, the apps directory may be |
| any other location and may have a different name. For example, the name |
| of versioned NuttX releases are always in the form <code class="docutils literal notranslate"><span class="pre">apps-xx.yy</span></code> where <code class="docutils literal notranslate"><span class="pre">xx.yy</span></code> |
| is the version number.</p> |
| </section> |
| <section id="finding-the-apps-directory-path"> |
| <h5>Finding the <code class="docutils literal notranslate"><span class="pre">apps/</span></code> Directory Path:<a class="headerlink" href="#finding-the-apps-directory-path" title="Permalink to this heading"></a></h5> |
| <p>When the default configuration is installed using one of the scripts or |
| programs in the NuttX tools directory, there will be an option to provide |
| the path to the <code class="docutils literal notranslate"><span class="pre">apps/</span></code> directory. If not provided, then the configure tool |
| will look around and try to make a reasonable decision about where the |
| <code class="docutils literal notranslate"><span class="pre">apps/</span></code> directory is located.</p> |
| </section> |
| <section id="compressed-defconfig-files"> |
| <h5>Compressed <code class="docutils literal notranslate"><span class="pre">defconfig</span></code> Files:<a class="headerlink" href="#compressed-defconfig-files" title="Permalink to this heading"></a></h5> |
| <p>The <code class="docutils literal notranslate"><span class="pre">Makefile</span></code> also supports an option to generate very small <code class="docutils literal notranslate"><span class="pre">defconfig</span></code> |
| files. The <code class="docutils literal notranslate"><span class="pre">.config</span></code> files are quite large and complex. But most of the |
| settings in the <code class="docutils literal notranslate"><span class="pre">.config</span></code> file simply have the default settings from the |
| <code class="docutils literal notranslate"><span class="pre">Kconfig</span></code> files. These <code class="docutils literal notranslate"><span class="pre">.config</span></code> files can be converted into small <code class="docutils literal notranslate"><span class="pre">defconfig</span></code> |
| file:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>make savedefconfig |
| </pre></div> |
| </div> |
| <p>That make target will generate a defconfig file in the top-level |
| directory. The size reduction is really quite remarkable:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>wc -l .config defconfig |
| 1085 .config |
| 82 defconfig |
| 1167 total |
| </pre></div> |
| </div> |
| <p>In order to be usable, the <code class="docutils literal notranslate"><span class="pre">.config</span></code> file installed from the compressed |
| defconfig file must be reconstituted using:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>make olddefconfig |
| </pre></div> |
| </div> |
| <blockquote> |
| <div><p><strong>NOTE 1</strong>: Only compressed defconfig files are retained in the NuttX repository. |
| All patches and PRs that attempt to add or modify a defconfig file MUST |
| use the compressed defconfig format as created by ‘make savdefconfig.’</p> |
| </div></blockquote> |
| <blockquote> |
| <div><p><strong>NOTE 2</strong>: When ‘make savedefconfig’ runs it will try several things some of |
| which are expected to fail. In these cases you will see an error message |
| from make followed by “(ignored).” You should also ignore these messages</p> |
| </div></blockquote> |
| <p><strong>CAUTION</strong>: This size reduction was accomplished by removing all setting |
| from the <code class="docutils literal notranslate"><span class="pre">.config</span></code> file that were at the default value. <code class="docutils literal notranslate"><span class="pre">make</span> <span class="pre">olddefconfig</span></code> |
| can regenerate the original <code class="docutils literal notranslate"><span class="pre">.config</span></code> file by simply restoring those default |
| settings. The underlying assumption here is, of course, that the default |
| settings do not change. If the default settings change, and they often |
| do, then the original <code class="docutils literal notranslate"><span class="pre">.config</span></code> may not be reproducible.</p> |
| <p>So if your project requires 100% reproducibility over a long period of |
| time, you make want to save the complete <code class="docutils literal notranslate"><span class="pre">.config</span></code> files vs. the standard, |
| compressed <code class="docutils literal notranslate"><span class="pre">defconfig</span></code> file.</p> |
| </section> |
| <section id="configuring-with-compressed-defconfig-files"> |
| <h5>Configuring with “Compressed” defconfig Files:<a class="headerlink" href="#configuring-with-compressed-defconfig-files" title="Permalink to this heading"></a></h5> |
| <p>As described above <code class="docutils literal notranslate"><span class="pre">defconfig</span></code>, all NuttX <code class="docutils literal notranslate"><span class="pre">defconfig</span></code> files are compressed |
| using <code class="docutils literal notranslate"><span class="pre">make</span> <span class="pre">savedeconfig</span></code>. These compressed <code class="docutils literal notranslate"><span class="pre">defconfig</span></code> files are |
| generally not fully usable as they are and may not build the target |
| binaries that you want because the compression process removed all of |
| the default settings from the <code class="docutils literal notranslate"><span class="pre">defconfig</span></code> file. To restore the default |
| settings, you should run the following after configuring:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>make olddefconfig |
| </pre></div> |
| </div> |
| <p>That will restore the the missing defaulted values.</p> |
| <p>Using this command after configuring is generally a good practice anyway: |
| Even if the <code class="docutils literal notranslate"><span class="pre">defconfig</span></code> files are not “compressed” in this fashion, the |
| <code class="docutils literal notranslate"><span class="pre">defconfig</span></code> file may be old and the only way to assure that the installed |
| <code class="docutils literal notranslate"><span class="pre">.config</span></code> is is up to date is via <code class="docutils literal notranslate"><span class="pre">make</span> <span class="pre">oldconfig</span></code> or <code class="docutils literal notranslate"><span class="pre">make</span> <span class="pre">olddefconfig</span></code>. |
| See the paragraph above entitled “Refreshing Configurations” for |
| additional information.</p> |
| </section> |
| </section> |
| <section id="incompatibilities-with-older-configurations"> |
| <h4>Incompatibilities with Older Configurations<a class="headerlink" href="#incompatibilities-with-older-configurations" title="Permalink to this heading"></a></h4> |
| <p><strong>WARNING</strong></p> |
| <p>The current NuttX build system supports <em>only</em> the new compressed, |
| <code class="docutils literal notranslate"><span class="pre">defconfig</span></code> configuration files generated using the <code class="docutils literal notranslate"><span class="pre">kconfig-frontends</span></code> tools |
| as described in the preceding section. Support for the older, legacy, |
| manual configurations was eliminated in NuttX 7.0; support for |
| uncompressed <code class="docutils literal notranslate"><span class="pre">.config-files-as-defconfig</span></code> files was eliminated after |
| NuttX-7.21. All configurations must now be done using the |
| <code class="docutils literal notranslate"><span class="pre">kconfig-frontends</span></code> tool. The older manual configurations and the new |
| <code class="docutils literal notranslate"><span class="pre">kconfig-frontends</span></code> configurations are not compatible. Old legacy |
| configurations can <em>not</em> be used with the <code class="docutils literal notranslate"><span class="pre">kconfig-frontends</span></code> tool and, |
| hence, cannot be used with releases of NuttX 7.0 and beyond:</p> |
| <p>If you run <code class="docutils literal notranslate"><span class="pre">make</span> <span class="pre">menuconfig</span></code> with a legacy configuration the resulting |
| configuration will probably not be functional.</p> |
| <blockquote> |
| <div><p>Q: How can I tell if a configuration is a new kconfig-frontends |
| configuration or an older, manual configuration?</p> |
| <p>A: Only old, manual configurations will have an appconfig file</p> |
| <p>Q: How can I convert a older, manual configuration into a new, |
| kconfig-frontends toolchain.</p> |
| <p>A: Refer to <a class="reference external" href="https://cwiki.apache.org/confluence/display/NUTTX/Converting+Legacy+Configurations+to+Use+kconfig-mconf">https://cwiki.apache.org/confluence/display/NUTTX/Converting+Legacy+Configurations+to+Use+kconfig-mconf</a></p> |
| </div></blockquote> |
| <p><strong>WARNING</strong></p> |
| <p>As described above, whenever you use a configuration, you really should |
| always refresh the configuration with the following command <em>before</em> you |
| make NuttX:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>make oldconfig |
| </pre></div> |
| </div> |
| <p>OR</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>make olddefconfig |
| </pre></div> |
| </div> |
| <p>This will make sure that the configuration is up-to-date in the event that |
| it has lapsed behind the current NuttX development (see the paragraph |
| “Refreshing Configurations” above). But this only works with <em>new</em> |
| configuration files created with the kconfig-frontends tools.</p> |
| <p>Further, this step is <em>NOT</em> optional with the new, compressed defconfig |
| files. It is a necessary step that will also uncompress the defconfig |
| file, regenerating the <code class="docutils literal notranslate"><span class="pre">.config</span></code> and making it usable for NuttX builds.</p> |
| <p>Never do <code class="docutils literal notranslate"><span class="pre">make</span> <span class="pre">oldconfig</span></code> (OR <code class="docutils literal notranslate"><span class="pre">make</span> <span class="pre">menuconfig</span></code>) on a configuration that |
| has not been converted to use the kconfig-frontends tools! This will |
| damage your configuration (see |
| <a class="reference external" href="https://cwiki.apache.org/confluence/display/NUTTX/Converting+Legacy+Configurations+to+Use+kconfig-mconf">https://cwiki.apache.org/confluence/display/NUTTX/Converting+Legacy+Configurations+to+Use+kconfig-mconf</a>).</p> |
| </section> |
| <section id="nuttx-configuration-tool-under-dos"> |
| <h4>NuttX Configuration Tool under DOS<a class="headerlink" href="#nuttx-configuration-tool-under-dos" title="Permalink to this heading"></a></h4> |
| <p>Recent versions of NuttX support building NuttX from a native Windows |
| console window (see <em>Native Windows Build</em> below). But <code class="docutils literal notranslate"><span class="pre">kconfig-frontends</span></code> |
| is a Linux tool. At one time this was a problem for Windows users, but |
| now there are two specially modified versions of the <code class="docutils literal notranslate"><span class="pre">kconfig-frontends</span></code> |
| tools that can be used. One can be found here: |
| <a class="reference external" href="http://uvc.de/posts/linux-kernel-configuration-tool-kconfig-under-windows.html">http://uvc.de/posts/linux-kernel-configuration-tool-kconfig-under-windows.html</a></p> |
| <p>The configuration steps of the most recent versions of NuttX require the |
| <code class="docutils literal notranslate"><span class="pre">kconfig-tweak</span></code> tool that is not not available in the the above. However, |
| there has been an update to this <code class="docutils literal notranslate"><span class="pre">Kconfig</span></code> Windows tools that does include |
| <code class="docutils literal notranslate"><span class="pre">kconfig-tweak</span></code>: http://reclonelabs.com/more-kconfig-awesomeness-for-windows/</p> |
| <p>Source code is available here: <a class="reference external" href="https://github.com/reclone/kconfig-frontends-win32">https://github.com/reclone/kconfig-frontends-win32</a> |
| and <a class="reference external" href="https://github.com/reclone/kconfig-frontends-win32/releases">https://github.com/reclone/kconfig-frontends-win32/releases</a></p> |
| <p>It is also possible to use the version of <code class="docutils literal notranslate"><span class="pre">kconfig-frontends</span></code> built |
| under Cygwin outside of the Cygwin <em>sandbox</em> in a native Windows |
| environment:</p> |
| <ol class="arabic"> |
| <li><p>You can run the configuration tool using Cygwin. However, the |
| Cygwin <code class="docutils literal notranslate"><span class="pre">Win.mk</span></code> will complain so to do this will, you have |
| to manually edit the <code class="docutils literal notranslate"><span class="pre">.config</span></code> file:</p> |
| <p>a. Delete the line: <code class="docutils literal notranslate"><span class="pre">CONFIG_WINDOWS_NATIVE=y</span></code></p> |
| <p>b. Change the apps/ directory path, <code class="docutils literal notranslate"><span class="pre">CONFIG_APPS_DIR</span></code> to use Unix |
| style delimiters. For example, change <code class="docutils literal notranslate"><span class="pre">..\apps</span></code> to <code class="docutils literal notranslate"><span class="pre">../apps</span></code></p> |
| <p>And of course, after you use the configuration tool you need to |
| restore <code class="docutils literal notranslate"><span class="pre">CONFIG_WINDOWS_NATIVE=y</span></code> and the correct <code class="docutils literal notranslate"><span class="pre">CONFIG_APPS_DIR</span></code>.</p> |
| </li> |
| <li><p>You can, with some effort, run the Cygwin <code class="docutils literal notranslate"><span class="pre">kconfig-mconf</span></code> tool |
| directly in the Windows console window. In this case, you do not |
| have to modify the <code class="docutils literal notranslate"><span class="pre">.config</span></code> file, but there are other complexities:</p> |
| <p>a. You need to temporarily set the Cygwin directories in the PATH |
| variable then run <code class="docutils literal notranslate"><span class="pre">kconfig-mconf</span></code> manually like:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span> kconfig-mconf Kconfig |
| </pre></div> |
| </div> |
| <p>There is a Windows batch file at <code class="docutils literal notranslate"><span class="pre">tools/kconfig.bat</span></code> that automates |
| these steps:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>tools/kconfig menuconfig |
| </pre></div> |
| </div> |
| <p>b. There is an issue with accessing DOS environment variables from |
| the Cygwin <code class="docutils literal notranslate"><span class="pre">kconfig-mconf</span></code> running in the Windows console. The |
| following change to the top-level <code class="docutils literal notranslate"><span class="pre">Kconfig</span></code> file seems to work |
| around these problems:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span> config APPSDIR |
| string |
| - option env="APPSDIR" |
| + default "../apps" |
| </pre></div> |
| </div> |
| </li> |
| </ol> |
| </section> |
| </section> |
| <section id="toolchains"> |
| <h3>TOOLCHAINS<a class="headerlink" href="#toolchains" title="Permalink to this heading"></a></h3> |
| <section id="cross-development-toolchains"> |
| <h4>Cross-Development Toolchains<a class="headerlink" href="#cross-development-toolchains" title="Permalink to this heading"></a></h4> |
| <p>In order to build NuttX for your board, you will have to obtain a cross- |
| compiler to generate code for your target CPU. For each board, |
| configuration, there is a <code class="docutils literal notranslate"><span class="pre">README.txt</span></code> file (at |
| <code class="docutils literal notranslate"><span class="pre">boards/<arch-name>/<chip-name>/<board-name>/README.txt</span></code>). |
| That README file contains suggestions and information about appropriate |
| tools and development environments for use with your board.</p> |
| <p>In any case, the PATH environment variable will need to be updated to |
| include the location where the build can find the toolchain binaries.</p> |
| </section> |
| <section id="nuttx-buildroot-toolchain"> |
| <h4>NuttX Buildroot Toolchain<a class="headerlink" href="#nuttx-buildroot-toolchain" title="Permalink to this heading"></a></h4> |
| <p>For many configurations, a DIY set of tools is available for NuttX. These |
| tools can be downloaded from the NuttX Bitbucket.org file repository. After |
| unpacking the buildroot tarball, you can find instructions for building |
| the tools in the <code class="docutils literal notranslate"><span class="pre">buildroot/boards/README.txt</span></code> file.</p> |
| <p>Check the README.txt file in the configuration directory for your board |
| to see if you can use the buildroot toolchain with your board (this |
| README.txt file is located in |
| <code class="docutils literal notranslate"><span class="pre">boards/<arch-name>/<chip-name>/<board-name>/README.txt</span></code>).</p> |
| <p>This toolchain is available for both the Linux and Cygwin development |
| environments.</p> |
| <p>Advantages: (1) NuttX header files are built into the tool chain, |
| and (2) related support tools like NXFLAT tools, the ROMFS |
| genromfs tools, and the kconfig-frontends tools can be built into your |
| toolchain.</p> |
| <p>Disadvantages: This tool chain is not was well supported as some other |
| toolchains. GNU tools are not my priority and so the buildroot tools |
| often get behind. For example, until recently there was no EABI support |
| in the NuttX buildroot toolchain for ARM.</p> |
| <p>NOTE: For Cortex-M3/4, there are OABI and EABI versions of the buildroot |
| toolchains. If you are using the older OABI toolchain the prefix for |
| the tools will be <code class="docutils literal notranslate"><span class="pre">arm-nuttx-elf-</span></code>; for the EABI toolchain the prefix will |
| be <code class="docutils literal notranslate"><span class="pre">arm-nuttx-eabi-</span></code>. If you are using the older OABI toolchain with |
| an ARM Cortex-M3/4, you will need to set CONFIG_ARM_TOOLCHAIN_BUILDROOT_OABI |
| in the <code class="docutils literal notranslate"><span class="pre">.config</span></code> file in order to pick the right tool prefix.</p> |
| <p>If the make system ever picks the wrong prefix for your toolchain, you |
| can always specify the prefix on the command to override the default |
| like:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>make CROSSDEV=arm-nuttx-elf |
| </pre></div> |
| </div> |
| </section> |
| </section> |
| <section id="shells"> |
| <h3>SHELLS<a class="headerlink" href="#shells" title="Permalink to this heading"></a></h3> |
| <p>The NuttX build relies on some shell scripts. Some are inline in the |
| Makefiles and many are executable scripts in the <code class="docutils literal notranslate"><span class="pre">tools/</span></code>. directory. The |
| scripts were all developed using bash and many contain bash shell |
| dependencies.</p> |
| <p>Most of the scripts begin with <code class="docutils literal notranslate"><span class="pre">#!/bin/bash</span></code> to specifically select the |
| bash shell. Some still have <code class="docutils literal notranslate"><span class="pre">#!/bin/sh</span></code> but I haven’t heard any complaints |
| so these must not have bash dependencies.</p> |
| <p>There are two shell issues that I have heard of:</p> |
| <ol class="arabic"> |
| <li><p>Linux where <code class="docutils literal notranslate"><span class="pre">/bin/sh</span></code> refers to an incompatible shell (like <code class="docutils literal notranslate"><span class="pre">ksh</span></code> or <code class="docutils literal notranslate"><span class="pre">csh</span></code>).</p> |
| <p>In this case, bash is probably available and the <code class="docutils literal notranslate"><span class="pre">#!/bin/bash</span></code> at the |
| beginning of the file should do the job. If any scripts with <code class="docutils literal notranslate"><span class="pre">#!/bin/sh</span></code> |
| fail, try changing that to <code class="docutils literal notranslate"><span class="pre">#!/bin/bash</span></code> and let me know about the change.</p> |
| </li> |
| <li><p>FreeBSD with the Bourne Shell and no bash shell.</p> |
| <p>The other, reverse case has also been reported on FreeBSD setups that |
| have the Bourne shell, but not bash. In this base, <code class="docutils literal notranslate"><span class="pre">#!/bin/bash</span></code> fails |
| but <code class="docutils literal notranslate"><span class="pre">#!/bin/sh</span></code> works okay. My recommendation in this case is to create |
| a symbolic link at <code class="docutils literal notranslate"><span class="pre">/bin/bash</span></code> that refers to the Bourne shell.</p> |
| <p>There may still be issues, however, with certain the <code class="docutils literal notranslate"><span class="pre">bash</span></code>-centric scripts |
| that will require modifications.</p> |
| </li> |
| </ol> |
| </section> |
| <section id="building-nuttx"> |
| <h3>BUILDING NUTTX<a class="headerlink" href="#building-nuttx" title="Permalink to this heading"></a></h3> |
| <section id="building"> |
| <h4>Building<a class="headerlink" href="#building" title="Permalink to this heading"></a></h4> |
| <p>NuttX builds in-place in the source tree. You do not need to create |
| any special build directories. Assuming that your Make.defs is setup |
| properly for your tool chain and that PATH environment variable contains |
| the path to where your cross-development tools are installed, the |
| following steps are all that are required to build NuttX:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>cd {TOPDIR} |
| make |
| </pre></div> |
| </div> |
| <p>At least one configuration (eagle100) requires additional command line |
| arguments on the make command. Read |
| <code class="docutils literal notranslate"><span class="pre">{TOPDIR}/boards/<arch-name>/<chip-name>/<board-name>/README.txt</span></code> to see |
| if that applies to your target.</p> |
| </section> |
| <section id="re-building"> |
| <h4>Re-building<a class="headerlink" href="#re-building" title="Permalink to this heading"></a></h4> |
| <p>Re-building is normally simple – just type make again.</p> |
| <p>But there are some things that can “get you” when you use the Cygwin |
| development environment with Windows native tools. The native Windows |
| tools do not understand Cygwin’s symbolic links, so the NuttX make system |
| does something weird: It copies the configuration directories instead of |
| linking to them (it could, perhaps, use the NTFS <code class="docutils literal notranslate"><span class="pre">mklink</span></code> command, but it |
| doesn’t).</p> |
| <p>A consequence of this is that you can easily get confused when you edit |
| a file in one of the linked (i.e., copied) directories, re-build NuttX, |
| and then not see your changes when you run the program. That is because |
| build is still using the version of the file in the copied directory, not |
| your modified file!</p> |
| <p>Older versions of NuttX did not support dependencies in this |
| configuration. So a simple work around this annoying behavior in this |
| case was the following when you re-build:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span> make clean_context all |
| </pre></div> |
| </div> |
| <p>This ‘make’ command will remove of the copied directories, re-copy them, |
| then make NuttX.</p> |
| <p>However, more recent versions of NuttX do support dependencies for the |
| Cygwin build. As a result, the above command will cause everything to be |
| rebuilt (because it removes and will cause recreating the |
| <code class="docutils literal notranslate"><span class="pre">include/nuttx/config.h</span></code> header file). A much less gracefully but still |
| effective command in this case is the following for the ARM configuration:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>rm -rf arch/arm/src/chip arch/arm/src/board |
| </pre></div> |
| </div> |
| <p>This “kludge” simple removes the copied directories. These directories |
| will be re-created when you do a normal ‘make’ and your edits will then be |
| effective.</p> |
| </section> |
| <section id="build-targets-and-options"> |
| <h4>Build Targets and Options<a class="headerlink" href="#build-targets-and-options" title="Permalink to this heading"></a></h4> |
| <section id="build-targets"> |
| <h5>Build Targets<a class="headerlink" href="#build-targets" title="Permalink to this heading"></a></h5> |
| <p>Below is a summary of the build targets available in the top-level |
| NuttX Makefile:</p> |
| <ul> |
| <li><p><code class="docutils literal notranslate"><span class="pre">all</span></code></p> |
| <p>The default target builds the NuttX executable in the selected output |
| formats.</p> |
| </li> |
| <li><p><code class="docutils literal notranslate"><span class="pre">clean</span></code></p> |
| <p>Removes derived object files, archives, executables, and temporary |
| files, but retains the configuration and context files and directories.</p> |
| </li> |
| <li><p><code class="docutils literal notranslate"><span class="pre">distclean</span></code></p> |
| <p>Does ‘clean’ then also removes all configuration and context files. |
| This essentially restores the directory structure to its original, |
| unconfigured stated.</p> |
| </li> |
| </ul> |
| <p>Application housekeeping targets. The APPDIR variable refers to the user |
| application directory. A sample <code class="docutils literal notranslate"><span class="pre">apps/</span></code> directory is included with NuttX, |
| however, this is not treated as part of NuttX and may be replaced with a |
| different application directory. For the most part, the application |
| directory is treated like any other build directory in the <code class="docutils literal notranslate"><span class="pre">Makefile</span></code> script. |
| However, as a convenience, the following targets are included to support |
| housekeeping functions in the user application directory from the NuttX |
| build directory.</p> |
| <ul> |
| <li><p><code class="docutils literal notranslate"><span class="pre">apps_clean</span></code></p> |
| <p>Perform the clean operation only in the user application directory</p> |
| </li> |
| <li><p><code class="docutils literal notranslate"><span class="pre">apps_distclean</span></code></p> |
| <p>Perform the distclean operation only in the user application directory. |
| The apps/.config file is preserved so that this is not a “full” distclean |
| but more of a configuration “reset” for the application directory.</p> |
| </li> |
| <li><p><code class="docutils literal notranslate"><span class="pre">export</span></code></p> |
| <p>The export target will package the NuttX libraries and header files into |
| an exportable package. Caveats: (1) These needs some extension for the KERNEL |
| build. (2) The logic in tools/mkexport.sh only supports GCC and, for example, |
| explicitly assumes that the archiver is ‘ar’</p> |
| </li> |
| <li><p><code class="docutils literal notranslate"><span class="pre">flash</span></code> (or <code class="docutils literal notranslate"><span class="pre">download</span></code> : DEPRECATED)</p> |
| <p>This is a helper target that will rebuild NuttX and flash it to the target |
| system in one step. The operation of this target depends completely upon |
| implementation of the FLASH command in the user Make.defs file. It will |
| generate an error if the FLASH command is not defined.</p> |
| </li> |
| </ul> |
| <p>The following targets are used internally by the make logic but can be invoked |
| from the command under certain conditions if necessary.</p> |
| <ul> |
| <li><p><code class="docutils literal notranslate"><span class="pre">depend</span></code></p> |
| <p>Create build dependencies. (NOTE: There is currently no support for build |
| dependencies under Cygwin using Windows-native toolchains.)</p> |
| </li> |
| <li><p><code class="docutils literal notranslate"><span class="pre">context</span></code></p> |
| <p>The context target is invoked on each target build to assure that NuttX is |
| properly configured. The basic configuration steps include creation of the |
| the <code class="docutils literal notranslate"><span class="pre">config.h</span></code> and <code class="docutils literal notranslate"><span class="pre">version.h</span></code> header files in the <code class="docutils literal notranslate"><span class="pre">include/nuttx</span></code> directory and |
| the establishment of symbolic links to configured directories.</p> |
| </li> |
| <li><p><code class="docutils literal notranslate"><span class="pre">clean_context</span></code></p> |
| <p>This is part of the <code class="docutils literal notranslate"><span class="pre">distclean</span></code> target. It removes all of the header files |
| and symbolic links created by the context target.</p> |
| </li> |
| </ul> |
| </section> |
| <section id="build-options"> |
| <h5>Build Options<a class="headerlink" href="#build-options" title="Permalink to this heading"></a></h5> |
| <p>Of course, the value any make variable an be overridden from the make command |
| line. However, there is one particular variable assignment option that may |
| be useful to you:</p> |
| <ul> |
| <li><p><code class="docutils literal notranslate"><span class="pre">V=1</span></code></p> |
| <p>This is the build “verbosity flag.” If you specify <code class="docutils literal notranslate"><span class="pre">V=1</span></code> on the make command |
| line, you will see the exact commands used in the build. This can be very |
| useful when adding new boards or tracking down compile time errors and |
| warnings (Contributed by Richard Cochran).</p> |
| </li> |
| </ul> |
| </section> |
| </section> |
| <section id="native-windows-build"> |
| <h4>Native Windows Build<a class="headerlink" href="#native-windows-build" title="Permalink to this heading"></a></h4> |
| <p>The beginnings of a Windows native build are in place but still not often |
| used as of this writing. The build was functional but because of lack of |
| use may find some issues to be resolved with this build configuration.</p> |
| <p>The windows native build logic initiated if CONFIG_WINDOWS_NATIVE=y is |
| defined in the NuttX configuration file:</p> |
| <p>This build:</p> |
| <ul class="simple"> |
| <li><p>Uses all Windows style paths</p></li> |
| <li><p>Uses primarily Windows batch commands from cmd.exe, with</p></li> |
| <li><p>A few extensions from GNUWin32</p></li> |
| </ul> |
| <p>In this build, you cannot use a Cygwin or MSYS shell. Rather the build must |
| be performed in a Windows console window. Here is a better terminal than the |
| standard issue, CMD.exe terminal: ConEmu which can be downloaded from: |
| <a class="reference external" href="https://sourceforge.net/projects/conemu/">https://sourceforge.net/projects/conemu/</a> or <a class="reference external" href="https://conemu.github.io/">https://conemu.github.io/</a>.</p> |
| <p>Build Tools. The build still relies on some Unix-like commands. I use |
| the GNUWin32 tools that can be downloaded from <a class="reference external" href="http://gnuwin32.sourceforge.net/">http://gnuwin32.sourceforge.net/</a> |
| using the <em>Download all</em> selection. Individual packages can be download |
| instead if you know what you are doing and want a faster download (No, I |
| can’t tell you which packages you should or should not download).</p> |
| <p>NOTE: It should be possible to use Cygwin or MSYS2 in place of the GNUWin32 |
| tools. There are, however, complexities in doing that because those tools |
| depend on the shell environment and use DLLs that are not found (at least |
| not without the correct setup).</p> |
| <p>Host Compiler: I use the MingGW GCC compiler which can be downloaded from |
| <a class="reference external" href="http://www.mingw.org/">http://www.mingw.org/</a>. If you are using GNUWin32, then it is recommended |
| the you not install the optional MSYS components as there may be conflicts.</p> |
| <p>Kconfig-frontends: See the section entitled “NuttX Configuration Tool |
| under DOS” for information about installing the <code class="docutils literal notranslate"><span class="pre">kconfig-frontend</span></code> tools to |
| run natively under Windows.</p> |
| <p>This capability should still be considered a work in progress because:</p> |
| <ol class="arabic simple"> |
| <li><p>It has not been verified on all targets and tools, and</p></li> |
| <li><p>it still lacks some of the creature-comforts of the more mature |
| environments.</p></li> |
| </ol> |
| </section> |
| <section id="installing-gnuwin32"> |
| <h4>Installing GNUWin32<a class="headerlink" href="#installing-gnuwin32" title="Permalink to this heading"></a></h4> |
| <p>The Windows native build will depend upon a few Unix-like tools that can be |
| provided either by MSYS or GNUWin32. The GNUWin32 are available from |
| <a class="reference external" href="http://gnuwin32.sourceforge.net/">http://gnuwin32.sourceforge.net/</a>. GNUWin32 provides ports of tools with a |
| GPL or similar open source license to modern MS-Windows (Microsoft Windows |
| 2000 / XP / 2003 / Vista / 2008 / 7). See |
| <a class="reference external" href="http://gnuwin32.sourceforge.net/packages.html">http://gnuwin32.sourceforge.net/packages.html</a> for a list of all of the tools |
| available in the GNUWin32 package.</p> |
| <p>The SourceForge project is located here: |
| <a class="reference external" href="http://sourceforge.net/projects/gnuwin32/">http://sourceforge.net/projects/gnuwin32/</a>. The project is still being |
| actively supported (although some of the Windows ports have gotten very old).</p> |
| <p>Some commercial toolchains include a subset of the GNUWin32 tools in the |
| installation. My recommendation is that you download the GNUWin32 tools |
| directly from the sourceforge.net website so that you will know what you are |
| using and can reproduce your build environment.</p> |
| <p>GNUWin32 Installation Steps:</p> |
| <p>The following steps will download and execute the GNUWin32 installer.</p> |
| <ol class="arabic"> |
| <li><p>Download <code class="docutils literal notranslate"><span class="pre">GetGNUWin32-x.x.x.exe</span></code> from |
| <a class="reference external" href="http://sourceforge.net/projects/getgnuwin32/files/">http://sourceforge.net/projects/getgnuwin32/files/</a>. This is the |
| installer. The current version as of this writing is 0.6.3.</p></li> |
| <li><p>Run the installer.</p></li> |
| <li><p>Accept the license.</p></li> |
| <li><p>Select the installation directory. My recommendation is the |
| directory that contains this README file (<code class="docutils literal notranslate"><span class="pre"><this-directory></span></code>).</p></li> |
| <li><p>After running <code class="docutils literal notranslate"><span class="pre">GetGNUWin32-0.x.x.exe</span></code>, you will have a new directory |
| <code class="docutils literal notranslate"><span class="pre"><this-directory>/GetGNUWin32</span></code></p> |
| <p>Note that the GNUWin32 installer didn’t install GNUWin32. Instead, it |
| installed another, smarter downloader. That downloader is the GNUWin32 |
| package management tool developed by the Open SSL project.</p> |
| <p>The following steps probably should be performed from inside a DOS shell.</p> |
| </li> |
| <li><p>Change to the directory created by <code class="docutils literal notranslate"><span class="pre">GetGNUWin32-x.x.x.exe</span></code></p> |
| <p>cd GetGNUWin32</p> |
| </li> |
| <li><p>Execute the download.bat script. The download.bat script will download |
| about 446 packages! Enough to have a very complete Linux-like environment |
| under the DOS shell. This will take awhile. This step only downloads |
| the packages and the next step will install the packages.</p> |
| <p>download</p> |
| </li> |
| <li><p>This step will install the downloaded packages. The argument of the |
| install.bat script is the installation location. C:\gnuwin32 is the |
| standard install location:</p> |
| <p>install C:\gnuwin32</p> |
| </li> |
| </ol> |
| <p><strong>NOTE</strong>: This installation step will install <em>all</em> GNUWin32 packages… far |
| more than you will ever need. If disc space is a problem for you, you might |
| need to perform a manual installation of the individual ZIP files that you |
| will find in the <code class="docutils literal notranslate"><span class="pre"><this</span> <span class="pre">directory>/GetGNUWin32/packages</span></code> directory.</p> |
| <ol class="arabic" start="9"> |
| <li><p>Make sure that you add the GNUWin32 tools to your path variable:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span> set PATH=C:\gnuwin32\bin;%PATH% |
| </pre></div> |
| </div> |
| </li> |
| </ol> |
| <p><strong>WARNING</strong>: Make sure you have <code class="docutils literal notranslate"><span class="pre">C:\MinGW\bin</span></code> in your path before any other |
| directory that contains <code class="docutils literal notranslate"><span class="pre">libiconv-2.dll</span></code>. Apparently the <code class="docutils literal notranslate"><span class="pre">as.exe</span></code> in some |
| MinGW distributions are dependent on that DLL, and having an old |
| version of it in the path somewhere (for example GnuWin32 tools) will |
| cause as.exe to pick up the older version that doesn’t have the entry |
| point it’s looking for.</p> |
| </section> |
| </section> |
| <section id="cygwin-build-problems"> |
| <h3>CYGWIN BUILD PROBLEMS<a class="headerlink" href="#cygwin-build-problems" title="Permalink to this heading"></a></h3> |
| <section id="performance"> |
| <h4>Performance<a class="headerlink" href="#performance" title="Permalink to this heading"></a></h4> |
| <p>Build performance under Cygwin is really not so bad, certainly not as good |
| as a Linux build. However, often you will find that the performance is |
| not just bad but terrible. If you are seeing awful performance.. like two |
| or three compilations per second.. the culprit is usually your Windows |
| Anti-Virus protection interfering with the build tool program execution.</p> |
| <p>I use Cygwin quite often and I use Windows Defender. In order to get good |
| build performance, I routinely keep the Windows Defender “Virus & Threat |
| Protections Settings” screen up: I disable “Real-Time Protection” just |
| before entering ‘make’ then turn “Real-Time Protection” back on when the |
| build completes. With this additional nuisance step, I find that build |
| performance under Cygwin is completely acceptable.</p> |
| </section> |
| <section id="strange-path-problems"> |
| <h4>Strange Path Problems<a class="headerlink" href="#strange-path-problems" title="Permalink to this heading"></a></h4> |
| <p>If you see strange behavior when building under Cygwin then you may have |
| a problem with your PATH variable. For example, if you see failures to |
| locate files that are clearly present, that may mean that you are using |
| the wrong version of a tool. For example, you may not be using Cygwin’s |
| ‘make’ program at /usr/bin/make. Try:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>which make |
| /usr/bin/make |
| </pre></div> |
| </div> |
| <p>When you install some toolchains (such as Yargarto or CodeSourcery tools), |
| they may modify your PATH variable to include a path to their binaries. |
| At that location, they may have GNUWin32 versions of the tools. So you |
| might actually be using a version of make that does not understand Cygwin |
| paths.</p> |
| <p>The solution is either:</p> |
| <ol class="arabic"> |
| <li><p>Edit your PATH to remove the path to the GNUWin32 tools, or</p></li> |
| <li><p>Put /usr/local/bin, /usr/bin, and /bin at the front of your path:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>export PATH=/usr/local/bin:/usr/bin:/bin:$PATH |
| </pre></div> |
| </div> |
| </li> |
| </ol> |
| </section> |
| <section id="window-native-toolchain-issues"> |
| <h4>Window Native Toolchain Issues<a class="headerlink" href="#window-native-toolchain-issues" title="Permalink to this heading"></a></h4> |
| <p>There are many popular Windows native toolchains that may be used with NuttX. |
| Examples include CodeSourcery (for Windows), devkitARM, and several vendor- |
| provided toolchains. There are several limitations with using a and Windows |
| based toolchain in a Cygwin environment. The three biggest are:</p> |
| <ol class="arabic"> |
| <li><p>The Windows toolchain cannot follow Cygwin paths. Path conversions are |
| performed automatically in the Cygwin makefiles using the ‘cygpath’ utility |
| but you might easily find some new path problems. If so, check out ‘cygpath -w’</p></li> |
| <li><p>Windows toolchains cannot follow Cygwin symbolic links. Many symbolic links |
| are used in NuttX (e.g., include/arch). The make system works around these |
| problems for the Windows tools by copying directories instead of linking them. |
| But this can also cause some confusion for you: For example, you may edit |
| a file in a “linked” directory and find that your changes had no effect. |
| That is because you are building the copy of the file in the “fake” symbolic |
| directory. If you use a Windows toolchain, you should get in the habit of |
| making like this:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>make clean_context all |
| </pre></div> |
| </div> |
| <p>An alias in your .bashrc file might make that less painful. The rebuild |
| is not a long as you might think because there is no dependency checking |
| if you are using a native Windows toolchain. That bring us to #3:</p> |
| </li> |
| </ol> |
| </section> |
| <section id="general-pre-built-toolchain-issues"> |
| <h4>General Pre-built Toolchain Issues<a class="headerlink" href="#general-pre-built-toolchain-issues" title="Permalink to this heading"></a></h4> |
| <p>To continue with the list of “Window Native Toolchain Issues” we can add |
| the following. These, however, are really just issues that you will have |
| if you use any pre-built toolchain (vs. building the NuttX toolchain from |
| the NuttX buildroot package):</p> |
| <p>There may be incompatibilities with header files, libraries, and compiler |
| built-in functions detailed below. For the most part, these issues |
| are handled in the existing make logic. But if you are breaking new ground, |
| then you may encounter these:</p> |
| <ol class="arabic"> |
| <li><p>Header Files. Most pre-built toolchains will build with a foreign C |
| library (usually newlib, but maybe uClibc or glibc if you are using a |
| Linux toolchain). This means that the header files from the foreign |
| C library will be built into the toolchain. So if you <code class="docutils literal notranslate"><span class="pre">#include</span> <span class="pre"><stdio.h></span></code>, |
| you will get the stdio.h from the incompatible, foreign C library and |
| not the nuttx <code class="docutils literal notranslate"><span class="pre">stdio.h</span></code> (at <code class="docutils literal notranslate"><span class="pre">nuttx/include/stdio.h</span></code>) that you wanted.</p> |
| <p>This can cause confusion in the builds and you must always be |
| sure the <code class="docutils literal notranslate"><span class="pre">-nostdinc</span></code> is included in the <code class="docutils literal notranslate"><span class="pre">CFLAGS</span></code>. That will assure that |
| you take the include files only from</p> |
| </li> |
| <li><p>Libraries. What was said above header files applies to libraries. |
| You do not want to include code from the libraries of any foreign |
| C libraries built into your toolchain. If this happens you will get |
| perplexing errors about undefined symbols. To avoid these errors, |
| you will need to add <code class="docutils literal notranslate"><span class="pre">-nostdlib</span></code> to your <code class="docutils literal notranslate"><span class="pre">CFLAGS</span></code> flags to assure that |
| you only take code from the NuttX libraries.</p> |
| <p>This, however, may causes other issues for libraries in the toolchain |
| that you do want (like <code class="docutils literal notranslate"><span class="pre">libgcc.a</span></code> or <code class="docutils literal notranslate"><span class="pre">libm.a</span></code>). These are special-cased |
| in most Makefiles, but you could still run into issues of missing |
| libraries.</p> |
| </li> |
| <li><p>Built-Ins. Some compilers target a particular operating system. |
| Many people would, for example, like to use the same toolchain to |
| develop Linux and NuttX software. Compilers built for other |
| operating systems may generate incompatible built-in logic and, |
| for this reason, <code class="docutils literal notranslate"><span class="pre">-fno-builtin</span></code> should also be included in your |
| C flags</p> |
| <p>And finally you may not be able to use NXFLAT.</p> |
| </li> |
| <li><p>NXFLAT. If you use a pre-built toolchain, you will lose all support |
| for NXFLAT. NXFLAT is a binary format described in |
| Documentation/NuttXNxFlat.html. It may be possible to build |
| standalone versions of the NXFLAT tools; there are a few examples |
| of this in the buildroot repository at <a class="reference external" href="https://bitbucket.org/nuttx/buildroot">https://bitbucket.org/nuttx/buildroot</a> |
| However, it is possible that there could be interoperability issues |
| with your toolchain since they will be using different versions of |
| binutils and possibly different ABIs.</p></li> |
| </ol> |
| </section> |
| <section id="building-original-linux-boards-in-cygwin"> |
| <h4>Building Original Linux Boards in Cygwin<a class="headerlink" href="#building-original-linux-boards-in-cygwin" title="Permalink to this heading"></a></h4> |
| <p>Some default board configurations are set to build under Linux and others |
| to build under Windows with Cygwin. Various default toolchains may also |
| be used in each configuration. It is possible to change the default |
| setup. Here, for example, is what you must do in order to compile a |
| default Linux configuration in the Cygwin environment using the |
| CodeSourcery for Windows toolchain. After instantiating a “canned” |
| NuttX configuration, run the target ‘menuconfig’ and set the following |
| items:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>Build Setup->Build Host Platform->Windows |
| Build Setup->Windows Build Environment->Cygwin |
| System Type->Toolchain Selection->CodeSourcery GNU Toolchain under Windows |
| </pre></div> |
| </div> |
| <p>In Windows 7 it may be required to open the Cygwin shell as Administrator |
| (“Run As” option, right button) you find errors like “Permission denied”.</p> |
| </section> |
| <section id="recovering-from-bad-configurations"> |
| <h4>Recovering from Bad Configurations<a class="headerlink" href="#recovering-from-bad-configurations" title="Permalink to this heading"></a></h4> |
| <p>Many people make the mistake of configuring NuttX with the “canned” |
| configuration and then just typing <code class="docutils literal notranslate"><span class="pre">make</span></code> with disastrous consequences; |
| the build may fail with mysterious, uninterpretable, and irrecoverable |
| build errors. If, for example, you do this with an unmodified Linux |
| configuration in a Windows/Cgwin environment, you will corrupt the |
| build environment. The environment will be corrupted because of POSIX vs |
| Windows path issues and with issues related to symbolic links. If you |
| make the mistake of doing this, the easiest way to recover is to just |
| start over: Do <code class="docutils literal notranslate"><span class="pre">make</span> <span class="pre">distclean</span></code> to remove every trace of the corrupted |
| configuration, reconfigure from scratch, and make certain that the set |
| the configuration correctly for your platform before attempting to make |
| again.</p> |
| <p>Just fixing the configuration file after you have instantiated the bad |
| configuration with ‘make’ is not enough.</p> |
| </section> |
| </section> |
| <section id="documentation"> |
| <h3>DOCUMENTATION<a class="headerlink" href="#documentation" title="Permalink to this heading"></a></h3> |
| <p>Additional information can be found in the Documentation/ directory and |
| also in README files that are scattered throughout the source tree. The |
| documentation is in HTML and can be access by loading the following file |
| into your Web browser:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>Documentation/index.html |
| </pre></div> |
| </div> |
| <p>NuttX documentation is also available online at <a class="reference external" href="https://nuttx.apache.org/">https://nuttx.apache.org/</a>.</p> |
| <p>Below is a guide to the available README files in the NuttX source tree:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>nuttx/ |
| | |
| |- arch/ |
| | | |
| | |- arm/ |
| | | `- src |
| | | |- common |
| | | | `- README_lwl_console.txt |
| | | |- lpc214x |
| | | | `-README.txt |
| | | `- stm32l4 |
| | | `- README.txt |
| | |- renesas/ |
| | | |- include/ |
| | | | `-README.txt |
| | | |- src/ |
| | | | `-README.txt |
| | |- x86/ |
| | | |- include/ |
| | | | `-README.txt |
| | | `- src/ |
| | | `-README.txt |
| | `- z80/ |
| | | `- src/ |
| | | |- z80/README.txt |
| | | `- z180/README.txt, z180_mmu.txt |
| | `- README.txt |
| |- audio/ |
| | `-README.txt |
| |- boards/ |
| | |- arm/ |
| | | |- a1x/ |
| | | | `- pcduino-a10/ |
| | | | `- README.txt |
| | | |- am335x/ |
| | | | `- beaglebone-black/ |
| | | | `- README.txt |
| | | |- c5471/ |
| | | | `- c5471evm/ |
| | | | `- README.txt |
| | | |- cxd56xx/ |
| | | | `- spresense/ |
| | | | `- README.txt |
| | | |- dm320/ |
| | | | `- ntosd-dm320/ |
| | | | |- doc/README.txt |
| | | | `- README.txt |
| | | |- efm32/ |
| | | | |- efm32-g8xx-stk/ |
| | | | | `- README.txt |
| | | | |- efm32gg-stk3700/ |
| | | | | `- README.txt |
| | | | `- olimex-efm32g880f128-stk/ |
| | | | `- README.txt |
| | | |- imx6/ |
| | | | `- sabre-6quad/ |
| | | | `- README.txt |
| | | |- imxrt/ |
| | | | |- imxrt1050-evk/ |
| | | | | `- README.txt |
| | | | |- imxrt1060-evk/ |
| | | | | `- README.txt |
| | | | `- teensy-4.x/ |
| | | | `- README.txt |
| | | |- kinetis/ |
| | | | |- freedom-k28f/ |
| | | | | `- README.txt |
| | | | |- freedom-k64f/ |
| | | | | `- README.txt |
| | | | |- freedom-k66f/ |
| | | | | `- README.txt |
| | | | |- kwikstik-k40/ |
| | | | | `- README.txt |
| | | | |- teensy-3.x/ |
| | | | | `- README.txt |
| | | | |- twr-k60n512/ |
| | | | | `- README.txt |
| | | | `- twr-k64f120m/ |
| | | | `- README.txt |
| | | |- kl/ |
| | | | |- freedom-kl25z/ |
| | | | | `- README.txt |
| | | | |- freedom-kl26z/ |
| | | | | `- README.txt |
| | | | `- teensy-lc/ |
| | | | `- README.txt |
| | | |- lc823450/ |
| | | | `- lc823450-xgevk/ |
| | | | `- README.txt |
| | | |- lpc17xx_40xx/ |
| | | | |- lincoln60/ |
| | | | | `- README.txt |
| | | | |- lpc4088-devkit/ |
| | | | | `- README.txt |
| | | | |- lpc4088-quickstart/ |
| | | | | `- README.txt |
| | | | |- lpcxpresso-lpc1768/ |
| | | | | `- README.txt |
| | | | |- lx_cpu/ |
| | | | | `- README.txt |
| | | | |- mbed/ |
| | | | | `- README.txt |
| | | | |- mcb1700/ |
| | | | | `- README.txt |
| | | | |- olimex-lpc1766stk/ |
| | | | | `- README.txt |
| | | | |- open1788/ |
| | | | | `- README.txt |
| | | | |- pnev5180b/ |
| | | | | `- README.txt |
| | | | |- u-blox-c027/ |
| | | | | `- README.txt |
| | | | `- zkit-arm-1769/ |
| | | | `- README.txt |
| | | |- lpc214x/ |
| | | | |- mcu123-lpc214x/ |
| | | | | `- README.txt |
| | | | `- zp214xpa/ |
| | | | `- README.txt |
| | | |- lpc2378/ |
| | | | `- olimex-lpc2378/ |
| | | | `- README.txt |
| | | |- lpc31xx/ |
| | | | |- ea3131/ |
| | | | | `- README.txt |
| | | | |- ea3152/ |
| | | | | `- README.txt |
| | | | `- olimex-lpc-h3131/ |
| | | | `- README.txt |
| | | |- lpc43xx/ |
| | | | |- bambino-200e/ |
| | | | | `- README.txt |
| | | | |- lpc4330-xplorer/ |
| | | | | `- README.txt |
| | | | |- lpc4337-ws/ |
| | | | | `- README.txt |
| | | | |- lpc4357-evb/ |
| | | | | `- README.txt |
| | | | `- lpc4370-link2/ |
| | | | `- README.txt |
| | | |- lpc54xx/ |
| | | | `- lpcxpresso-lpc54628/ |
| | | | `- README.txt |
| | | |- max326xx/ |
| | | | `- max32660-evsys/ |
| | | | `- README.txt |
| | | |- moxart/ |
| | | | `- moxa/ |
| | | |- nrf52/ |
| | | | `- nrf52-generic/ |
| | | | `- README.txt |
| | | |- nuc1xx/ |
| | | | `- nutiny-nuc120/ |
| | | | `- README.txt |
| | | |- s32k1xx/ |
| | | | |- s32k118evb/ |
| | | | | `- README.txt |
| | | | |- s32k146evb/ |
| | | | | `- README.txt |
| | | | `- s32k148evb/ |
| | | | `- README.txt |
| | | |- sam34/ |
| | | | |- arduino-due/ |
| | | | | `- README.txt |
| | | | |- flipnclick-sam3x/ |
| | | | | `- README.txt |
| | | | |- sam3u-ek/ |
| | | | | `- README.txt |
| | | | |- sam4cmp-db/ |
| | | | | `- README.txt |
| | | | |- sam4e-ek/ |
| | | | | `- README.txt |
| | | | |- sam4l-xplained/ |
| | | | | `- README.txt |
| | | | |- sam4s-xplained/ |
| | | | | `- README.txt |
| | | | `- sam4s-xplained-pro/ |
| | | | `- README.txt |
| | | |- sama5/ |
| | | | |- sama5d2-xult/ |
| | | | | `- README.txt |
| | | | |- giant-board/ |
| | | | | `- README.md |
| | | | |- sama5d3x-ek/ |
| | | | | `- README.txt |
| | | | |- sama5d3-xplained/ |
| | | | | `- README.txt |
| | | | `- sama5d4-ek/ |
| | | | `- README.txt |
| | | |- samd2l2/ |
| | | | |- arduino-m0/ |
| | | | | `- README.txt |
| | | | |- samd20-xplained/ |
| | | | | `- README.txt |
| | | | |- samd21-xplained/ |
| | | | | `- README.txt |
| | | | `- saml21-xplained/ |
| | | | `- README.txt |
| | | |- samd5e5/ |
| | | | `- metro-m4/ |
| | | | `- README.txt |
| | | |- samv7/ |
| | | | |- same70-qmtech/ |
| | | | | `- README.txt |
| | | | |- same70-xplained/ |
| | | | | `- README.txt |
| | | | `- samv71-xult/ |
| | | | `- README.txt |
| | | |- stm32/ |
| | | | |- axoloti/ |
| | | | | `- README.txt |
| | | | |- b-g474e-dpow1/ |
| | | | | `- README.txt |
| | | | |- clicker2-stm32/ |
| | | | | `- README.txt |
| | | | |- cloudctrl/ |
| | | | | `- README.txt |
| | | | |- emw3162/ |
| | | | | `- README.txt |
| | | | |- fire-stm32v2/ |
| | | | | `- README.txt |
| | | | |- hymini-stm32v/ |
| | | | | `- README.txt |
| | | | |- maple/ |
| | | | | `- README.txt |
| | | | |- mikroe-stm32f4/ |
| | | | | `- README.txt |
| | | | |- nucleo-f103rb/ |
| | | | | `- README.txt |
| | | | |- nucleo-f207zg/ |
| | | | | `- README.txt |
| | | | |- nucleo-f302r8/ |
| | | | | `- README.txt |
| | | | |- nucleo-f303re/ |
| | | | | `- README.txt |
| | | | |- nucleo-f303ze/ |
| | | | | `- README.txt |
| | | | |- nucleo-f334r8/ |
| | | | | `- README.txt |
| | | | |- nucleo-f410rb/ |
| | | | | `- README.txt |
| | | | |- nucleo-f446re/ |
| | | | | `- README.txt |
| | | | |- nucleo-f4x1re/ |
| | | | | `- README.txt |
| | | | |- nucleo-l152re/ |
| | | | | `- README.txt |
| | | | |- olimexino-stm32/ |
| | | | |- olimex-stm32-e407/ |
| | | | | `- README.txt |
| | | | |- olimex-stm32-h405/ |
| | | | | `- README.txt |
| | | | |- olimex-stm32-h407/ |
| | | | | `- README.txt |
| | | | |- olimex-stm32-p107/ |
| | | | |- olimex-stm32-p207/ |
| | | | | `- README.txt |
| | | | |- olimex-stm32-p407/ |
| | | | | `- README.txt |
| | | | |- omnibusf4/ |
| | | | | `- README.txt |
| | | | |- photon/ |
| | | | | `- README.txt |
| | | | |- shenzhou/ |
| | | | | `- README.txt |
| | | | |- stm32_tiny/ |
| | | | | `- README.txt |
| | | | |- stm3210e-eval/ |
| | | | | `- README.txt |
| | | | |- stm3220g-eval/ |
| | | | | `- README.txt |
| | | | |- stm3240g-eval/ |
| | | | | `- README.txt |
| | | | |- stm32butterfly2/ |
| | | | |- stm32f103-minimum/ |
| | | | | `- README.txt |
| | | | |- stm32f334-disco/ |
| | | | | `- README.txt |
| | | | |- stm32f3discovery/ |
| | | | | `- README.txt |
| | | | |- stm32f411e-disco/ |
| | | | | `- README.txt |
| | | | |- stm32f429i-disco/ |
| | | | | `- README.txt |
| | | | |- stm32f4discovery/ |
| | | | | `- README.txt |
| | | | |- stm32ldiscovery/ |
| | | | | `- README.txt |
| | | | |- stm32vldiscovery/ |
| | | | | `- README.txt |
| | | | `- viewtool-stm32f107/ |
| | | | `- README.txt |
| | | |- stm32f0l0g0/ |
| | | | |- b-l072z-lrwan1/ |
| | | | | `- README.txt |
| | | | |- nucleo-f072rb/ |
| | | | | `- README.txt |
| | | | |- nucleo-f091rc/ |
| | | | | `- README.txt |
| | | | |- nucleo-g070rb/ |
| | | | | `- README.txt |
| | | | |- nucleo-g071rb/ |
| | | | | `- README.txt |
| | | | |- nucleo-l073rz/ |
| | | | | `- README.txt |
| | | | |- stm32f051-discovery/ |
| | | | | `- README.txt |
| | | | `- stm32f072-discovery/ |
| | | | `- README.txt |
| | | |- stm32f7/ |
| | | | |- nucleo-144/ |
| | | | | `- README.txt |
| | | | |- stm32f746g-disco/ |
| | | | | |- configs/fb/README.txt |
| | | | | |- configs/nxdemo/README.txt |
| | | | | |- configs/nxterm/README.txt |
| | | | | `- README.txt |
| | | | |- stm32f746-ws/ |
| | | | `- stm32f769i-disco/ |
| | | | `- README.txt |
| | | |- stm32h7/ |
| | | | `- nucleo-h743zi/ |
| | | | `- README.txt |
| | | |- stm32l4/ |
| | | | |- b-l475e-iot01a/ |
| | | | | `- README.txt |
| | | | |- nucleo-l432kc/ |
| | | | | `- README.txt |
| | | | |- nucleo-l452re/ |
| | | | | `- README.txt |
| | | | |- nucleo-l476rg/ |
| | | | | `- README.txt |
| | | | |- nucleo-l496zg/ |
| | | | | `- README.txt |
| | | | |- stm32l476-mdk/ |
| | | | | `- README.txt |
| | | | |- stm32l476vg-disco/ |
| | | | | `- README.txt |
| | | | `- stm32l4r9ai-disco/ |
| | | | `- README.txt |
| | | |- str71x/ |
| | | | `- olimex-strp711/ |
| | | | `- README.txt |
| | | |- tiva/ |
| | | | |- dk-tm4c129x/ |
| | | | | `- README.txt |
| | | | |- eagle100/ |
| | | | | `- README.txt |
| | | | |- ekk-lm3s9b96/ |
| | | | | `- README.txt |
| | | | |- launchxl-cc1310/ |
| | | | | `- README.txt |
| | | | |- launchxl-cc1312r1/ |
| | | | | `- README.txt |
| | | | |- lm3s6432-s2e/ |
| | | | | `- README.txt |
| | | | |- lm3s6965-ek/ |
| | | | | `- README.txt |
| | | | |- lm3s8962-ek/ |
| | | | | `- README.txt |
| | | | |- lm4f120-launchpad/ |
| | | | | `- README.txt |
| | | | |- tm4c123g-launchpad/ |
| | | | | `- README.txt |
| | | | `- tm4c1294-launchpad/ |
| | | | `- README.txt |
| | | |- tms570/ |
| | | | |- launchxl-tms57004/ |
| | | | | `- README.txt |
| | | | `- tms570ls31x-usb-kit/ |
| | | | `- README.txt |
| | | `- xmc4/ |
| | | `- xmc4500-relax/ |
| | | `- README.txt |
| | |- avr/ |
| | | |- at32uc3/ |
| | | | `- avr32dev1/ |
| | | | `- README.txt |
| | | |- at90usb/ |
| | | | |- micropendous3/ |
| | | | | `- README.txt |
| | | | `- teensy-2.0/ |
| | | | `- README.txt |
| | | `- atmega/ |
| | | |- amber/ |
| | | | `- README.txt |
| | | |- arduino-mega2560/ |
| | | | `- README.txt |
| | | `- moteino-mega/ |
| | | `- README.txt |
| | |- hc/ |
| | | `- m9s12/ |
| | | |- demo9s12ne64/ |
| | | | `- README.txt |
| | | `- ne64badge/ |
| | | `- README.txt |
| | |- mips/ |
| | | |- pic32mx/ |
| | | | |- mirtoo/ |
| | | | | `- README.txt |
| | | | |- pic32mx7mmb/ |
| | | | | `- README.txt |
| | | | |- pic32mx-starterkit/ |
| | | | | `- README.txt |
| | | | |- sure-pic32mx/ |
| | | | | `- README.txt |
| | | | `- ubw32/ |
| | | | `- README.txt |
| | | `-pic32mz/ |
| | | |- chipkit-wifire/ |
| | | | `- README.txt |
| | | |- flipnclick-pic32mz/ |
| | | | `- README.txt |
| | | `- pic32mz-starterkit/ |
| | | `- README.txt |
| | |- misoc/ |
| | | `- lm32/ |
| | | `- misoc/ |
| | | `- README.txt |
| | |- or1k/ |
| | | `- mor1kx/ |
| | | `- or1k/ |
| | | `- README.txt |
| | |- renesas/ |
| | | |- m16c/ |
| | | | `- skp16c26/ |
| | | | `- README.txt |
| | | `-sh1/ |
| | | `- us7032evb1/ |
| | | `- README.txt |
| | |- risc-v/ |
| | |- sim/ |
| | | `- sim/ |
| | | `- sim/ |
| | | |- include/README.txt |
| | | `- README.txt |
| | |- x86/ |
| | | `- qemu/ |
| | | `- qemu-i486/ |
| | | `- README.txt |
| | |- xtensa/ |
| | | `- esp32/ |
| | | `- esp32-core/ |
| | | `- README.txt |
| | |- z16/ |
| | | `- z16f/ |
| | | `- z16f2800100zcog/ |
| | | |- configs/nsh/README.txt |
| | | |- configs/ostest/README.txt |
| | | |- configs/pashello/README.txt |
| | | `- README.txt |
| | |- z80/ |
| | | |- ez80/ |
| | | | |- ez80f910200kitg/ |
| | | | | |- configs/ostest/README.txt |
| | | | | `- README.txt |
| | | | |- ez80f910200zco/ |
| | | | | |- configs/dhcpd/README.txt |
| | | | | |- configs/httpd/README.txt |
| | | | | |- configs/nettest/README.txt |
| | | | | |- configs/nsh/README.txt |
| | | | | |- configs/poll/README.txt |
| | | | | `- README.txt |
| | | | |- makerlisp/ |
| | | | | |- configs/nsh_flash/README.txt |
| | | | | |- configs/nsh_ram/README.txt |
| | | | | |- configs/sdboot/README.txt |
| | | | | `- README.txt |
| | | | `- z80x/ |
| | | | |- configs/nsh_flash/README.txt |
| | | | |- configs/nsh_ram/README.txt |
| | | | |- configs/sdboot/README.txt |
| | | | `- README.txt |
| | | |- z180/ |
| | | | `- p112/ |
| | | | `- README.txt |
| | | |- z8/ |
| | | | |- z8encore000zco/ |
| | | | | |- configs/ostest/README.txt |
| | | | | `- README.txt |
| | | | `- z8f64200100kit/ |
| | | | |- configs/ostest/README.txt |
| | | | `- README.txt |
| | | `- z80/ |
| | | `- z80sim/ |
| | | `- README.txt |
| | `-README.txt |
| |- drivers/ |
| | |- eeprom/ |
| | | `- README.txt |
| | |- lcd/ |
| | | | README.txt |
| | | `- pcf8574_lcd_backpack_readme.txt |
| | |- mtd/ |
| | | `- README.txt |
| | |- sensors/ |
| | | `- README.txt |
| | |- syslog/ |
| | | `- README.txt |
| | `- README.txt |
| |- fs/ |
| | |- binfs/ |
| | | `- README.txt |
| | |- cromfs/ |
| | | `- README.txt |
| | |- mmap/ |
| | | `- README.txt |
| | |- nxffs/ |
| | | `- README.txt |
| | |- smartfs/ |
| | | `- README.txt |
| | |- procfs/ |
| | | `- README.txt |
| | |- spiffs/ |
| | | `- README.md |
| | `- unionfs/ |
| | `- README.txt |
| |- graphics/ |
| | `- README.txt |
| |- libs/ |
| | |- README.txt |
| | |- libc/ |
| | | |- zoneinfo |
| | | | `- README.txt |
| | | `- README.txt |
| | |- libdsp/ |
| | | `- README.txt |
| | |- libnx/ |
| | | |- nxfongs |
| | | | `- README.txt |
| | | `- README.txt |
| | |- libxx/ |
| | `- README.txt |
| |- mm/ |
| | |- shm/ |
| | | `- README.txt |
| | `- README.txt |
| |- net/ |
| | |- sixlowpan |
| | | `- README.txt |
| | `- README.txt |
| |- pass1/ |
| | `- README.txt |
| |- syscall/ |
| | `- README.txt |
| `- tools/ |
| `- README.txt |
| </pre></div> |
| </div> |
| <p>Below is a guide to the available README files in the semi-optional apps/ |
| source tree:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>apps/ |
| |- examples/ |
| | |- bastest/README.txt |
| | |- json/README.txt |
| | |- pashello/README.txt |
| | `- README.txt |
| |- gpsutils/ |
| | `- minmea/README.txt |
| |- graphics/ |
| | |- tiff/README.txt |
| | `- traveler/tools/tcledit/README.txt |
| |- interpreters/ |
| | |- bas/ |
| | | `- README.txt |
| | |- ficl/ |
| | | `- README.txt |
| | `- README.txt |
| |- modbus/ |
| | `- README.txt |
| |- netutils/ |
| | |- discover/ |
| | | `- README.txt |
| | |- ftpc/ |
| | | `- README.txt |
| | |- json/ |
| | | `- README.txt |
| | |- telnetd/ |
| | | `- README.txt |
| | `- README.txt |
| |- nshlib/ |
| | `- README.txt |
| |- NxWidgets/ |
| | `- README.txt |
| |- system/ |
| | |- cdcacm/ |
| | | `- README.txt |
| | |- i2c/ |
| | | `- README.txt |
| | |- inifile/ |
| | | `- README.txt |
| | |- install/ |
| | | `- README.txt |
| | |- nsh/ |
| | | `- README.txt |
| | |- nxplayer/ |
| | | `- README.txt |
| | |- psmq/ |
| | | `- README.txt |
| | |- symtab/ |
| | | `- README.txt |
| | |- termcurses/ |
| | | `- README.txt |
| | |- usbmsc/ |
| | | `- README.txt |
| | `- zmodem/ |
| | `- README.txt |
| `- wireless |
| |- bluetooth/ |
| | `- btsak/ |
| | `- README.txt |
| `- ieee802154 |
| `- i8sak/ |
| `- README.txt |
| </pre></div> |
| </div> |
| <p>Additional README.txt files in the other, related repositories:</p> |
| <div class="highlight-none notranslate"><div class="highlight"><pre><span></span>NxWidgets/ |
| |- Doxygen |
| | `- README.txt |
| |- tools |
| | `- README.txt |
| |- UnitTests |
| | `- README.txt |
| `- README.txt |
| |
| buildroot/ |
| `- README.txt |
| |
| tools/ |
| `- README.txt |
| |
| uClibc++/ |
| `- README.txt |
| </pre></div> |
| </div> |
| </section> |
| </section> |
| </section> |
| |
| |
| </div> |
| </div> |
| <footer><div class="rst-footer-buttons" role="navigation" aria-label="Footer"> |
| <a href="trademarks.html" class="btn btn-neutral float-left" title="Trademarks" accesskey="p" rel="prev"><span class="fa fa-arrow-circle-left" aria-hidden="true"></span> Previous</a> |
| <a href="../quickstart/index.html" class="btn btn-neutral float-right" title="Getting Started" accesskey="n" rel="next">Next <span class="fa fa-arrow-circle-right" aria-hidden="true"></span></a> |
| </div> |
| |
| <hr/> |
| |
| <div role="contentinfo"> |
| <p>© Copyright 2023, The Apache Software Foundation.</p> |
| </div> |
| |
| |
| |
| </footer> |
| </div> |
| </div> |
| </section> |
| </div> |
| <script> |
| jQuery(function () { |
| SphinxRtdTheme.Navigation.enable(true); |
| }); |
| </script> |
| |
| </body> |
| </html> |
