Gcc arm embedded windows

Проблема 2000h (или как собрать GCC-ARM-embedded линкером большой проект)

Тема в первую очередь будет интересна пользователям среды Eclipse IDE/GNU ARM plugin/GCC ARM compiler под Windows.

Всякий уважающий себя эмбеддер рано или поздно вырастает из светодиодных моргалок, забрасывает авр-ки на полку, и пересаживается на более продвинутые чипы. С ростом возможностей микроконтроллера увеличивается и сложность встроенных программ. Мегабайты и Мегамипсы так и просят прикрутить к проекту графический ЖКИ, стек TCP/IP, файловую систему, а для полного счастья — конечно ещё и фриртоску.

И вот в один прекрасный момент проект перестаёт собираться. А виноват в этом может быть (ну конечно же, Билл Гейтс) лимит на длину командной строки в 8192 символа. Что же делать?

Давайте разбираться.

Утилиты из комплекта GNU ARM compiler имеют досоподобный интерфейс — все необходимые ключи и параметры передаются через командную строку. Самая длинная строка с параметрами в итоге достаётся линкеру. Она содержит список всех объектных файлов (в том числе пути их расположения), необходимых для сборки конечного hex-файла.

Так вот, если длина полученной строки с параметрами более 8191 символов, линкер начинает ругаться:

Он не может найти объектный файл, в имени которого почему-то отсутствует один смвол. В данном примере нет пробела между именами двух файлов.

Майкрософт утверждает, что командная строка должна быть не больше чем 8191 (либо 2047, в зависимости от ОС) символов. В моём случае линкеру передаётся 8613 буковок, в итоге попадаем под санкции и отдаём в виде налога 8192-ю букву.

Причём любопытно, что выпадает только каждый 8192-й символ, а вся остальная строка передаётся правильно. Ну а верхний лимит командной строки — 32768 байт (проверено), сверх этого передать ничего уже не получится.

Рассмотрим варианты решения проблемы.

1. Сократить длину пути и имени файлов

2. Использовать статические библиотеки

Создаём отдельный проект, в котором собираем массу исходников в одну my_lib.a библиотеку. Затем скармливаем её линкеру в базовом проекте. Длина проблемной командной строки кардинально сокращается. Если файлов слишком много, делаем несколько библиотек.

Отличный вариант. Побочным положительным эффектом будет сокращение времени компиляции основного проекта (т.к. куча файлов была ранее скомпилирована в my_lib.a). Но.

Довольно часто библиотечные модули (характерный пример — стек LwIP) имеют массу настроек в виде директив условной компиляции. Поэтому полученная библиотека будет актуальна только для конкретного проекта. Т.е. её нужно будет хранить, архивировать, сопровождать всегда совместно с базовым проектом.
А если одновременно в работе несколько проектов? Брр, неудобно…

3. Стать мастером make-файлостроительства

Если писать make-файл вручную, то проблему 2000h тоже можно легко обойти. Например, собрать проект в виде набора тех же статических библиотек, а потом объединить их в один выходной hex. При использовании ручного makefile открывается огромная масса других полезных возможностей. Однако…

Стать make-мастером — ой как не просто. И потом потребуется постоянно держать себя в форме. Иначе по прошествии пары-другой месяцев без тренировки приходится долго вспоминать, как же вся эта штука работает. Поэтому обычно предпочитаю использовать make-файл, автоматически создаваемый GNU ARM плагином.

upd: безусловно, если заниматься программированием серьёзно, познать make-утилиту всё равно придётся. И оно того стоит.

4. Передать строку параметров линкеру через отдельный файл

Говорят, ребята из Freescale (CodeWarrior) так и делают. Как это сделать в связке GNU make + GCC, не разобрался. Если таки можно — снова потребуется править makefile (возвращаемся к варианту №3).

upd: благодаря Gleserg , дополню этот пункт.

В автоматически создаваемом makefile есть три точки расширения
Они позволяют дополнить процесс сборки проекта своими фичами.

Как вариант, предлагается (см. оригинал) через файл makefile.defs подключить скрипт вида
который и поместит список необходимых объектных файлов в файл ObjectList. Для передачи этого файла линкеру в параметрах проекта

Project properties -> C/C++ Build -> Settings -> закладка Tool Settings -> Cross ARM C++ Linker -> строка Command Line pattern

5. Перейти на линукс

хм, резонансная фраза получилась, больше сотни комментариев 🙂

6. Использовать костыль-корректор командной строки

Собственно, этот вариант и послужил стимулом для написания данной заметки.

В очередной раз посетила мысль: ну неужели никто проблему 2000h так и не решил? И о, чудо! Гуглер наконец выдал свежее решение. Фтопку варианты 1..6. Нужно всего лишь взять пропатченные Build Tools.

PS: Liviu, you probably read this, and I know you are using Mac OS, and you are not a fan of Windows environment for good reasons. On behalf of the Windows user community: THANK YOU, THANK YOU, THANK YOU!

Надеюсь, на этом вопрос можно считать закрытым. По крайней мере пока не доберёмся до следующей границы в 32к (в запасе имеем безлимитный метод №4).

Удачного вам гуглинга и кодинга!

Комментарии ( 177 )

5. Перейти на линукс
Говорят, там этой проблемы нет. В общем, на любителя.

Извините, немножко GNU-сю для молодняка.

Проблемы возникают, когда люди смешивают разные парадигмы. Затронутая тема — пример такой проблемы.

Парадигма UNIX/Linux основана на том, что взаимодействие пользователя и программ осуществляется посредством «телетайпа». А парадигма Windows — на визуальном интерфейсе.

Что такое «телетайп»? Телетайп — это текстовый экран и клавиатура. И более ничего другого! Другие названия телетайпа — терминал, консоль. (Для нас пока их отличия друг от друга не важны!)
Причем, парадигма UNIX рассматривает телетайп и сам компьютер как два независимых (отдельных) устройства. Комп обычно называют «хостом». Согласно этому положению, телетайп может находится в любом месте. Примеры:

* на том же компе (ноутбук, настольный комп)
* на соседнем столе, в соседней комнате (локальная сеть, сервер + клиент)
* в другом городе, в другой стране
* в космосе (космическая станция), в атмосфере (дрон)

Ну и так далее. Важно понять, что хост находится в одном месте, а пульт управления — в другом. Между хостом и пультом управления имеется канал связи.

Следует заметить, что поскольку UNIX/Linux — это есть многозадачные многопользовательские ОС-и, то они допускают одновременное подключение к хосту сразу нескольких терминалов (пользователей).

Так вот, поскольку терминал — это текстовый экран и клавиатура, то это положение накладывает серьезное ограничение на способы взаимодействия пользователя и программы. Здесь нельзя, как Виндовсе указать мышкой или получить графическую картинку. Здесь допустимо только текстовое взаимодействие. Другими словами, интерфейс — ТЕКСТОВЫЙ. В связи с этим в UNIX развиты текстовые методы взаимодействия пользователя и программ.

Жизнь день ото дня становится всё сложнее и сложнее. И даже в сложном мире жить как-то надо. Поэтому в мире UNIX нет ничего удивительного в том, что посредством командной строки в программу приходится передавать много-килобайтные данные. Как-то давно я что-то компилировал, и я хорошо помню, что команда на компиляцию занимала целых два экрана! Да, тогда я удивлялся и негодовал — как такое вообще имеет право жить! Но прошло несколько лет, и я понял, что мои представления о «правильности» мирового устройства основаны на парадигме Виндовса. А UNIX — это совершенно другой мир.

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

Скажу еще пару слов о парадигме Виндовс.

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

Windows, в отличие от UNIX, изначально разрабатывалась как КОММЕРЧЕСКАЯ Операционная система, назначение которой — продаваться на рынке, принося владельце бабло. Поэтому Виндовс разрабатывалась в прицеле не на специалистов, готовых изучать «компьютерную» науку, а на необученных широких народных масс, которым любое упоминание об учёбе наводит на тоску. Учиться мало-кто любит и хочет. И чтобы продажи операционки не встали колом, пользователь не должен испытывать негатив от её освоения. Всё должно быть просто и понятно, как велосипед — сел и поехал!

Понимание этого положения привело к пониманию того, что нужно делать. Нужно на экран вывести варианты и предоставить пользователю ткнуть пальцем и выбрать один из них. Учить, запоминать ничего не надо! Нужно только овладеть умением пользоваться мышкой. В пределе — даже не надо уметь читать — цветные картинки рулят!

Так вот, согласно парадигме Виндовс взаимодействие пользователя и программы должно происходить посредством выбора того, что отображено на экране — радиокнопки, чек-боксы, списки, менюшечки и так далее. Когда это всё графическое хозяйство будет настроено нужно нажать единственную кнопку «ОК» («Выполнить», «Откомпилировать», «Сделать мне приятно» . )

Причем, заданные таким образом параметры уже находятся во власти программы. То есть на самом деле, если их перевести в текстовый эквивалент, их объем может быть очень большой. Мне сложно назвать какую-то цифру. Ну, предположим, — несколько мегабайт! И это не проблема!

Непроблема потому, что мы осуществляем взаимодействие (пользователь и программа) в своей родной среде. Если в Винде работать по-Виндовому, а в Линуксе — по Линуксовому, то проблем вообще не возникает! Проблемы возникают когда одну технологию напяливают на другую.

И в самом деле, когда в среде UNIX/Linux мы пытаемся что-то откомпилировать и набираем в консоли длинную команду, то компилятор (программа) еще не работает! Мы только-только готовим задание для работы. Поэтому среда должна нам обеспечить очень большие возможности для указания очень большого числа параметров. Но противоречия здесь нет! Это и есть парадигма UNIX.

Когда в Виндовой программе мы указываем очень большое количество параметров, то программа уже работает. Виндовая среда в этом взаимодействии не участвует. Поэтому всё взаимодействие (пользователя и программы) протекает внутри программы и под её контролем. Это парадигма Виндовс. И противоречия здесь так же нет!

Всё вроде бы хорошо, если оставаться в рамках выбранной технологии, то можно очень даже комфортно жить.

Однако, мир стал интернет-ориентированным. Это наложило отпечаток на технологии. Технологии UNIX изначально подразумевали, что хост и терминал — это два устройства, связанные между собой какими-то линиями связи. А вот Виндовс — это персональный компьютер, у которого процессорный блок, клавиатура и дисплей — это единое целое. И нельзя одно от другого дистанцировать.

Поэтому, UNIX/Linux легко допускает удаленное взаимодействие (пользователя и программ), а Виндовс — с определенными трудностями. Удаленное управление в UNIX/Linux находится под контролем самой операционной системы. Поэтому ЛЮБЫЕ (неграфические) программы в Линуксе уже сразу готовы к сетевым операциям. А вот в Виндовсе — не всё так просто! Если программа должна взаимодействовать с удаленным пользователем, то она сама должна решать эти сетевые проблемы. И если Виндовая программа не умеет работать удаленно, то — проблемы!

В среде UNIX/Linux — контроль взаимодействия между программой и пользователем осуществляется самой средой. Поэтому программе достаточно принимать данные из стандартного потока ввода, а результат работы выдавать в стандартный поток — и этого уже достаточно для любого взаимодействия между пользователем и программой — будь то взаимодействие локально (на том же самом компе (хосте)) или удаленно (управление космическим аппаратом, умным домом и т.д.).

Надеюсь, я не очень утомил вас своим рассказом. Я попытался объяснить, чем объясняется что настоящие специалисты выбирают тяжелое оружие, не смотря на его брутальность и отсутствие розовеньких бантиков. (Для тех, кто не понял — им нужно решать задачи, а не выглядеть красиво.)

(Хрена-се! Целая статья получилась. От-это я в ударе!)

и я хорошо помню, что команда на компиляцию занимала целых два экрана

Источник

Настраиваем бесплатную сборку для написания и отладки программ под микроконтроллеры на основе ядра ARM под Windows 10

Идея написать статью (которая войдет в цикл статей для новичков, остро жаждущих создавать что-то на микроконтроллерах при почти нулевых знаниях в области программирования в принципе) пришла мне после того, как мне пришлось немного отвлечься от своих основных дел, чтобы помочь другу настроить рабочую среду для написания софта под его небольшой домашний проект на основе board-а с stm32f103 на борту. Я рассчитывал, что это займет около получаса, максимум час, но ноутбук друга был на Windows 10 x64, что для меня уже непривычно (сам работаю в Ubuntu). По итогу мы потратили практически 8 часов на настройку и создание простого проекта, борясь с многими не очевидными вещами.

Параллельно с этим мне пришлось подробно объяснять, какой элемент сборки для чего нужен, а так же, как эти элементы взаимодействуют между собой, поскольку друг до этого никогда ранее с микроконтроллерами не сталкивался (от слова «видел Arduino в магазине»).

Данный материал призван помочь начинающим быстро и без проблем настроить полностью бесплатную инфраструктуру для работы с микроконтроллерами, а так же понять, каким образом происходит сборка итогового бинарного файла. Производитель и модель микроконтроллера на этапе настройки этой инфраструктуры неважны. Главное, чтобы в его основе лежало ядро ARM.

Оглавление

1. Постановка задачи.
2. Выбор программных средств реализации.
3. Ставим Eclipse Neon 3.
   • Скачиваем установщик Eclipse.
   • Устанавливаем JRE.
   • Устанавливаем Eclipse.
   • Устанавливаем в Eclipse плагин GNU ARM Eclipse.
   • Патчим JRE (на случай появления ошибки при установке плагина).
   • Устанавливаем GNU ARM Eclipse Windows Build Tools.
4. Скачиваем и устанавливаем GNU ARM Embedded Toolchain.
5. Устанавливаем OpenOCD.
6. Устанавливаем драйвера на st-link v2.
7. Разбираемся, как все это работает.
8. Заключение.

Постановка задачи

Выбор программных средств реализации

Для решения поставленных задач нам потребуются следующие программные продукты:

1. Eclipse Neon 3 для C/C++ (самая последняя версия на момент написания статьи). Будет использована нами как IDE (текстовый редактор с удобным авто дополнением + удобства по взаимодействию со средствами отладки), в которой мы будем писать код.
2. JRE (на момент написания статьи, самая последняя версия 1.8.0). Без него не запустится установщик Eclipse (ну и сам Eclipse).
3. GNU ARM Embedded Toolchain (на момент написания статьи, самой последней версией был 5_4-2016q3-20160926). Это комплекс нужных нам программных решений (таких как компилятор C кода «gcc», C++ кода «g++», линкер — «ld», средство загрузки и отладки финальной прошивки — «gdb» и многие другие), благодаря которым мы получим из наших файлов с исходным кодом файл с разрешением «.elf», представляющий из себя бинарный файл прошивки микроконтроллера, который в последствии будет загружен в микроконтроллер (об этом ниже).
4. OpenOCD 0.10.0. С помощью него мы будем загружать наш «.elf» файл программы в микроконтроллер (на деле, OpenOCD предоставляет связь между gdb из указанного выше toolchain-а и отладчиком).

Помимо перечисленных средств, нам нужно будет поставить еще несколько небольших пакетов, о которых я скажу уже непосредственно в процессе установки.

Ставим Eclipse Neon 3

Как говорилось выше, для того, чтобы писать код, нам нужен текстовый редактор, в котором было бы удобно писать (различные методы авто-дополнения, поиска по проекту, навигация по файлам и т.д). А после того, как мы написали код, было бы неплохо, чтобы его компиляция, сборка и исполнение — были бы делом пары комбинаций клавиш (или кликов мышью, кому как удобно).
Для этих целей я использую Eclipse. Помимо редактора, он представляет еще возможность подключения различных расширений, которые значительно упрощают жизнь разработчика, сводя всю рутинную работу (сборку, компоновку, загрузку программы в контроллер) к паре кликов/нажатий.

Источник