APACHE NUTTX (ПОДГОТОВКА К ВЫПУСКУ)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  * Введение
    - Статус подготовки к выпуску
  * Сообщество
    - Получение помощи
    - Почтовые списки
    - Трекер ошибок
    - Исходный код
    - Исходный код веб-сайта
  * Окружения
    - Установка Cygwin
    - Ubuntu Bash под Windows 10
    - Использование macOS
  * Установка
    - Скачивание и распаковка
    - Полуобязательные приложения/пакеты
    - Папки установки с пробелами в пути
    - Скачивание из репозиториев
    - Связанные репозитории
    - Примечания о заголовочных файлах
  * Настройка NuttX
    - Создание "готовых" конфигураций
    - Обновление конфигураций
    - Инструмент конфигурирования NuttX
    - Поиск выборок в меню конфигурации
    - Отображение скрытых опций конфигурации
    - Убедитесь, что вы используете правильную платформу
    - Сравнение двух конфигураций
    - Создание файлов defconfig
    - Несовместимости со старыми конфигурациями
    - Инструмент конфигурирования NuttX под DOS
  * Инструментные цепочки
    - Кросс-разработка инструментных цепочек
    - Инструментная цепочка NuttX Buildroot
  * Оболочки
  * Сборка NuttX
    - Сборка
    - Пересборка
    - Цели сборки и опции
    - Нативная сборка под Windows
    - Установка GNUWin32
  * Проблемы сборки Cygwin
    - Странные проблемы с путями
    - Проблемы нативной инструментной цепочки Windows

ДОКУМЕНТАЦИЯВВЕДЕНИЕ
^^^^^^^^^

Apache NuttX (Подготовка к выпуску) — это операционная система реального времени (RTOS), ориентированная на соответствие стандартам и малый размер. Скалярная от 8-битных до 32-битных микроконтроллерных сред, основными регламентирующими стандартами в NuttX являются POSIX и ANSI стандарты. Дополнительные стандартные API от Unix и других распространённых RTOS (например, VxWorks) используются для функциональности, недоступной под этими стандартами, или для функциональности, не подходящей для глубоко встроенных сред (например, fork()).

Подробная документация доступна на проектном вики:

https://cwiki.apache.org/NUTTX/Nuttx

Статус подготовки к выпуску
----------------------------

Apache NuttX (Подготовка к выпуску) — это усилие, находящееся в процессе подготовки к выпуску в Apache Software Foundation (ASF), спонсируемое Incubator. Для получения дополнительной информации о нашем усилии подготовки к выпуску, пожалуйста, обратитесь к файлу DISCLAIMER-WIP, находящемуся в той же директории, что и этот README.

Для краткости остальная часть этого файла будет ссылаться на него как на Apache NuttX или просто NuttX.

КОММУНИКАТИВНАЯ ОБЛАСТЬ
^^^^^^^^^^^^^^^^^^^^^^

Каждый волонтерский проект черпает свою силу из людей, участвующих в нём. Мы приглашаем вас принять участие в проекте столько, сколько вам будет угодно.

Мы рекомендуем вам:  - Использовать наш проект и предоставлять обратную связь.
  - Предоставлять нам примеры использования.
  - Сообщать о багах и отправлять патчи.
  - Вносить свой вклад в виде кода или документации.

Получение помощи
----------------

  Лучшим местом для получения помощи является список рассылки разработчиков. Пожалуйста, обратитесь к следующему разделу:

Списки рассылки
----------------

  Получите помощь в использовании NuttX или внесите свой вклад в проект через наши списки рассылки:

  dev@nuttx.apache.org предназначен для людей, желающих внести свой вклад в код NuttX.

  - Чтобы подписаться, отправьте электронное письмо на dev-subscribe@nuttx.apache.org.
  - Чтобы отписаться, отправьте электронное письмо на dev-unsubscribe@nuttx.apache.org.
  - Посмотреть архивы можно здесь:

      https://www.mail-archive.com/dev@nuttx.apache.org/

  commits@nuttx.apache.org — это только для чтения список, который уведомляет подписчиков о сообщениях о коммитах и патчах NuttX.

  - Чтобы подписаться, отправьте электронное письмо на commits-subscribe@nuttx.apache.org.
  - Чтобы отписаться, отправьте электронное письмо на commits-unsubscribe@nuttx.apache.org.
  - Посмотреть архивы можно здесь:

      https://www.mail-archive.com/commits@nuttx.apache.org/

Система отслеживания проблем
-----------------------------

  Сообщения о багах:

  Нашли баг? Отправьте электронное письмо на список рассылки разработчиков dev@nuttx.apache.org.  Перед тем как отправить сообщение о проблеме, пожалуйста:

  - Убедитесь, что баг действительно существует.
  - Поищите архивы списка рассылки, чтобы убедиться, что такой баг еще не был сообщён.
  - Рассмотрите возможность самостоятельного поиска бага в исходном коде NuttX и отправки патча вместе с вашим сообщением о баге. Это существенно экономит время разработчикам NuttX и помогает гарантировать быстрое исправление бага.

  Запросы на новые функции:

  Запросы на улучшение новых функций также приветствуются. Чем конкретнее и рациональнее запрос, тем больше шансов, что он будет включён в будущие выпуски.

Исходный код
-------------

  Исходный код проекта находится в двух репозиториях Git. Основной операционной системой является incubator-nuttx, а репозиторий приложений находится в incubator-nuttx-apps. Эти репозитории находятся на серверах GitBox Apache и также зеркалируются на GitHub. Они синхронизированы, поэтому вы можете использовать любую из этих опций по своему выбору.

  - Репозиторий ядра операционной системы NuttX:

      Основной:
      https://gitbox.apache.org/repos/asf?p=incubator-nuttx.git

      Миррор GitHub:
      https://github.com/apache/incubator-nuttx

  - Репозиторий приложений:

      Основной:
      https://gitbox.apache.org/repos/asf?p=incubator-nuttx-apps.git

      Миррор GitHub:
      https://github.com/apache/incubator-nuttx-apps

Исходный код веб-сайта
-----------------------  Исходный код проекта доступен через репозиторий исходного кода веб-сайта,
  который также зеркалируется в GitHub:

      Основной:
      https://gitbox.apache.org/repos/asf?p=incubator-nuttx-website.git

      Миррор GitHub:
      https://github.com/apache/incubator-nuttx-website

ОКРУЖЕНИЯ
^^^^^^^^^^

  NuttX требует окружения разработки, совместимого с POSIX, таким как вы
  можете найти под Linux или macOS. NuttX также может быть установлен и
  собран на системах Windows, если вы предоставите такое окружение разработки,
  совместимое с POSIX. Варианты окружения разработки, совместимого с POSIX,
  под Windows включают:

    - Установка Linux в виртуальной машине (VM) под Windows. Я не был доволен
      использованием виртуальных машин. У меня были проблемы с устойчивостью
      с открытыми исходниками виртуальными машинами, а коммерческие виртуальные
      машины стоят больше, чем я хочу потратить. Поделиться файлами с Linux,
      работающим в виртуальной машине, неудобно; поделиться устройствами,
      подключенными к компьютеру Windows, с Linux в виртуальной машине, по меньшей
      мере, запутано; использование инструментов Windows (например, Segger J-Link)
      с файлами, собранными под Linux в виртуальной машине, невозможно.    - Окружение Cygwin. Инструкции по установке Cygwin на системе Windows
      приведены ниже в разделе "Установка Cygwin". Cygwin — это зрелое,
      хорошо протестированное и очень удобное окружение. Оно особенно удобно,
      если вам нужно интегрироваться с инструментами Windows и файлами.
      Недостатками являются длительное время установки и медленное время компиляции.    - Ubuntu/Bash Shell под Windows 10. Это новый вариант под Windows 10.
      См. раздел "Ubuntu Bash под Windows 10" ниже. Это улучшение по сравнению
      с Cygwin, если ваша забота — время компиляции; его производительность сборки
      сравнима с нативной Linux, определенно лучше, чем время компиляции Cygwin.
      Он также устанавливается за крошечную долю времени по сравнению с Cygwin,
      возможно, за 20 минут для базовой установки Ubuntu (в отличие от более чем
      одного дня для полной установки Cygwin). Были даже более свежие порты окружения Linux на Windows. Мне нужно обновить этот раздел, чтобы включить упоминание этих альтернатив.

    - Окружение MSYS. MSYS происходит из более старой версии Cygwin, упрощённой и адаптированной для работы более естественно в окружении Windows. Если вас интересует использование MSYS, см. http://www.mingw.org/wiki/MSYS. Преимущества окружения MSYS заключаются в том, что оно лучше интегрировано с нативным окружением Windows и имеет меньший вес; оно использует минимальное количество дополнительных инструментов POSIX.

      Ссылка на загрузку в этом Wiki приводит на сайт загрузки SourceForge. Проект SourceForge MSYS некоторое время был стагнирующим. Проект MSYS недавно переместился на http://odsn.net/projects/sfnet_mingwbundle. Там доступны текущие .zip-файлы для загрузки, но нет инструкций по установке.    - MSYS2 кажется переписью MSYS на основе более новой версии Cygwin. Он доступен по адресу https://www.msys2.org. На этом сайте доступен установщик для Windows вместе с очень хорошими инструкциями по установке. Загрузка происходит относительно быстро (по крайней мере, по сравнению с Cygwin), и инструмент управления пакетами 'pacman' поддерживает простые обновления системы. Например, команда 'pacman -S git' установит командные инструменты линии приказов Git.    - Другие окружения POSIX. Проверьте:

        UnxUtils: https://sourceforge.net/projects/unxutils/, https://en.wikipedia.org/wiki/UnxUtils
        MobaXterm: https://mobaxterm.mobatek.net/
        Gow: https://github.com/bmatzelle/gow/wiki

      Примечание: В принципе, эти окружения должны работать. Однако, я никогда не использовал ни одно из этих окружений и не могу гарантировать, что нет каких-либо менее очевидных проблем.

  NuttX также может быть установлен и построен на нативной системе Windows, но с некоторыми потенциальными проблемами, связанными с инструментами (см. обсуждение "Native Windows Build" под "Building NuttX" ниже). GNUWin32 используется для предоставления совместимых нативных инструментов Windows.

Установка Cygwin
----------------

  Установка Cygwin на вашем компьютере Windows проста, но затратна по времени. См. http://www.cygwin.com/ для инструкций по установке. В основном вам просто нужно скачать небольшую программу setup.exe, и она выполнит реальную, сетевую установку для вас. Некоторые советы по установке Cygwin:

1. Установите в C:\cygwin

2. Установите ВСЕ: "Только минимальные базовые пакеты из распределения Cygwin устанавливаются по умолчанию. Нажатие на категории и пакеты в окне установки программы setup.exe предоставляет вам возможность контролировать, что будет установлено или обновлено. Нажатие на поле 'По умолчанию' рядом с категорией 'Все' предоставляет вам возможность установить каждый пакет Cygwin. Обратите внимание, что это загрузит и установит сотни мегабайт на ваш компьютер."Если вы используете установку 'по умолчанию', вы будете недостаточно оснащены многими утилитами Cygwin, необходимыми для сборки NuttX. Сборка завершится ошибками в нескольких местах из-за отсутствия пакетов.

ЗАМЕЧАНИЕ: Последний раз, когда я устанавливал ВСЕ, размер загрузки составил около 5 ГБ. Сервер, который я выбрал, также был очень медленным, поэтому установка заняла более одного дня!

ЗАМЕЧАНИЕ: Вам действительно не обязательно устанавливать ВСЕ, но я не могу ответить на вопрос "А что тогда мне установить?". Я не знаю ответа на этот вопрос, поэтому буду продолжать рекомендовать установку ВСЕГО.

Вы, конечно, можете исключить "Науку", "Математику" и "Публикацию". Вы можете попробовать исключить KDE, GNOME, GTK и другие графические пакеты, если вы не планируете использовать их.

Возможно, минимальный набор будет таким, как упомянутый ниже для установки "Ubuntu Bash под Windows 10"?

ОБНОВЛЕНИЕ: Сергей Фролов успешно использовал следующую минимальную конфигурацию Cygwin:

1. После запуска установщика Cygwin, оставьте предварительно выбранные рекомендованные пакеты в конфигурации по умолчанию.
2. Используя средства установки, добавьте следующие пакеты:

    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После установки Cygwin вы получите множество ссылок на установленные инструменты и оболочки. Я использую нативную оболочку rxvt. Она быстрая и надёжная и не требует запуска сервера X Cygwin (который ни в коем случае не является быстрым или надёжным). Если не указано иное, остальные инструкции предполагают, что вы находитесь в командной строке bash либо в Linux, либо в оболочке Cygwin.

Использование MSYS
------------------

MSYS представляет собой среду, основанную на Cygwin. Таким образом, большинство сказанного о Cygwin применимо и к MSYS. В этом разделе будут рассматриваться различия при использовании MSYS, в частности MSYS2.

Предполагается, что вы уже скачали и установили MSYS2 с сайта https://www.msys2.org с помощью доступного там Windows установщика. Также предполагается, что вы уже установили необходимые инструменты с помощью утилиты управления пакетами 'pacman'. Необходимыми инструментами являются:

    pacman -S git
    pacman -S make
    pacman -S gcc
    pacman -S gdb

И возможно, другие в зависимости от вашего использования. Затем вам потребуется собрать и установить kconfig-frontends в соответствии с инструкциями файла README.txt верхнего уровня в репозитории инструментов. Это требует следующих дополнительных инструментов:

    pacman -S bison
    pacman -S gperf
    pacman -S ncurses-devel
    pacman -S automake-wrapper
    pacman -S autoconf
    pacman -S pkg-configПо причине некоторых проблем с версионированием, мне пришлось запустить `aclocal` перед запуском конфигурационного скрипта kconfig-frontends. Дополнительная информация см. в разделе "Настройка NuttX" ниже.

В отличие от Cygwin, MSYS не поддерживает символические ссылки. Команда `ln -s` фактически копирует директорию! Это означает, что ваш файл Make.defs должен содержать определения, такие как:

```makefile
ifeq ($(CONFIG_WINDOWS_MSYS),y)
  DIRLINK = $(TOPDIR)/tools/copydir.sh
  DIRUNLINK = $(TOPDIR)/tools/unlink.sh
endif
```

Это заставляет копирование директорий работать таким образом, чтобы его могло обрабатывать систему сборки NuttX. ОБРАТНАЯ СВЯЗЬ: Скрипт по умолчанию link.sh был обновлен так, чтобы он теперь был совместим с MSYS2. Вышеупомянутое является предпочтительным, но больше не обязательно в файле Make.defs.

Чтобы собрать симулятор под MSYS, вам также потребуется:

```bash
pacman -S zlib-devel
```

Кажется, что вы не можете использовать имена директорий с пробелами, такими как "/c/Program Files (86)" в переменной пути MSYS. Я обходил это, создавая Windows-соединения следующим образом:

1. Откройте окно командной строки Windows,
2. Перейдите в c:\msys64, затем
3. `mklink /j programfiles "C:/Program Files"` и
4. `mklink /j programfiles86 "C:/Program Files (x86)"`

Теперь они отображаются как `/programfiles` и `/programfiles86` в песочнице MSYS2. Эти пути можно использовать с переменной PATH. Мне пришлось сделать что-то подобное для пути к GNU Tools "ARM Embedded Toolchain", который также имеет пробелы в имени пути. Ubuntu Bash в Windows 10
------------------------  Более продвинутая версия командной строки только для Ubuntu в Windows 10 (бета) недавно стала доступна от Microsoft.

  Установка
  ----------
  Инструкции по установке широко распространены в Интернете с приложенными скриншотами. Я попытаюсь воспроизвести эти инструкции полностью здесь. Вот упрощённые шаги установки:

    - Откройте "Настройки".
    - Нажмите на "Обновление и безопасность".
    - Нажмите на "Для разработчиков".
    - Под "Использование разработческих возможностей" выберите опцию "Разработчикский режим" для настройки окружения для установки Bash.
    - Откроется окно сообщения. Нажмите "Да", чтобы включить разработческий режим.
    - После установки необходимых компонентов вам потребуется перезагрузить компьютер.

  После перезагрузки вашего компьютера:

    - Откройте "Панель управления".
    - Нажмите на "Программы".
    - Нажмите на "Включение или отключение Windows-функций".
    - Откроется список функций, отметьте опцию "Подсистема Windows для Linux (бета)".
    - Нажмите "ОК".
    - После установки компонентов на вашем компьютере нажмите кнопку "Перезагрузить сейчас", чтобы завершить задачу.

  После перезагрузки вашего компьютера вы заметите, что Bash не появится в списке "Недавно добавленных" приложений, так как Bash ещё не установлен. Теперь, когда вы настроили необходимые компоненты, используйте следующие шаги для завершения установки Bash:    - Откройте "Пуск", выполните поиск bash.exe и нажмите "Enter".
    - В командной строке введите y и нажмите Enter для загрузки и установки Bash из Windows Store. Это займет некоторое время.
    - Затем вам потребуется создать стандартный UNIX-аккаунт пользователя. Этот аккаунт не обязан совпадать с вашим Windows-аккаунтом. Введите имя пользователя в требуемое поле и нажмите Enter (вы не можете использовать имя пользователя "admin").
    - Закройте командную строку "bash.exe".

  Теперь, когда вы завершили установку и настройку, вы можете открыть Bash-инструмент из меню "Пуск" так же, как вы делаете это с любым другим приложением.

  Доступ к файлам Windows из Ubuntu
  ---------------------------------
  Файловые системы будут смонтированы под "/mnt", поэтому, например, "C:\Program Files" будет доступен по пути "/mnt/c/Program Files". Это противопоставляется Cygwin, где тот же каталог будет доступен по пути "/cygdrive/c/Program Files". Существуют некоторые различия (возможно, несколько других особенностей Windows), но установка Ubuntu работает точно так же, как если бы она запускалась нативно на вашем ПК.

Хороший совет по работе с файлами — использовать символические ссылки в домашнем каталоге Ubuntu. Например, предположим, что у вас есть каталог "projects" по пути C:\Documents\projects. Тогда вы можете создать ссылку на каталог projects/ в вашем домашнем каталоге Ubuntu следующим образом:```bash
ln -s /mnt/c/Documents/projects projects
```

Доступ к файлам Ubuntu из Windows
---------------------------------
В окружении Ubuntu Userspace for Windows корневой каталог файловой системы Ubuntu находится по пути:

```bash
%localappdata%\lxss\rootfs
```

Или

```bash
C:\Users\Username\AppData\Local\lxss\rootfs
```

Однако я не могу увидеть свои файлы в каталоге rootfs\home. После некоторого поиска я нашел домашний каталог по пути:

```bash
%localappdata%\lxss\home
```

С этой хитростью доступ к каталогу /home, вы должны быть в состоянии использовать инструменты Windows вне песочницы Ubuntu с версией NuttX, собранной внутри песочницы, используя этот путь.

Выполнение инструментов Windows из Ubuntu
-----------------------------------------
Вы также можете выполнять инструменты Windows изнутри песочницы Ubuntu:

```bash
/mnt/c/Program\ Files\ \(x86\)/Microchip/xc32/v1.43/bin/xc32-gcc.exe --version
Не удалось перевести текущий рабочий каталог. Используется C:\WINDOWS\System32
xc32-gcc.exe (Microchip Technology) 4.8.3 MPLAB XC32 Compiler v1.43 Дата сборки: 1 марта 2017
...
```

Сообщение об ошибке указывает, что есть дополнительные проблемы: вы не можете смешивать инструменты Windows, использующие пути в стиле Windows, в окружении, использующем пути POSIX. Я полагаю, что вам следует использовать только инструменты Linux изнутри песочницы Ubuntu.

Установка программного обеспечения Ubuntu
----------------------------------------
Используйте `sudo apt-get install <название пакета>`. В качестве примера вот как вы получите Git:

```bash
sudo apt-get install git
``````bash
sudo apt-get install git
```

Это даст вам компилятор для вашего хостового ПК:

```bash
sudo apt-get install gcc
```

Это даст вам компилятор ARM для целевой платформы:

```bash
sudo apt-get install gcc-arm-none-eabi
```

**ЗАМЕЧАНИЕ:** Это всего лишь пример. Я не уверен, будет ли `apt-get` давать вам актуальный или работающий компилятор. Вы должны тщательно выбирать свою цепочку инструментов для потребностей своего проекта.

Также вам потребуется конфигурация `kconfig-frontends`, как описано ниже под заголовком "Инструмент конфигурации NuttX". Для сборки инструмента конфигурации `kconfig-frontends` вам также потребуются: `make`, `gperf`, `flex`, `bison` и `libncurses-dev`. Этого достаточно для базовой сборки NuttX.

Интеграция с инструментами Windows
-----------------------------------
Если вы хотите интегрироваться с нативными инструментами Windows, вам потребуется решать те же проблемы, что и при интеграции Cygwin с нативными компиляторами, см. раздел "Проблемы сборки в Cygwin" ниже.

Однако в настоящее время нет поддержки сборки для использования нативных инструментов Windows с Ubuntu под Windows. Эта комбинация инструментов предназначена для работы с помощью Cygwin через использование инструмента `'cygpath -w'`, который преобразует пути, например, из `'/cydrive/c/Program Files'` в `'C:\Program Files'`. Однако аналогичного инструмента для преобразования `'/mnt/c/Program Files'` в окружении Ubuntu нет.  Поддержка графики
  -----------------
  Поддерживаемая Microsoft версия Ubuntu является только командной строкой. Поддержка графических утилит Linux отсутствует.  Это ограничение не связано с ограничениями Ubuntu, а лишь с тем, что Microsoft готова поддерживать. Если вы установите X-сервер, вы сможете использовать базовые графические утилиты. См., например:

    http://www.howtogeek.com/261575/how-to-run-graphical-linux-desktop-applications-from-windows-10s-bash-shell/

  Многие графические программы Linux также требуют графического фреймворка, такого как GTK или Qt. Поэтому это может превратиться в путешествие в страну бреда.

Использование macOS
-------------------

  Вам необходимо установить следующие инструменты, специфичные для macOS.

  * flock (используется логикой сборки APPDIR)

    Доступна портация для macOS по адресу: https://github.com/discoteq/flock

      brew tap discoteq/discoteq
      brew install flock

  Если вы хотите собрать симулятор:

    * Xcode (нативный компилятор и остальная часть инструментария)

    * ELF инструментарий (если вы хотите собрать модули для CONFIG_LIBC_MODLIB)

        brew install x86_64-elf-gc

УСТАНОВКА
^^^^^^^^^

  Есть два способа получить NuttX: вы можете скачать стабильные архивы tarball с сайта проекта. Или вы можете получить NuttX, клонируя репозитории GIT. Давайте рассмотрим сначала стабильные архивы tarball:Загрузка и распаковка
----------------------

Загрузите и распакуйте архив NuttX. Если вы читаете это, то, скорее всего, вы уже сделали это. После распаковки вы получите директорию nuttx-version (где version — номер версии NuttX). Возможно, вы захотите переименовать эту директорию в nuttx, чтобы она соответствовала различным инструкциям в документации и некоторым скриптам в дереве исходного кода. Ссылка для скачивания:    https://nuttx.apache.org/download/

  Устаревшие ссылки для скачивания:

    https://bitbucket.org/nuttx/nuttx/downloads
    https://sourceforge.net/projects/nuttx/files/nuttx/

Пакет приложений (полуобязательный)
-----------------------------------

  Все библиотеки NuttX и примеры кода ранее включались в состав NuttX.
  С версии NuttX-6.0 этот код приложений был вынесен в отдельный архив apps.tar.gz.
  Если вы только начинаете работу с NuttX, вам потребуется скачать версионный архив apps.tar.gz вместе с основным архивом NuttX.
  Если у вас уже есть свой каталог приложений, вам может не потребоваться архив apps.tar.gz.

  Называется "полуобязательным", потому что если у вас нет каталога apps/, сборка NuttX **не пройдет**!
  Вам не обязательно использовать архив apps.tar.gz; вы можете предоставить свой собственный каталог приложений.
  Такой каталог должен содержать действительный файл Makefile для поддержки сборки и действительный файл Kconfig для поддержки конфигурации.
  Больше информации о этих файлах будет позже.

  Скачайте и распакуйте архив apps.tar.gz в ту же директорию, где вы распаковали архив NuttX.
  После распаковки архива apps.tar.gz у вас появится новая директория с названием apps-версия (где версия должна точно совпадать с версией архива NuttX).
  Возможно, вам захочется переименовать директорию в apps/ для соответствия с документацией.

  После распаковки (и переименования) архива apps.tar.gz у вас будут две директории рядом друг с другом:             |
        +----+----+
        |         |
      nuttx/     apps/

Это важно, так как процесс сборки NuttX ожидает найти директорию apps в этом (по умолчанию) месте.
По умолчанию это место можно изменить, модифицировав ваш файл конфигурации NuttX, но это другая история.

Директории установки с пробелами в пути
----------------------------------------

Директория сборки NuttX должна находиться в пути, который не содержит пробелов в имени любого верхнего уровня каталога.
Например, под Cygwin ваш домашний каталог может быть сформирован из вашего имени и фамилии, например: "/home/Имя Фамилия".
Это вызовет странные ошибки при попытке сборки системы make. [На самом деле, эта проблема, вероятно, не слишком сложна для решения. Некоторые файлы make могут просто требовать путей в двойных кавычках]

Я работаю с пробелами в имени домашней директории, создавая новую директорию, которая не содержит пробелов, например /home/nuttx. Затем я устанавливаю NuttX в /home/nuttx и всегда собираю из /home/nuttx/nuttx-code.

Загрузка из репозиториев
-------------------------

Клонирование репозитория

ПЕРЕД клонированием репозиториев на любой платформе Windows выполните следующую команду GIT:

git config --global core.autocrlf false

Это избежит преобразования символов новой строки (новых строк, \n) в последовательности возврата каретки плюс новой строки (\r\n).    Текущая версия NuttX доступна из репозитория GIT. Вот инструкции по клонированию основного репозитория NuttX RTOS (соответствующего tarball nuttx, обсуждавшегося выше):

      git clone https://gitbox.apache.org/repos/asf/incubator-nuttx.git nuttx
      -или-
      git clone https://github.com/apache/incubator-nuttx.git nuttx

    А также полуобязательная директория приложений apps/ может быть клонирована так:

      git clone https://gitbox.apache.org/repos/asf/incubator-nuttx-apps.git apps
      -или-
      git clone https://github.com/apache/incubator-nuttx-apps.git apps

    Это даст вам ту же структуру директорий, как показано ниже:

             |
        +----+----+
        |         |
      nuttx/     apps/

  Настройка клонов

    Следующие шаги должны быть выполнены для каждого из репозиториев. После перехода в директорию клонов:

    Установите ваше имя:

      git config --global user.name "Ваше Имя"
      git config --global user.email ваше.имя@example.com

    Цветные diff гораздо легче читаются:

      git config --global color.branch auto
      git config --global color.diff auto
      git config --global color.interactive auto
      git config --global color.status auto

    Проверьте другие настройки

      git config --list

  Клонирование NuttX внутри Cygwin

    Если вы клонируете репозиторий NuttX, рекомендуется избежать автоматических преобразований концов строк git. Эти преобразования могут сломать некоторые скрипты, такие как configure.sh. Перед клонированием выполните следующее:

      git config --global core.autocrlf false

Связанные репозитории
--------------------

  Эти являются автономными репозиториями:  * https://gitbox.apache.org/repos/asf/incubator-nuttx-apps
    или
    https://github.com/apache/incubator-nuttx-apps.git

    Этот каталог содержит опциональный пакет приложений и библиотек,
    который можно использовать с операционной системой реального времени NuttX.
    В этом каталоге есть файл README.txt, который предоставляет больше информации
    о данном пакете.

  * https://bitbucket.org/nuttx/nxwidgets

    Это графическая поддержка NuttX на C++. Включает NxWM — небольшой менеджер окон NuttX.

  * https://bitbucket.org/nuttx/uclibc

    Этот репозиторий содержит версию C++ библиотеки uClibc++. Код был взят с
    http://cxx.uclibc.org/ и адаптирован для NuttX командой RGMP (http://rgmp.sourceforge.net/wiki/index.php/Main_Page).

  * https://bitbucket.org/nuttx/buildroot

    Окружение, которое вы можете использовать для сборки кастомного GNU инструментария для NuttX.

  * https://bitbucket.org/nuttx/tools

    Здесь представлены моментальные снимки некоторых инструментов, которые вам потребуются для работы с NuttX: kconfig-frontends, genromfs и другие.

Примечания о заголовочных файлах
---------------------------------

  Другие заголовочные файлы C-библиотеки.    Когда собирается GCC инструментарий, он должен быть собран против C-библиотеки.
    Компилятор вместе с содержимым C-библиотеки завершает определение языка C и
    предоставляет полную среду разработки на языке C. NuttX предоставляет свою
    собственную встроенную C-библиотеку. Таким образом, полное и последовательное
    определение языка C для использования с NuttX происходит от сочетания компилятора
    и заголовочных файлов, предоставленных C-библиотекой NuttX.    Когда собирается GCC инструментарий, он включает заголовочные файлы C-библиотеки внутрь внутренних директорий компилятора, и таким образом C-библиотека становится частью инструментария. Если вы используете инструментарий NuttX buildroot, как описано ниже в разделе "NuttX Buildroot Toolchain", ваш GCC инструментарий будет собран против C-библиотеки NuttX и включит заголовочные файлы C-библиотеки NuttX как часть инструментария. Если вы используете какую-либо другую цепочку инструментов от третьей стороны, это будет не так. Эти цепочки инструментов, вероятно, были собраны против какой-то другой, несовместимой распределённой библиотеки C (например, newlib). Эти инструменты включили в себя несовместимые заголовочные файлы библиотеки C как часть цепочки инструментов. Эти несовместимые заголовочные файлы *не должны* использоваться с NuttX, так как они будут конфликтовать с определениями в встроенной библиотеке C NuttX. Для таких цепочек инструментов, которые включают заголовочные файлы из внешней библиотеки C, NuttX должен быть скомпилирован без использования стандартных заголовочных файлов, которые распространяются вместе с вашей цепочкой инструментов. Это предотвращает включение конфликтующих, несовместимых заголовочных файлов, таких как stdio.h. Заголовочные файлы math.h и stdarg.h, вероятно, являются самыми проблематичными.Эти проблематичные заголовочные файлы рассматриваются в более подробном порядке ниже.  Заголовочные файлы, предоставляемые вашим компилятором.

    Некоторые заголовочные файлы, такие как setjmp.h, stdarg.h и math.h, могут все еще требоваться от вашего компилятора, и ваш компилятор может не находить эти файлы, если вы компилируете NuttX без использования стандартных заголовочных файлов (то есть с ключом -nostdinc). В этом случае одним из решений является копирование этих заголовочных файлов из вашего компилятора в каталог include NuttX.

  Дублированные заголовочные файлы.

    Также есть несколько заголовочных файлов, которые можно найти в каталоге nuttx/include, которые дублируются заголовочными файлами из вашего компилятора. stdint.h и stdbool.h являются примерами. Если вы предпочитаете использовать заголовочные файлы stdint.h и stdbool.h из вашего компилятора, эти файлы могут быть скопированы в каталог nuttx/include/. Использование большинства других заголовочных файлов из вашего компилятора, скорее всего, вызовет ошибки.

  math.h    Хотя вы не должны использовать внешнюю библиотеку C, вам может потребоваться использовать другие внешние библиотеки с NuttX. В частности, вам может потребоваться использовать математическую библиотеку, libm.a. NuttX поддерживает универсальную встроенную математическую библиотеку, которая может быть включена с помощью CONFIG_LIBM=y. Однако вам может потребоваться использовать более производительную внешнюю математическую библиотеку, которая была настроена для вашего процессора. Иногда такие настроенные математические библиотеки включены в ваш компилятор.    Заголовочный файл математической библиотеки, math.h, является особым случаем. Если вы ничего не делаете, будет использован стандартный заголовочный файл math.h, предоставляемый вашим компилятором. Если у вас есть пользовательский, архитектурно-специфический файл заголовка math.h, то этот файл заголовка следует поместить в папку arch/<cpu>/include/math.h. Также существует файл заголовка math.h-заглушка, расположенный по адресу include/nuttx/lib/math.h. Этот файл заголовка-заглушки можно использовать для "перенаправления" включения на архитектурно-специфический файл заголовка math.h. Если вы добавите архитектурно-специфический файл заголовка math.h, то вам также следует определить CONFIG_ARCH_MATH_H=y в вашем файле конфигурации NuttX. Если CONFIG_ARCH_MATH_H выбран, то верхнеуровневый файл Makefile скопирует файл заголовка math.h-заглушки из include/nuttx/lib/math.h в include/math.h, где он станет системным файлом заголовка math.h. Файл заголовка math.h-заглушки ничего не делает, кроме как включает этот архитектурно-специфический файл заголовка math.h как системный файл заголовка math.h. float.h    Если вы включите общую встроенную библиотеку математики, то эта библиотека математики
    будет ожидать, что ваш компилятор предоставит стандартный заголовочный файл float.h.
    Заголовочный файл float.h определяет свойства вашей реализации с плавающей запятой.
    Всегда лучше использовать заголовочный файл float.h вашего компилятора, но если он недоступен,
    будет предоставлен стандартный заголовочный файл float.h, если выбрана эта опция. Однако,
    нет гарантии, что настройки в этом заголовочном файле float.h действительно корректны для вашей платформы!  stdarg.h

    В большинстве случаев правильной версией stdarg.h является версия, предоставляемая вашим компилятором.
    Однако иногда возникают проблемы с использованием stdarg.h вашего компилятора. Например, он может пытаться
    включить заголовочные файлы, которые отсутствуют в NuttX, или заголовочные файлы, которые он использует,
    могут не совместимы с заголовочными файлами NuttX. В этих случаях вы можете использовать архитектурно-специфический
    заголовочный файл stdarg.h, определив CONFIG_ARCH_STDARG_H=y.

    См. обсуждение выше для заголовочного файла math.h. Это настройка работает точно так же для заголовочного файла stdarg.h.

НАСТРОЙКА NUTTX
^^^^^^^^^^^^^^^

Инстанцирование "готовых" конфигураций
--------------------------------------

  configure.sh и configure.bat:

    "Готовые" конфигурационные файлы NuttX хранятся в:

      boards/<arch-name>/<chip-name>/<board-name>/configs/<config-dir>

    Где <board-name> — это имя вашей разработочной платы, а <config-dir> — это имя подкаталога,
    содержащего конкретную конфигурацию для этой платы. <arch-name> и <chip-name> относятся к характеристикам
    микроконтроллера, используемого на плате: <arch-name> — это архитектура процессора, реализованная микроконтроллером;
    <chip-name> — это семейство микроконтроллеров. Для инстанцирования конфигурации NuttX требуется всего несколько шагов,
    но чтобы сделать настройку еще проще, есть скрипты, доступные в подкаталоге tools/, которые объединяют эти простые шаги
    в одну команду.    Есть один инструмент для использования с любым шеллом типа Bash, который выполняет шаги настройки. Он используется следующим образом:

      tools/configure.sh <board-name>:<config-dir>

    Есть альтернативный файл батарей Windows, который можно использовать в нативной среде Windows, например:

      инструменты\configure.bat <название_платы>:<конфиг-дир>

    Для обеспечения поддержки других платформ также существует программа
    на языке C в файле tools/configure.c, которую можно скомпилировать для
    установки конфигурации платы.

    Дополнительная информация о этих скриптах содержится в файле:

    tools/README.txt

    Общая информация о настройке NuttX доступна по следующим путям:

     {TOPDIR}/boards/README.txt
     {TOPDIR}/boards/<arch-name>/<chip-name>/<board-name>/README.txt

  Скрытые конфигурационные скрипты:

    Как упоминалось выше, для создания конфигурации NuttX требуется всего
    несколько простых шагов. Эти шаги скрыты конфигурационными скриптами,
    но они сведены ниже:

    1. Копирование файлов

      Настройка NuttX требует копирования двух файлов из <конфиг-дир> в
      директорию, где установлен NuttX (TOPDIR):

        Копировать boards/<arch-name>/<chip-name>/<board-name>/configs/<конфиг-дир>/Make.def
        в {TOPDIR}/Make.defs

      ИЛИ

        Копировать boards/<arch-name>/<chip-name>/<board-name>/scripts/Make.def
        в {TOPDIR}/Make.defs      Make.defs описывает правила, необходимые для вашего компилятора для
      сборки и линковки кода. Возможно, вам потребуется изменить этот файл,
      чтобы он соответствовал специфическим требованиям вашего компилятора.
      ВАЖНО отметить, что конфигурация может иметь свой уникальный файл
      Make.defs в своей конфигурационной директории или использовать общий
      файл Make.defs для платы в директории scripts/. Первый имеет приоритет.        Копировать boards/<arch-name>/<chip-name>/<board-name>/configs/<конфиг-дир>/defconfig
        в {TOPDIR}/.config

      Файл defconfig содержит фактическую конфигурацию сборки. Этот файл
      включается всеми другими make файлами для определения того, что входит
      в сборку, а что нет. Этот файл также используется для генерации C
      заголовочного файла конфигурации в include/nuttx/config.h.

        Копировать другие, специфичные для окружения файлы в {TOPDIR}

      Это может включать файлы, такие как .gdbinit или файлы конфигурации
      среды разработки, такие как .project или .cproject.

    2. Обновление конфигурации

      Новые параметры конфигурации могут быть добавлены или удалены.
      Существующие параметры также могут изменять свои значения или опции.
      Это должно быть обработано обновлением конфигурации, как описано ниже.ЗАМЕЧАНИЕ: NuttX использует только сжатые файлы defconfig. Для файлов defconfig NuttX этот шаг обновления *не* является обязательным; также необходимо распаковать и заново сгенерировать полный файл сборки. Это подробнее обсуждается ниже.

Обновление конфигураций
-----------------------Конфигурации могут устареть. Когда новые параметры конфигурации добавляются или удаляются, или когда зависимости между параметрами конфигурации изменяются, содержимое файла по умолчанию может выйти из синхронизации с системами сборки. Поэтому хорошей практикой является "обновление" каждой конфигурации после её настройки и перед сборкой. Чтобы обновить конфигурацию, используйте инструмент конфигурирования NuttX следующим образом:```make oldconfig
```

ПОСЛЕ того, как вы создали конфигурацию NuttX, как описано выше. Шаг конфигурирования скопировал файл .config в верхний уровень директории NuttX; шаг 'make oldconfig' затем будет работать с этим файлом .config, чтобы привести его в актуальное состояние.

Если ваша конфигурация устарела, вы будете спрошены 'make oldconfig', чтобы разрешить обнаруженные инструментом конфигурирования проблемы, то есть, предоставить значения для новых параметров конфигурации в системе сборки. Выполнение этого может спасти вас от многих проблем в будущем из-за устаревших параметров в файле конфигурации по умолчанию. Инструмент конфигурирования NuttX подробнее обсуждается в следующем абзаце.

Разбираетесь, какое значение должно быть правильным для нового параметра конфигурации? Введите '?' в ответ на запрос 'make oldconfig', и он покажет вам справочное сообщение, связанное с этим параметром.

Если вы не хотите принимать решения или готовы принять рекомендованное значение по умолчанию для каждого нового параметра конфигурации, более простым способом является:

```make olddefconfig
```

Цель olddefconfig просто приведёт вашу конфигурацию в актуальное состояние с текущими Kconfig файлами, установив любые новые параметры на значение по умолчанию. Без вопросов.Инструмент конфигурирования NuttX
---------------------------------
В систему была встроена автоматизированная программа для поддержки переустановки конфигураций NuttX. Эта программа основана на приложении kconfig-frontends, доступном по адресу https://bitbucket.org/nuttx/tools/src/master/kconfig-frontends/. (Это архив старого http://ymorin.is-a-geek.org/projects/kconfig-frontends, который больше недоступен.) Приложение предоставляет инструмент под названием 'kconfig-mconf', используемый верхним уровнем Makefile NuttX. Предоставлено следующее целевое значение make:

    make menuconfig  Эта цель сборки `make` запускает конфигурационные меню NuttX.

  ВНИМАНИЕ: Никогда не выполняйте команду `make menuconfig` для конфигурации, которая не была преобразована для использования инструментов kconfig-frontends! Это может повредить вашу конфигурацию (см. [http://www.nuttx.org/doku.php?id=wiki:howtos:convertconfig](http://www.nuttx.org/doku.php?id=wiki:howtos:convertconfig)).

  Как отличить новую конфигурацию от старой? Смотрите раздел "Несовместимости с более ранними конфигурациями" ниже.

  Цель сборки `menuconfig` зависит от двух вещей:

  1. Файлов конфигурационных данных Kconfig, которые присутствуют практически во всех директориях NuttX. Эти данные находятся в части, которая все еще находится в разработке (приветствуются патчи!). Файлы Kconfig содержат информацию о конфигурации, относящуюся к директории, в которой находится этот файл Kconfig.

     **Примечание:** Для описания синтаксиса этого файла конфигурации см. файл `kconfig-language.txt` в репозитории инструментов по адресу [https://bitbucket.org/nuttx/tools](https://bitbucket.org/nuttx/tools).

  2. Инструмента `kconfig-mconf`. `kconfig-mconf` является частью пакета kconfig-frontends. Вы можете скачать этот пакет из снапшота репозитория инструментов по адресу [https://bitbucket.org/nuttx/tools](https://bitbucket.org/nuttx/tools).     Сборка kconfig-frontends под Linux может быть выполнена простыми командами `./configure`, `make`, `make install`, но могут возникнуть некоторые сложности при сборке, особенно если вы используете Cygwin. Подробные инструкции по сборке можно найти в файле `README.txt` верхнего уровня репозитория инструментов по адресу [https://bitbucket.org/nuttx/tools](https://bitbucket.org/nuttx/tools).     Шаг `make install` по умолчанию установит инструмент `kconfig-mconf` по пути `/usr/local/bin/mconf`. Убедитесь, что переменная окружения PATH включает путь к этой директории установки.

     Инструменты kconfig-frontends не собираются непосредственно "из коробки" в среде Windows. Для случая нативной Windows вы можете использовать модифицированную версию kconfig-frontends, которую можно найти по адресу [http://uvc.de/posts/linux-kernel-configuration-tool-kconfig-under-windows.html](http://uvc.de/posts/linux-kernel-configuration-tool-kconfig-under-windows.html) или более свежую портированную версию по адресу [http://reclonelabs.com/more-kconfig-awesomeness-for-windows/](http://reclonelabs.com/more-kconfig-awesomeness-for-windows/).

  Основной порядок конфигурирования — "снизу вверх": 
    - Выберите среду сборки,
    - Выберите процессор,
    - Выберите платформу,
    - Выберите поддерживаемые периферийные устройства,
    - Настройте драйверы устройств,
    - Настройте параметры приложения поверх этого.

  Это довольно прямолинейно для создания новых конфигураций,
  но может быть менее интуитивным для модификации существующих конфигураций.

  Другой ncurses-основанный инструмент, который является альтернативой kconfig-mconf, это
  kconfig-nconf. Основные различия заключаются в эстетике интерфейса пользователя.
  Если у вас есть kconfig-nconf, вы можете запустить этот интерфейс с помощью команды:

    make nconfigЕсли ваша среда поддерживает графические системы Qt или GTK (возможно, KDE или GNOME соответственно, или Cygwin под Windows с установленными Qt или GTK),
то вы также можете построить графический интерфейс kconfig-frontends, kconfig-qconf и kconfig-gconf. В этом случае вы можете запустить графический конфигуратор с помощью одной из следующих команд:    make qconfig

  или

    make gconfig

  Некоторые клавишные комбинации, поддерживаемые kconfig-mconf, инструментом, который запускается при выполнении команды 'make menuconfig':

    - '?' откроет справочное меню mconfig.

    - '/' можно использовать для поиска конфигурационных параметров.

    - 'Z' можно использовать для отображения скрытых конфигурационных параметров.

  Эти последние два сочетания клавиш подробнее описаны в следующих абзацах.

Поиск параметров в конфигурационных меню
----------------------------------------

  Конфигурационные параметры NuttX стали сложными, и найти определённый параметр в деревьях конфигураций может быть очень сложно, если вы не знаете, где искать.
  "Основной порядок конфигурации", описанный выше, может помочь сузить область поиска.

  Но если вы точно знаете, какой параметр конфигурации вам нужен, например CONFIG_XYZ, но не знаете, где его найти, то версия инструмента 'make menuconfig' предлагает помощь:
  Нажав клавишу '/', инструмент откроет меню, которое позволит вам искать конфигурационный параметр. Просто введите строку CONFIG_XYZ и нажмите 'ENTER'. Он покажет вам не только, где найти этот параметр конфигурации, но и все зависимости, связанные с этим параметром.Отображение скрытых параметров конфигурации
------------------------------------------
Если вы введете 'Z', то kconfig-mconf изменит то, что отображается.
Обычно отображаются только активированные функции, все зависимости которых выполнены.
Это, конечно, не очень полезно, если вы хотите обнаружить новые опции или ищете опцию и не осознаете, что зависимости еще не были выбраны, и, следовательно, она не отображается. Но если вы введете 'Z', то будет показана каждая опция, независимо от того, были ли удовлетворены её зависимости. Вы сможете увидеть всё, что можно было бы выбрать с правильными зависимостями. Дополнительные опции будут показаны как '-', для выбора и для значения (так как они не могут быть выбраны и не имеют значения). Основное, что вы делаете, это выбираете опцию <Помощь>, чтобы увидеть, какие зависимости существуют.Убедитесь, что вы находитесь на правильной платформе
-----------------------------------------------------

Сохранённые конфигурации могут работать на Linux, Cygwin (32- или 64-битной), или других платформах. Характеристики платформы могут быть изменены с помощью `make menuconfig`. Иногда это может быть запутанно из-за различий между платформами. Введите `sethost.sh`

`sethost.sh` — это простой скрипт, который изменяет конфигурацию на вашу платформу. Это может значительно упростить жизнь, если вы используете множество различных конфигураций. Например, если вы работаете на Linux и настраиваете таким образом:

```bash
tools/configure.sh board:configuration
```

Тогда вы можете использовать следующую команду, чтобы (1) убедиться, что конфигурация актуальна, и (2) правильно настроить конфигурацию для Linux:

```bash
tools/sethost.sh -l
```

Или, если вы на платформе Windows/Cygwin 64-битной:

```bash
tools/sethost.sh -c
```

Или, для MSYS/MSYS2:

```bash
tools/sethost.sh -g
```

Другие опции доступны через встроенную опцию помощи в скрипте. Вы можете увидеть все опции с помощью:

```bash
tools/sethost.sh -h
```

Недавно опции для скриптов `configure.sh` (и `configure.bat`) были расширены так, чтобы вы могли одновременно настроить конфигурацию, выбрать платформу хоста, которую вы используете, и разархивировать и обновить файл `defconfig` всего одной командой, как:

```bash
tools/configure.sh -l board:configuration
```

Для хоста Linux или Windows/Cygwin:

```bash
tools/configure.sh -c board:configuration
```Другие опции доступны через встроенную опцию помощи в скрипте. Вы можете увидеть все опции с помощью:

```bash
tools/configure.sh -h
```

Сравнение двух конфигураций
----------------------------

Если вы попытаетесь сравнить две конфигурации с помощью `diff`, вы, вероятно, не будете довольны результатом. В конфигурационных файлах добавлены лишние вещи, что затрудняет сравнение глазами человека. Имеется инструмент в файле `nuttx/tools/cmpconfig.c`, который можно скомпилировать для упрощения этих сравнений. Выходные данные этого инструмента различий покажут только значимые различия между двумя конфигурационными файлами. Этот инструмент компилируется следующим образом:

```bash
cd nuttx/tools
make -f Makefile.host
```

Это создаст программу под названием `cmpconfig` или `cmpconfig.exe` на Windows.

Почему вы захотите сравнивать два конфигурационных файла? Вот несколько причин, по которым я это делаю:

1. Когда я создаю новую конфигурацию, я обычно основываю её на старой конфигурации и хочу знать: "Какие опции мне нужно изменить, чтобы добавить новую функцию к старым конфигурациям?" Например, предположим, что у меня есть конфигурация `boardA/nsh` и я хочу создать конфигурацию `boardA/nxwm`. Предположим, что у меня уже есть конфигурации `boardB/nsh` и `boardB/nxwm`. Тогда, сравнивая `boardB/nsh` с `boardB/nxwm`, я могу увидеть изменения, которые мне нужно внести в мою конфигурацию `boardA/nsh`, чтобы создать новую конфигурацию `boardA/nxwm`.2. Но наиболее распространенной причиной использования программы `cmpconfig` является проверка результатов "обновления" конфигурации с помощью команды `make oldconfig` (см. абзац "Обновление конфигураций" выше). Команда `make oldconfig` делает изменения в моей конфигурации, и используя `cmpconfig`, я могу точно увидеть, какие именно изменения были сделаны и если какие из них должны вызывать у меня беспокойство.

3. Инструмент `cmpconfig` также может быть полезен при конвертации старых, устаревших ручных конфигураций в текущие конфигурации, основанные на инструментах kconfig-frontends. См. следующий абзац.

Создание файлов defconfig
-------------------------

Файлы .config как файлы defconfig:

Минимальный файл defconfig — это просто сгенерированный файл .config без настройки `CONFIG_APPS_DIR` или с её комментированием. Эта настройка предоставляет имя и путь к каталогу `apps/` относительно каталога сборки NuttX. По умолчанию это `../apps/`, однако каталог `apps` может находиться в любом другом месте и иметь другое имя. Например, имя версий NuttX всегда имеет вид `apps-xx.yy`, где `xx.yy` — это номер версии.

Поиск пути к каталогу `apps/`: при установке конфигурации по умолчанию с помощью одного из скриптов или программ из директории инструментов NuttX будет возможность указать путь к директории `apps/`. Если этот путь не указан, то конфигурационный инструмент попробует найти директорию `apps/` и сделать разумный выбор о её расположении.  Сжатые файлы defconfig:

    Makefile также поддерживает опцию для генерации очень маленьких файлов defconfig.
    Файлы .config довольно большие и сложные. Но большинство настроек в файле .config
    имеют значения по умолчанию из файлов Kconfig. Эти файлы .config могут быть
    преобразованы в маленькие файлы defconfig:

      make savedefconfig

    Эта цель make создаст файл defconfig в корневой директории. Уменьшение размера
    действительно впечатляет:

      wc -l .config defconfig
       1085 .config
        82 defconfig
       1167 всего

     Чтобы файл .config, установленный из сжатого файла defconfig, был использован,
     его нужно восстановить с помощью:

       make olddefconfig

     ОБСЛУЖИВАНИЕ 1: Только сжатые файлы defconfig сохраняются в репозитории NuttX.
     Все патчи и запросы на изменение файла defconfig должны использовать сжатый
     формат defconfig, созданный командой 'make savedefconfig.'

     ОБСЛУЖИВАНИЕ 2: Когда выполняется 'make savedefconfig', он попытается выполнить
     несколько действий, некоторые из которых ожидают ошибки. В этих случаях вы увидите
     сообщение об ошибке от make, за которым следует "(игнорируется)". Вы также должны
     игнорировать эти сообщения.     ВНИМАНИЕ: Это уменьшение размера было достигнуто путём удаления всех настроек из
     файла .config, которые имели значения по умолчанию. Команда 'make olddefconfig'
     может восстановить исходный файл .config, просто восстановив те значения по
     умолчанию. Подразумеваемое здесь предположение состоит в том, что значения по
     умолчанию не изменяются. Если значения по умолчанию изменяются (что часто
     происходит), то исходный файл .config может не быть воспроизводимым.     Поэтому, если ваш проект требует 100%-ной воспроизводимости на длительный период,
     вы можете сохранять полные файлы .config вместо стандартных, сжатых файлов defconfig.

  Настройка с использованием "сжатых" файлов defconfig:    Как описано выше для defconfig, все файлы defconfig NuttX сжаты
    с помощью команды 'make savedeconfig'. Эти сжатые файлы defconfig
    обычно не полностью используются в своем текущем виде, так как могут
    не собирать целевые бинарники, которые вы хотите, поскольку процесс
    сжатия удаляет все значения по умолчанию из файла defconfig. Чтобы
    восстановить значения по умолчанию, вам следует запустить следующую
    команду после конфигурирования:

      make olddefconfig

    Это восстановит отсутствующие значения по умолчанию.

    Использование этой команды после конфигурирования обычно является хорошей практикой:
    Даже если файлы defconfig не "сжаты" таким образом, файл defconfig может быть устаревшим,
    и единственным способом обеспечить актуальность установленного .config является использование
    команд 'make oldconfig' или 'make olddefconfig'. См. абзац выше с заголовком "Обновление конфигураций"
    для дополнительной информации.

Несовместимости с более старыми конфигурациями
-----------------------------------------------

  ***** ВНИМАНИЕ *****  Текущая система сборки NuttX поддерживает *только* новые сжатые файлы
  конфигурации defconfig, созданные с помощью инструментов kconfig-frontends,
  как описано в предыдущем разделе. Поддержка старых, устаревших, ручных
  конфигураций была удалена в NuttX 7.0; поддержка несжатых .config-файлов
  была удалена после NuttX 7.21. Все конфигурации теперь должны выполняться
  с использованием инструментов kconfig-frontends. Старые ручные конфигурации
  и новые конфигурации kconfig-frontends не совместимы. Старые устаревшие
  конфигурации *не могут* использоваться с инструментами kconfig-frontends
  и, следовательно, не могут использоваться с выпусками NuttX 7.0 и далее.  Если вы запустите 'make menuconfig' с устаревшей конфигурацией, результирующая
  конфигурация, скорее всего, будет некорректной.

  Вопрос: Как можно определить, является ли конфигурация новой конфигурацией kconfig-frontends
  или старой, ручной конфигурацией?

  Ответ: Только старые, ручные конфигурации будут иметь файл .appconfig

  Вопрос: Как можно преобразовать старую, ручную конфигурацию в новую,
  конфигурацию kconfig-frontends?

  Ответ: См. http://www.nuttx.org/doku.php?id=wiki:howtos:convertconfig

  ***** ВНИМАНИЕ *****

  Как описано выше, каждый раз, когда вы используете конфигурацию, вам следует
  всегда обновлять конфигурацию следующей командой *до* сборки NuttX: выполните make oldconfig

  ИЛИ

  выполните make olddefconfig

  Это убедится, что конфигурация актуальна в случае, если она отстала от текущего развития NuttX (см. абзац "Обновление конфигураций" выше). Но это работает только с *новыми* конфигурационными файлами, созданными с помощью инструментов kconfig-frontends.

  Кроме того, этот шаг *не является* необязательным при использовании новых, сжатых defconfig файлов. Это необходимый шаг, который также распакует defconfig файл, перегенерирует .config и сделает его доступным для сборки NuttX.

  Никогда не выполняйте 'make oldconfig' (ИЛИ 'make menuconfig') на конфигурации, которая не была преобразована для использования инструментов kconfig-frontends! Это повредит вашу конфигурацию (см. http://www.nuttx.org/doku.php?id=wiki:howtos:convertconfig).Инструмент конфигурирования NuttX под DOS
------------------------------------------

Недавние версии NuttX поддерживают сборку NuttX из нативного окна консоли Windows (см. "Нативная сборка Windows" ниже). Но kconfig-frontends — это инструмент для Linux. В прошлом это было проблемой для пользователей Windows, но теперь есть две специально модифицированные версии инструментов kconfig-frontends, которые можно использовать. Одна из них находится здесь: http://uvc.de/posts/linux-kernel-configuration-tool-kconfig-under-windows.html

Шаги конфигурирования наиболее новых версий NuttX требуют инструмента kconfig-tweak, который недоступен в вышеприведённой версии. Однако, был выпущен обновлённый Kconfig инструмент для Windows, который включает kconfig-tweak: http://reclonelabs.com/more-kconfig-с-awesome-ness-for-windows/

Исходный код доступен здесь: https://github.com/reclone/kconfig-frontends-win32 и https://github.com/reclone/kconfig-frontends-win32/releases

Также возможно использование версии kconfig-frontends, собранной под Cygwin вне "песочницы" Cygwin в нативной среде Windows:

1. Вы можете запустить инструмент конфигурирования используя Cygwin. Однако, Makefile.win Cygwin будет жаловаться, поэтому вам нужно будет вручную отредактировать файл .config:

    а. Удалите строку: CONFIG_WINDOWS_NATIVE=y
    б. Измените путь к каталогу apps/, CONFIG_APPS_DIR, чтобы использовать разделители Unix. Например, измените "..\apps" на "../apps". Конечно же, после использования конфигурационного инструмента вам нужно восстановить CONFIG_WINDOWS_NATIVE=y и правильное значение CONFIG_APPS_DIR.  2) Вы можете, с некоторыми усилиями, запустить инструмент Cygwin kconfig-mconf непосредственно в окне консоли Windows. В этом случае вам не нужно изменять файл .config, но есть другие сложности:

      а. Вам нужно временно установить директории Cygwin в переменной PATH, а затем запустить kconfig-mconf вручную, например:

          kconfig-mconf Kconfig

         Есть Windows-скрипт в tools/kconfig.bat, который автоматизирует эти шаги:

         tools/kconfig menuconfig

       б. Существует проблема доступа к переменным окружения DOS из Cygwin kconfig-mconf, работающего в окне консоли Windows. Следующее изменение в файле Kconfig верхнего уровня кажется работающим решением этой проблемы:

          config APPSDIR
              строка
          -   опция env="APPSDIR"
          +   значение по умолчанию "../apps"

ИНСТРУМЕНТЫ ПЕРЕКОНФИГУРИРОВАНИЯ
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Кросс-разработка инструментов
-----------------------------

  Чтобы скомпилировать NuttX для вашей платы, вам потребуется получить кросс-компилятор для генерации кода для вашего целевого процессора. Для каждой платы и конфигурации существует файл README.txt (в boards/<arch-name>/<chip-name>/<board-name>/README.txt). Этот файл README содержит предложения и информацию о подходящих инструментах и средах разработки для вашей платы.

  В любом случае, переменная окружения PATH должна быть обновлена для включения местоположения, где сборка может найти исполняемые файлы инструментов.Инструменты сборки NuttX
------------------------

Для многих конфигураций доступен набор инструментов "сделай сам" для NuttX. Эти инструменты можно скачать из репозитория файлов NuttX на Bitbucket.org. После распаковки tar-архива вы найдете инструкции по сборке инструментов в файле README.txt в папке buildroot/boards/.

Проверьте файл README.txt в конфигурационной директории вашей платы, чтобы узнать, можно ли использовать инструменты сборки с вашей платой (этот файл README.txt находится в boards/<arch-name>/<chip-name>/<board-name>/README.txt).

Этот набор инструментов доступен как для среды разработки Linux, так и для среды разработки Cygwin. Преимущества: (1) Заголовочные файлы NuttX встроены в цепочку инструментов, и (2) связанные с ними средства поддержки, такие как NXFLAT инструменты, инструменты генерации ROMFS (genromfs) и средства конфигурации (kconfig-frontends), могут быть встроены в вашу цепочку инструментов.

Недостатки: Эта цепочка инструментов не так хорошо поддерживается, как некоторые другие цепочки инструментов. GNU-инструменты не являются моей приоритетной задачей, поэтому средства buildroot часто отстают. Например, до недавнего времени в цепочке инструментов NuttX buildroot для ARM не было поддержки EABI.ЗАМЕЧАНИЕ: Для Cortex-M3/4 существуют версии buildroot цепочек инструментов с OABI и EABI. Если вы используете более старую версию с OABI, префикс для инструментов будет arm-nuttx-elf-; для цепочки инструментов с EABI префикс будет arm-nuttx-eabi-. Если вы используете более старую версию с OABI для ARM Cortex-M3/4, вам потребуется установить CONFIG_ARMV7M_OABI_TOOLCHAIN в файле .config, чтобы выбрать правильный префикс инструментов.Если система сборки когда-либо выбирает неправильный префикс для вашей цепочки инструментов, вы всегда можете указать префикс на командной строке, чтобы переопределить значение по умолчанию, например:

    make CROSSDEV=arm-nuttx-elf

ОБОЛОЧКИ
^^^^^^^^

NuttX использует некоторые скрипты оболочки. Некоторые из них встроены в Makefiles, а многие являются исполняемыми скриптами в директории tools/. Все скрипты были разработаны с использованием bash, и многие из них содержат зависимости от оболочки bash.

Большинство скриптов начинаются с #!/bin/bash для конкретного выбора оболочки bash. Некоторые все еще имеют #!/bin/sh, но мне не сообщали жалоб, поэтому они, вероятно, не имеют зависимостей от bash.

Существуют две проблемы с оболочками, которые мне известны:

1. Linux, где /bin/sh указывает на неконсистентную оболочку (например, ksh или csh).

   В этом случае bash, скорее всего, доступен, и #!/bin/bash в начале файла должно решить проблему. Если какие-либо скрипты с #!/bin/sh не работают, попробуйте заменить это на #!/bin/bash и сообщите мне о изменениях.

2. FreeBSD с оболочкой Bourne и без bash.

   В этом случае также сообщали о проблемах на FreeBSD системах, где есть оболочка Bourne, но нет bash. В этом случае #!/bin/bash не работает, но #!/bin/sh работает нормально. Мое рекомендация в этом случае — создать символьную ссылку в /bin/bash, которая указывает на оболочку Bourne.   Однако могут возникнуть проблемы с некоторыми скриптами, ориентированными на bash, которые потребуют модификаций. СБОРКА NUTTX

Сборка
------

  NuttX собирается в одном месте в дереве исходных кодов. Вам не нужно создавать
  какие-либо специальные директории сборки. Предполагая, что ваш Make.defs
  настроен правильно для вашего компилятора и что переменная окружения PATH
  содержит путь к месту установки ваших кросс-разработочных инструментов,
  следующие шаги являются всем необходимым для сборки NuttX:

    cd {TOPDIR}
    make

  По крайней мере одна конфигурация (eagle100) требует дополнительных
  аргументов командной строки при выполнении команды make. Прочтите
  {TOPDIR}/boards/<arch-name>/<chip-name>/<board-name>/README.txt, чтобы
  узнать, применимо ли это к вашей цели.

Пересборка
-----------

  Пересборка обычно проста — просто выполните команду make снова.

  Однако есть некоторые вещи, которые могут "поймать" вас, когда вы используете
  среду разработки Cygwin с нативными инструментами Windows. Нативные инструменты
  Windows не понимают символьные ссылки Cygwin, поэтому система сборки NuttX делает
  что-то странное: она копирует конфигурационные директории вместо создания ссылок
  на них (она могла бы, возможно, использовать команду NTFS 'mklink', но этого не делает).Последствием этого является то, что вы легко можете запутаться, когда редактируете файл в одной из связанных (то есть скопированных) директорий, пересобираете NuttX, и затем не видите свои изменения при запуске программы. Это потому, что сборка все еще использует версию файла в скопированной директории, а не ваш отредактированный файл!Старые версии NuttX не поддерживали зависимости в этой конфигурации. Поэтому простым решением этой неприятной ситуации было следующее при пересборке:

```make clean_context all
```

Эта команда `make` удаляет скопированные директории, заново копирует их, а затем собирает NuttX.

Однако более новые версии NuttX поддерживают зависимости для сборки Cygwin. В результате, эта команда приведет к пересборке всего (потому что она удаляет и будет вызывать заново создание файла заголовков `include/nuttx/config.h`). Гораздо менее гладкое, но все же эффективное решение в этом случае для конфигурации ARM:

```rm -rf arch/arm/src/chip arch/arm/src/board
```

Этот "костыль" просто удаляет скопированные директории. Эти директории будут заново созданы при выполнении обычной команды `make`, и ваши правки будут тогда применены.

Цели сборки
--------------------

Цели сборки:
Ниже приведена сводка доступных целей сборки в основной NuttX Makefile:

- **все**

  По умолчанию цель собирает исполняемый файл NuttX в выбранном формате выходных данных.

- **чисто**

  Удаляет производные объектные файлы, архивы, исполняемые файлы и временные файлы, но сохраняет конфигурационные и контекстные файлы и директории.

- **полная очистка**

  Выполняет 'чисто', а затем также удаляет все конфигурационные и контекстные файлы. Это фактически восстанавливает структуру директорий до её первоначального, незаконченного состояния.Цели домашнего хозяйства приложений. Переменная APPDIR относится к директории пользователя приложения. Примерная директория `apps/` включена с NuttX, однако это не рассматривается как часть NuttX и может быть заменена другой директорией приложения. В большинстве случаев директория приложения рассматривается как любая другая директория сборки в скрипте Makefile. Однако, для удобства, следующие цели включены для поддержки функций домашнего хозяйства в директории пользователя приложения из директории сборки NuttX.

- **apps_чисто**

  Выполняет операцию чистки только в директории пользователя приложения.

- **apps_полнаяочистка**

  Выполняет полную очистку только в директории пользователя приложения. Файл конфигурации `apps/.config` сохраняется, поэтому это не полная очистка, а скорее сброс конфигурации для директории приложения.

- **экспорт**

  Цель экспорта упаковывает библиотеки NuttX и заголовочные файлы в экспортируемый пакет. Ограничения: (1) Эти нужды требуют расширения для сборки KERNEL. (2) Логика в `tools/mkexport.sh` поддерживает только GCC и, например, явно предполагает, что архиватор — это `'ar'`.

- **загрузка**

  Это вспомогательная цель, которая перестраивает NuttX и загружает его в целевую систему за один шаг. Действие этой цели полностью зависит от реализации команды `DOWNLOAD` в файле пользователя `Make.defs`. Будет выдано сообщение об ошибке, если команда `DOWNLOAD` не определена.  Следующие цели используются внутренней логикой сборки, но могут быть вызваны из командной строки при определённых условиях, если необходимо.

  зависимость

    Создаёт зависимости сборки. (ЗАМЕЧАНИЕ: На данный момент нет поддержки зависимостей сборки под Cygwin с использованием нативных Windows-инструментов.)  контекст

    Цель контекста вызывается при каждом сборке цели для обеспечения правильной конфигурации NuttX. Основные шаги конфигурации включают создание заголовочных файлов config.h и version.h в директории include/nuttx и установление символьных ссылок на конфигурированные директории.

  очистка_контекста

    Это часть цели distclean. Она удаляет все заголовочные файлы и символьные ссылки, созданные целью контекста.

  Параметры сборки:
  Конечно, значение любого переменного make можно переопределить с командной строки make. Однако, есть одна опция присвоения переменной, которая может быть полезна для вас:

  V=1

    Это флаг "шумности" сборки. Если вы укажете V=1 на командной строке make, вы увидите точные команды, используемые при сборке. Это может быть очень полезно при добавлении новых плат или отслеживании ошибок компиляции и предупреждений (предложено Ричардом Кохраном).

Сборка под нативным Windows
----------------------------Начальные этапы сборки под нативным Windows уже реализованы, но до сих пор не часто используются. Сборка была функциональной, но из-за недостатка использования могут возникнуть проблемы с этой конфигурацией сборки.Логика сборки под нативным Windows запускается, если CONFIG_WINDOWS_NATIVE=y определена в конфигурационном файле NuttX:

Эта сборка:

- Использует все пути в стиле Windows;
- Использует в основном команды батника из cmd.exe, с
- Несколько расширений из GNUWin32.

В этой сборке нельзя использовать оболочки Cygwin или MSYS. Сборка должна выполняться в окне консоли Windows. Вот лучший терминал, чем стандартный CMD.exe терминал: ConEmu, который можно скачать с https://sourceforge.net/projects/conemu/ или https://conemu.github.io/.

Инструменты сборки. Сборка всё ещё зависит от некоторых команд Unix-подобных. Я использую инструменты GNUWin32, которые можно скачать с http://gnuwin32.sourceforge.net/, используя опцию "Download all". Отдельные пакеты можно скачать вместо этого, если вы знаете, что делаете и хотите более быстрый процесс загрузки (Нет, я не могу сказать вам, какие пакеты вы должны или не должны загружать).

УВАЖЕНИЕ: Возможно использование Cygwin или MSYS2 вместо инструментов GNUWin32. Однако, существуют сложности в этом, так как эти инструменты зависят от оболочки и используют DLL, которые не находятся (по крайней мере, не без правильной настройки). Хостовый компилятор: Я использую компилятор MingGW GCC, который можно скачать с http://www.mingw.org/. Если вы используете GNUWin32, рекомендуется не устанавливать необязательные компоненты MSYS, так как могут возникнуть конфликты.Kconfig-frontends: В разделе "Инструмент конфигурации NuttX под DOS" приведена информация
о том, как установить инструменты kconfig-frontend для работы нативно под Windows.

Эта возможность все еще находится в стадии разработки, поскольку:

(1) Она не была проверена на всех целевых платформах и инструментах,
(2) она все еще недостаточно оснащена удобствами более продвинутой среды.

Установка GNUWin32
-------------------

Windows- native сборка будет зависеть от нескольких Unix-подобных инструментов, которые можно получить с помощью MSYS или GNUWin32. GNUWin32 можно скачать с
http://gnuwin32.sourceforge.net/. GNUWin32 предоставляет версии инструментов с лицензией GPL или другими похожими открытыми лицензиями для современных MS-Windows (Microsoft Windows 2000 / XP / 2003 / Vista / 2008 / 7). Посмотрите
http://gnuwin32.sourceforge.net/packages.html для получения списка всех доступных инструментов в пакетах GNUWin32.

Проект расположен по адресу:
http://sourceforge.net/projects/gnuwin32/. Проект все еще активно поддерживается (хотя некоторые Windows-порты стали очень устаревшими).

Некоторые коммерческие наборы инструментов включают подмножество инструментов GNUWin32. Мое советуем вам скачать инструменты GNUWin32 с сайта sourceforge.net, чтобы вы знали, что используете, и могли воспроизвести вашу среду сборки.

Шаги установки GNUWin32:

Следующие шаги будут скачивать и запускать установщик GNUWin32.

1. Скачайте GetGNUWin32-x.x.x.exe с
   http://sourceforge.net/projects/getgnuwin32/files/. Это установщик. Текущая версия — 0.6.3.

2. Запустите установщик.

3. Принять лицензионное соглашение.

4. Выберите каталог установки. Мое советуем вам выбрать каталог, содержащий этот README-файл (<this-directory>).

5. После запуска GetGNUWin32-0.x.x.exe вы получите новый каталог <this-directory>/GetGNUWin32.

Обратите внимание, что установщик GNUWin32 не устанавливает сам GNUWin32. Вместо этого он устанавливает другой более умный загрузчик. Этот загрузчик является пакетным менеджером для пакетов GNUWin32, разработанным проектом OpenSSL. Следующие шаги, вероятно, следует выполнять из командной строки DOS.

6. Перейдите в каталог, созданный GetGNUWin32-x.x.x.exe    cd GetGNUWin32

  7. Выполните скрипт download.bat. Скрипт download.bat скачает около 446 пакетов! Достаточно для создания очень полной среды, похожей на Linux, под командной строкой DOS. Это займет некоторое время. Этот шаг только скачивает пакеты, а следующий шаг установит эти пакеты.

    download

  8. Этот шаг установит скачанные пакеты. Аргумент скрипта install.bat — это местоположение установки. C:\gnuwin32 — стандартное место установки:

    install C:\gnuwin32

  УВАЖАЕМЫЙ ПОЛЬЗОВАТЕЛЬ: Этот шаг установки установит *все* пакеты GNUWin32... гораздо больше, чем вам когда-либо понадобится. Если диск имеет ограниченное пространство, вам может потребоваться выполнить установку отдельных ZIP-файлов вручную, которые вы найдете в директории <this directory>/GetGNUWin32/packages.

  9. Убедитесь, что вы добавили инструменты GNUWin32 в переменную PATH:

    set PATH=C:\gnuwin32\bin;%PATH%

  ВНИМАНИЕ: Убедитесь, что у вас есть C:\MinGW\bin в вашей переменной PATH перед любым другим каталогом, содержащим libiconv-2.dll. Похоже, что программа as.exe в некоторых распределениях MinGW зависит от этой DLL, и наличие старой версии этой DLL где-то в пути (например, в инструментах GnuWin32) приведет к тому, что as.exe будет использовать более старую версию, которая не имеет точки входа, которую он ищет.

ПРОБЛЕМЫ С ПОСТРОЕНИЕМ CYGWIN
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Производительность
------------------  Производительность построения под Cygwin действительно не так уж плоха, хотя она не так хороша, как при построении под Linux. Однако часто можно заметить, что производительность просто ужасна. Если вы видите ужасную производительность... например, две или три компиляции в секунду... причиной обычно является защита от вирусов Windows, которая мешает выполнению программы построения.

  Я использую Cygwin довольно часто и использую Windows Defender. Чтобы получить хорошую производительность построения, я регулярно отключаю "Реальное время обнаружение" перед запуском 'make', а затем снова включаю его после завершения построения. С этим дополнительным шагом, я нахожу, что производительность построения под Cygwin вполне приемлема.

Проблемы с необычным поведением при сборке в окружении Cygwin
-------------------------------------------------------------

  Если вы замечаете странное поведение при сборке в окружении Cygwin, то у вас может быть проблема с переменной PATH. Например, если вы видите ошибки, связанные с отсутствием файлов, которые явно присутствуют, это может указывать на использование неправильной версии какого-либо инструмента. Например, вы можете использовать не версию программы 'make' от Cygwin, расположенную по пути /usr/bin/make. Попробуйте:

    which make
    /usr/bin/makeПри установке некоторых цепочек инструментов (например, Yargarto или инструментов CodeSourcery), они могут модифицировать вашу переменную PATH, чтобы включить путь к их исполняемым файлам. В этом месте могут находиться версии инструментов GNUWin32. Поэтому вы можете использовать версию make, которая не понимает путей Cygwin.Решение проблемы может заключаться в одном из следующих вариантов:

1. Измените ваш PATH, чтобы удалить путь к инструментам GNUWin32,
2. Добавьте /usr/local/bin, /usr/bin и /bin в начало вашего PATH:

   ```bash
   export PATH=/usr/local/bin:/usr/bin:/bin:$PATH
   ```

Проблемы с нативными Windows-инструментами
-------------------------------------------

Существует множество популярных нативных Windows-инструментов, которые могут использоваться с NuttX. Примеры включают CodeSourcery (для Windows), devkitARM и несколько инструментов, предоставляемых производителями. Есть несколько ограничений при использовании этих инструментов в окружении Cygwin. Три самых больших из них:  1. Нативные Windows-инструменты не могут работать с путями Cygwin. Преобразования путей выполняются автоматически в makefile-файлах Cygwin с помощью утилиты 'cygpath', но вы можете столкнуться с новыми проблемами с путями. Если так, проверьте 'cygpath -w'.
  
  2. Нативные Windows-инструменты не могут работать с символическими ссылками Cygwin. Многие символические ссылки используются в NuttX (например, include/arch). Система сборки работает вокруг этих проблем для Windows-инструментов путем копирования директорий вместо создания ссылок. Но это также может вызвать некоторую путаницу: например, вы можете редактировать файл в "связанной" директории и обнаружить, что ваши изменения не оказывают эффекта. Это потому, что вы собираете копию файла в "ложной" символической директории. Если вы используете нативный Windows-инструмент, вам следует привыкнуть к выполнению команд в таком виде:     make clean_context all

Алиас в вашем файле .bashrc может сделать это менее болезненным. Пересборка не займет много времени, как вы могли бы подумать, поскольку нет проверки зависимостей, если вы используете нативный Windows-инструмент. Это приводит нас к пункту #3: Общие проблемы с заранее скомпилированными наборами инструментов.

-------------------------------------------------------------

Для продолжения списка "Проблем с нативными наборами инструментов Windows" можно добавить следующее. Однако эти проблемы действительно возникают, если вы используете любой заранее скомпилированный набор инструментов (вместо сборки набора инструментов NuttX из пакета NuttX buildroot):

Может возникнуть несовместимость с заголовочными файлами, библиотеками и встроенными функциями компилятора, подробно описанными ниже. В большинстве случаев эти проблемы решаются существующей логикой сборки. Но если вы работаете в новой области, то можете столкнуться с этими проблемами:

4. Заголовочные файлы. Большинство заранее скомпилированных наборов инструментов будут использовать чужую библиотеку C (обычно newlib, но может быть uClibc или glibc, если вы используете набор инструментов Linux). Это означает, что заголовочные файлы из чужой библиотеки C будут включены в набор инструментов. Так что если вы "включите <stdio.h>", вы получите stdio.h из несовместимой, чужой библиотеки C, а не nuttx stdio.h (в nuttx/include/stdio.h), который вам нужен.Это может вызвать путаницу при сборке, и вы всегда должны быть уверены, что `-nostdinc` включено в `CFLAGS`. Это гарантирует, что вы будете использовать только заголовочные файлы из

5. библиотек. То, что было сказано выше относительно заголовочных файлов, применимо и к библиотекам. Вы не хотите использовать код из библиотек чужих библиотек C, встроенных в ваш набор инструментов. Если это произойдет, вы получите запутанные ошибки о неопределенных символах. Чтобы избежать этих ошибок, вам потребуется добавить `-nostdlib` в ваши `CFLAGS`, чтобы гарантировать, что вы будете использовать только код из библиотек NuttX.

Однако это может вызвать другие проблемы для библиотек в наборе инструментов, которые вам нужны (например, `libgcc.a` или `libm.a`). Эти библиотеки специальным образом обрабатываются в большинстве `Makefile`, но вы все равно можете столкнуться с проблемами отсутствия библиотек.

6. Встроенные функции. Некоторые компиляторы ориентированы на конкретную операционную систему. Многие люди, например, хотели бы использовать тот же набор инструментов для разработки программ для Linux и NuttX. Компиляторы, предназначенные для других операционных систем, могут генерировать несовместимые встроенные функции, и поэтому `-fno-builtin` также должно быть включено в ваши `CFLAGS`.И, наконец, вы можете не иметь возможности использовать NXFLAT. NXFLAT — это двоичный формат, описанный в Documentation/NuttXNxFlat.html. Если вы используете готовую цепочку инструментов, вы потеряете всю поддержку NXFLAT. Возможно, что можно будет создать автономные версии инструментов NXFLAT; есть несколько примеров этого в репозитории buildroot по адресу https://bitbucket.org/nuttx/buildroot. Однако возможно, что могут возникнуть проблемы совместимости с вашей цепочкой инструментов, так как они будут использовать различные версии binutils и, возможно, различные ABI.

Сборка оригинальных досок Linux в Cygwin
----------------------------------------

Некоторые конфигурации досок по умолчанию настроены для сборки под Linux, а другие — для сборки под Windows с использованием Cygwin. В различных конфигурациях также могут использоваться различные цепочки инструментов. Можно изменить настройки по умолчанию. Например, вот что вам нужно сделать, чтобы скомпилировать конфигурацию Linux по умолчанию в окружении Cygwin с использованием цепочки инструментов CodeSourcery для Windows. После создания "готовой" конфигурации NuttX запустите целевой 'menuconfig' и установите следующие параметры:

    Настройка сборки -> Платформа хоста сборки -> Windows
    Настройка сборки -> Окружение сборки Windows -> Cygwin
    Тип системы -> Выбор цепочки инструментов -> Цепочка инструментов GNU CodeSourcery под WindowsВ Windows 7 может потребоваться открыть оболочку Cygwin с правами администратора (опция "Запуск как", правый клик мышью). Вы найдете ошибки типа "Доступ запрещен".

Восстановление после неправильной конфигурации
----------------------------------------------

Многие люди делают ошибку, настраивая NuttX с помощью "готовой" конфигурации и затем просто запуская 'make', что приводит к катастрофическим последствиям; сборка может завершиться неудачей с загадочными, неинтерпретируемыми и необратимыми ошибками сборки. Например, если вы сделаете это с неизмененной конфигурацией Linux в окружении Windows/Cygwin, вы повредите среду сборки. Среда будет повреждена из-за проблем с путями POSIX против путей Windows и проблемами, связанными со ссылками. Если вы допустили эту ошибку, самый простой способ восстановления — начать заново: выполните 'make distclean', чтобы удалить все следы поврежденной конфигурации, переустановите конфигурацию с нуля и убедитесь, что правильно настроили конфигурацию для вашей платформы перед попыткой сборки снова. Просто исправление конфигурационного файла после того, как вы создали неправильную конфигурацию с помощью команды 'make', недостаточно.

ДОКУМЕНТАЦИЯ
^^^^^^^^^^^^^Дополнительная информация может быть найдена в директории Documentation/ и также в README файлах, рассредоточенных по всему дереву исходного кода. Документация представлена в формате HTML и может быть доступна через загрузку следующего файла в вашем веб-браузере:Документация NuttX также доступна онлайн по адресу http://www.nuttx.org.Ниже приведен руководство по доступным README файлам в дереве исходного кода NuttX:

```
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/
   |   |   |   |- efm3s-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
   |   |   |- 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/
   |   |   |   |   |   `- README.txt
   |   |   |   |   `- 
   |   |   |   |- nrf52/
   |   |   |   |   |- nrf52-generic/
   |   |   |   |   |   `- README.txt  |   |   |   |   |   `- 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
  |   |   |   |- 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-xplained/
  |   |   |   |   `- README.txt
  |   |   |   |- samv71-xult/
  |   |   |      `- README.txt
  |   |   |- stm32/
  |   |   |   |- axoloti/
  |   |   |   |   `- README.txt
  |   |   |   |- clicker2-stm32/
  |   |   |   |   `- README.txt
  |   |   |   |- cloudctrl/
  |   |   |   |   `- 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
  |   |   | |   |   |   |   `- 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
  |   |   |   |   |- ЧИТАЕМЕ.txt
  |   |   |   |- stm32_tiny/
  |   |   |   |   |- ЧИТАЕМЕ.txt
  |   |   |   |- stm3210e-eval/
  |   |   |   |   |- ЧИТАЕМЕ.txt
  |   |   |   |- stm3220g-eval/
  |   |   |   |   |- ЧИТАЕМЕ.txt
  |   |   |   |- stm3240g-eval/
  |   |   |   |   |- ЧИТАЕМЕ.txt
  |   |   |   |- stm32butterfly2/
  |   |   |   |- stm32f103-minimum/
  |   |   |   |   |- ЧИТАЕМЕ.txt
  |   |   |   |- stm32f334-disco/
  |   |   |   |   |- ЧИТАЕМЕ.txt
  |   |   |   |- stm32f3discovery/
  |   |   |   |   |- ЧИТАЕМЕ.txt
  |   |   |   |- stm32f411e-disco/
  |   |   |   |   |- ЧИТАЕМЕ.txt
  |   |   |   |- stm32f429i-disco/
  |   |   |   |   |- ЧИТАЕМЕ.txt
  |   |   |   |- stm32f4discovery/
  |   |   |   |   |- ЧИТАЕМЕ.txt
  |   |   |   |- stm32ldiscovery/
  |   |   |   |   |- ЧИТАЕМЕ.txt
  |   |   |   |- stm32vldiscovery/
  |   |   |   |   |- ЧИТАЕМЕ.txt
  |   |   |   |- viewtool-stm32f107/
  |   |   |       |- ЧИТАЕМЕ.txt
  |   |   |- stm32f0l0g0/
  |   |   |   |- b-l072z-lrwan1/
  |   |   |   |   |- ЧИТАЕМЕ.txt
  |   |   |   |- nucleo-f072rb/
  |   |   |   |   |- ЧИТАЕМЕ.txt
  |   |   |   |- nucleo-f091rc/
  |   |   |   |   |- ЧИТАЕМЕ.txt
  |   |   |   |- nucleo-g070rb/
  |   |   |   |   |- ЧИТАЕМЕ.txt
  |   |   |   |- nucleo-g071rb/
  |   |   |   |   |- ЧИТАЕМЕ.txt
  |   |   |   |   |- ЧИТАЕМО.txt
   |   |   |   |- stm32f051-discovery/
   |   |   |   |   |- ЧИТАЕМО.txt
   |   |   |   |- stm32f072-discovery/
   |   |   |       |- ЧИТАЕМО.txt
   |   |   |   |- stm32f7/
   |   |   |   |   |- nucleo-144/
   |   |   |   |   |   |- ЧИТАЕМО.txt
   |   |   |   |   |- stm32f746g-disco/
   |   |   |   |   |   |- configs/fb/ЧИТАЕМО.txt
   |   |   |   |   |   |- configs/nxdemo/ЧИТАЕМО.txt
   |   |   |   |   |   |- configs/nxterm/ЧИТАЕМО.txt
   |   |   |   |   |   |- ЧИТАЕМО.txt
   |   |   |   |   |- stm32f746-ws/
   |   |   |   |   |- stm32f769i-disco/
   |   |   |       |- ЧИТАЕМО.txt
   |   |   |   |- stm32h7/
   |   |   |   |   |- nucleo-h743zi/
   |   |   |       |- ЧИТАЕМО.txt
   |   |   |   |- stm32l4/
   |   |   |   |   |- b-l475e-iot01a/
   |   |   |   |   |   |- ЧИТАЕМО.txt
   |   |   |   |   |- nucleo-l432kc/
   |   |   |   |   |   |- ЧИТАЕМО.txt
   |   |   |   |   |- nucleo-l452re/
   |   |   |   |   |   |- ЧИТАЕМО.txt
   |   |   |   |   |- nucleo-l476rg/
   |   |   |   |   |   |- ЧИТАЕМО.txt
   |   |   |   |   |- nucleo-l496zg/
   |   |   |   |   |   |- ЧИТАЕМО.txt
   |   |   |   |   |- stm32l476-mdk/
   |   |   |   |   |   |- ЧИТАЕМО.txt
   |   |   |   |   |- stm32l476vg-disco/
   |   |   |   |   |   |- ЧИТАЕМО.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/
 |   |   |       |- 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/
 |   |   |- gap8/
 |   |   |   `- gapuino/
 |   |   |       `- README.txt
 |   |   `- nr5m100/
 |   |       `- nr5m100-nexys4/
 |   |           `- README.txt
 |   |- 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 в дереве каталогов приложений/apps/:
```

|   |   |   |   `- 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  
```Ниже представлен список доступных файлов README в дереве каталогов приложений/apps/:```apps/
 |- примеры/
 |   |- bastest/README.txt
 |   |- json/README.txt
 |   |- pashello/README.txt
 |   `- README.txt
 |- gpsutils/
 |   `- minmea/README.txt
 |- графика/
 |   |- tiff/README.txt
 |   `- путешественник/инструменты/tcledit/README.txt
 |- интерпретаторы/
 |   |- bas/
 |   |  `- README.txt
 |   |- ficl/
 |   |  `- README.txt
 |   |- README.txt
 |   `- README.txt
 |- modbus/
 |   `- README.txt
 |- сетевые_инструменты/
 |   |- discover/
 |   |  `- README.txt
 |   |- ftpc/
 |   |  `- README.txt
 |   |- json/
 |   |  `- README.txt
 |   |- telnetd/
 |   |  `- README.txt
 |   `- README.txt
 |- nshlib/
 |   `- README.txt
 |- NxWidgets/
 |   `- README.txt
 |- система/
 |   |- cdcacm/
 |   |  `- README.txt
 |   |- i2c/
 |   |  `- README.txt
 |   |- inifile/
 |   |  `- README.txt
 |   |- установка/
 |   |  `- README.txt
 |   |- nsh/
 |   |  `- README.txt
 |   |- nxplayer/
 |   |  `- README.txt
 |   |- psmq/
 |   |  `- README.txt
 |   |- symtab/
 |   |   `- README.txt
 |   |- термкюре/
 |   |   `- README.txt
 |   |- usbmsc/
 |   |  `- README.txt
 |   |- zmodem/
 |      `- README.txt
 `- беспроводные_технологии
     |- блютуз/
     |  |- btsak/
     |     |- README.txt
     |- ieee802154
        |- i8sak/
           |- README.txt

Дополнительные файлы README.txt в других связанных репозиториях:

NxWidgets/
 |- Doxygen
 |   `- README.txt
 |- инструменты
 |   `- README.txt
 |- UnitTests
 |   `- README.txt
 `- README.txt

buildroot/
 |- README.txt

инструменты/
 |- README.txt

uClibc++
 |- README.txt