Toolchain for MSP430

Краткое руководство как развернуть у себя на компе тулчейн для работы с MSP430 находится тут:

https://zhevak.wordpress.com/2012/06/08/toolchain-for-msp430-краткое-изложение/

Те, кто не очень разбирается как это делать, читайте далее.

Преамбула
(Неинтересно. В принципе, можете пропустить.)

Я использую микроконтроллеры MSP430. Не очень сильно. Но если быть честным, то только один — MSP430F2001. Самый простой, а следовательно — самый дешевый. Не думайте, что чем круче микроконтроллер, тем важнее разработчик. (Я обижусь!) На самом деле у меня серийно изготовляется целое семейство различных устройств, где используется этот камень. Количество изделий исчисляется десятками тысяч. (Ну вот, похвастался, и стало не так стыдно за себя из-за мелкого микроконтроллера.)

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

Так вот, до недавнего времени я опирался на MSP430F2001 и, в общем-то, горя не знал. Но со временем всякая востребованная на рынке и долго живущая разработка имеет свойство укрупняться и обрастать дополнительной функциональностью. Говоря по нашему — жиреть.

Вот и мне с какого-то времени начало элементарно не хватать ножек процессора. И начал приглядываться к другим камням с бóльшим количеством ножек. Надо сказать, что фирма Texas Instruments на месте тоже не стоит, и пару лет приступила к выпуску новой серии MSP430G.

— А почему бы их не попробовать? — подумал я, — тем более, что стоимость камней этой серии даже немного меньше, чем серии MSP430F2xxx.

Всё бы ничего, если бы не тулчейн! Это ведь только в Шindows принято воровать чужой труд. Я имею в виду то, что мало кто из разработчиков использует купленный компилятор. В основном люди устанавливают компилятор, а потом его «крякают». Тем и живут! Несколько лет назад я добровольно отказался идти этим путём. (Я потом как-нибудь расскажу, почему имеет смысл жить честно.)

Я использую Ubuntu-10.04 LTS. В репозиториях этого дистрибутива отсутствуют пакеты тулчейна для MSP430. Примерно месяц назад фирма Canonical выпустила еще один LTS (Long Term Support) дистрибутив — Ubuntu-12.04 LTS. Дистрибутивы LTS хороши тем, что Canonical поддерживает их актуальность (то есть предоставляет подновления) в течение более длительного периода времени.

Например, был такой хороший дистрибутив Ubuntu-10.10. Я на нем сидел достаточно долгое время. Всем был хорош дистрибутив, но прошло полтора года и Canonical перестала его поддерживать. Вах! И куда теперь податься бедному крестьянину?

Пробовал я более свежие дистрибутивы (11.04, 11.10), не понравились они мне. Основные претензии две. Первая — дистрибутивы стали «жирнее» (для нормальной работы им нужно больше памяти и процессор по-быстрее). И вторая — мне не нравится интерфейс Unity. Ну, не вкусил я его, не понимаю его прелести! Мне удобней работать в втором Гноме. Поэтому, пару раз я пробовал их установить и поработать под ними, но каждый раз испытывая трудности и дискомфорт, сносил и уходил на 10.04. В общем-то я и сейчас сижу на 10.04.

Но самое забавное это то, что в в новейшем дистрибутиве 12.04 имеются пакеты тулчейна для MSP430. И что более всего радует — тулчейн поддерживает новые типы камней MSP430G.

Всё хорошо, но мне с моим стареньким компом этот путь «заказан». Поэтому мне пришлось искать альтернативные пути для работы с новыми камнями. И я их нашел, обкатал и сейчас с чувством особой гордости возвращаю полученные знания во благо Linux-сообщества.

Амбула
(Описание технологии установки тулчейна для MSP430)

Не думайте, что я такой «вумный», и все сам изобрел. Нет! Я воспользовался Инернетом. Я нагуглил источник

http://sourceforge.net/projects/mspgcc/files/mspgcc

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

Прежде чем мы начнем, я скажу, что я проверил установку на двух дистрибутивах — Debian-6.04 и Ubuntu-10.04.4 LTS. Сборка и установка тулчейна для MSP430 происходит почти одинаково. Разница состоит только в том, что в Ubuntu все происходит в пользовательском аккаунте (с правами пользователя) кроме самой установки тулчейна, а в Debian — вы всё полностью делаете под root-ом. Так удобнее. Далее по тексту я эту разницу отмечу особо, так что не ошибетесь!

Поехали!

Для сборки тулчейна нам необходимы исходники этого тулчейна. А еще нам бы не помешало накануне сборки установить кое-какие пакеты в систему. А вообще, самый правильный джедайский путь начинается с захода в консоль и выполнения команд:

$ sudo apt-get update
$ sudo apt-get upgrade

— это если вы работает под Ubuntu. Если у вас Debian, то вам нужно зайти в консоль под root-ом и выполнить те же команды, только без sudo:

$ su
# apt-get update
# apt-get upgrade

Теперь самое время установить дополнительные пакеты, которые нам понадобятся для успешной сборки тулчейна.

Например, источник

http://hackaday.com/2010/08/11/how-to-launchpad-programming-with-linux/

( http://forum.e-lug.ru/viewtopic.php?id=666 )

рекомендует установить в Ubuntu следующие пакеты:

$ sudo apt-get install gcc-4.4 texinfo patch libncurses5-dev \
    zlibc zlib1g-dev libx11-dev libusb-dev libreadline6-dev

Для «чистого», только-что установленного Debian-а мне понадобилось установить немножко иной состав пакетов:

# apt-get install make libncurses5-dev expat zlib1g-dev \
    libusb-dev libreadline6-dev

Идем далее.

В домашнем директории нужно создать поддиректорий msp430-build и зайти в него. Для Debian это будет домашний директорий root-а, а для Ubuntu — домашний директорий пользователя. Далее все действия будем выполнять в этих поддиректориях.

$ mkdir msp430-build
$ cd !$

Примечание
Для Debian вместо значка $ будет указываться значок #, который говорит об особом статусе пользователя. Чтобы не засорять текст публикации лишней дублирующейся информацией я не буду повторять те же самые фрагменты кода, но с другим значком.

Теперь нам надо получить к себе на комп, в только-что созданный директорий исходники тулчейна. Все эти исходники создаются (и поддерживаются) разными людьми, поэтому они находятся на разных ресурсах интернета. И нам нужно пройтись по всем этим ресурсам и скачать исходники к себе на комп.

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

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

#!/bin/bash
# Закачка необходимых компонет для сборки тулчейна для MSP430

wget http://ftpmirror.gnu.org/gcc/gcc-4.6.3/gcc-core-4.6.3.tar.bz2
wget -c http://sourceforge.net/projects/mspgcc/files/mspgcc/mspgcc-20120406.tar.bz2
wget -c http://sourceforge.net/projects/mspgcc/files/msp430mcu/msp430mcu-20120407.tar.bz2
wget -c http://sourceforge.net/projects/mspgcc/files/msp430-libc/msp430-libc-20120224.tar.bz2
wget -c http://ftpmirror.gnu.org/binutils/binutils-2.21.1a.tar.bz2
wget -c http://ftpmirror.gnu.org/gdb/gdb-7.2a.tar.bz2
wget -c http://sourceforge.net/projects/mspdebug/files/mspdebug-0.19.tar.gz

wget -c ftp://gcc.gnu.org/pub/gcc/infrastructure/mpfr-2.4.2.tar.bz2
wget -c ftp://gcc.gnu.org/pub/gcc/infrastructure/gmp-4.3.2.tar.bz2
wget -c ftp://gcc.gnu.org/pub/gcc/infrastructure/mpc-0.8.1.tar.gz

и сохраните файл под именем gethere.sh . Я рекомендую вам не бросаться сейчас выполнять этот скрипт, а прочитать статью до конца и сохранить в виде файлов еще несколько скриптов, которые находятся далее по тексту.

Вообще, скриптовый файл — это исполняемый файл. Иначе говоря, это есть программа. В принципе, вы может запустить скриптовый файл на исполнение несколькими способами.

Если скриптовый файл не имеет статуса «исполнения», то есть вы его создали как обычный текстовый файл, то его можно запустить следующим способом. Например, так:

$ bash gethere.sh

Но это не совсем удобно. Правильнее будет присвоить текстовому файлу статус «исполнения». Тогда он превратиться в программу, и его можно будет запускать на исполнение точно так же как все  другие программы.

Я предполагаю, что вы прочитали статью до конца и создали все необходимые скриптовые файлы. Теперь давайте одним махом все эти скриптовые файлы сделаем программами:

$ chmod +x *.sh

Теперь созданные программы можно запускать самым обычным способом:

$ ./gethere.sh

Как вы уже успели наверное заметить, все закаченные файлы — это сжатые архивы. Давайте их разожмем и разархивируем.

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

Разжатие и разархивирование нескольких файлов удобно опять-таки оформить в виде скрипта. Сохраним его под именем extract.sh :

#!/bin/bash
# Разжатие и разархивирование

tar xvfj binutils-2.21.1a.tar.bz2
tar xvfj gcc-core-4.6.3.tar.bz2
tar xvfj gdb-7.2a.tar.bz2
tar xvfj mspgcc-20120406.tar.bz2
tar xvfj msp430mcu-20120407.tar.bz2
tar xvfj msp430-libc-20120224.tar.bz2
tar xvfz mspdebug-0.19.tar.gz

# Зайдем в директорий gcc и сразу в него разархивируем некоторые
# компоненты и создадим ссылки
cd gcc-4.6.3

tar xjf ../mpfr-2.4.2.tar.bz2
tar xjf ../gmp-4.3.2.tar.bz2
tar xzf ../mpc-0.8.1.tar.gz

ln -sf mpfr-2.4.2 mpfr
ln -sf gmp-4.3.2 gmp
ln -sf mpc-0.8.1 mpc

cd ..

Следующий наш шаг состоит в наложении патчей. Снова готовим скриптовый файл и сохраняем его под именем patch.sh :

#!/bin/bash
# Наложение патчей

cd binutils-2.21.1
patch -p1<../mspgcc-20120406/msp430-binutils-2.21.1a-20120406.patch
cd ..

cd gcc-4.6.3
patch -p1<../mspgcc-20120406/msp430-gcc-4.6.3-20120406.patch
cd ..

cd gdb-7.2
patch -p1<../mspgcc-20120406/msp430-gdb-7.2a-20111205.patch
cd ..

Ну и последний наш шаг будет с создании скрипта make.sh для сборки и установки тулчейна — собственно, того, ради чего всё это затевалось.

Этот скрипт для сборки тулчейна под Ubuntu:

#! /bin/bash
# Сборка и установка тулчейна для MSP430

mkdir binutils-2.21.1-msp430 gcc-4.6.3-msp430 gdb-7.2-msp430

cd binutils-2.21.1-msp430
../binutils-2.21.1/configure --target=msp430 --program-prefix="msp430-"
make
sudo make install
cd ..

cd gcc-4.6.3-msp430
../gcc-4.6.3/configure --target=msp430 --enable-languages=c --program-prefix="msp430-"
make
sudo make install
cd ..

cd gdb-7.2-msp430
../gdb-7.2/configure --target=msp430 --program-prefix="msp430-"
make
sudo make install
cd ..

cd msp430mcu-20120407
sudo MSP430MCU_ROOT=`pwd` ./scripts/install.sh /usr/local/
cd ..

cd msp430-libc-20120224/src
make
sudo PATH=$PATH make PREFIX=/usr/local install
cd ../..

cd mspdebug-0.19
make
sudo make install
cd ..

echo ALL DONE

А этот — для сборки под Debian:

#! /bin/bash
# Сборка и установка тулчейна для MSP430

mkdir binutils-2.21.1-msp430 gcc-4.6.3-msp430 gdb-7.2-msp430

cd binutils-2.21.1-msp430
../binutils-2.21.1/configure --target=msp430 --program-prefix="msp430-"
make
make install
cd ..

cd gcc-4.6.3-msp430
../gcc-4.6.3/configure --target=msp430 --enable-languages=c --program-prefix="msp430-"
make
make install
cd ..

cd gdb-7.2-msp430
../gdb-7.2/configure --target=msp430 --program-prefix="msp430-"
make
make install
cd ..

cd msp430mcu-20120407
MSP430MCU_ROOT=`pwd` ./scripts/install.sh /usr/local/
cd ..

cd msp430-libc-20120224/src
make
PATH=$PATH make PREFIX=/usr/local install
cd ../..

cd mspdebug-0.19
make
make install
cd ..

echo ALL DONE

Постамбула
(Наведение блеска)

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

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

Делается это с помощью ключа -j N. Вместо N вы должны подставить количество ядер. в моем случае, с двуядерным процом команды будут выглядеть так:

...

cd binutils-2.21.1-msp430
../binutils-2.21.1/configure --target=msp430 --program-prefix="msp430-"
make -j 2
sudo make install
cd ..

...

Я обращаю ваше внимание на то, что этот ключ нужно подставлять только в той команде make, которая занимается компиляцией и сборкой. В тех командах make, которые производят установку программного обеспечения (это команды типа sudo make install), в них ключ подставлять не надо. Вреда, конечно, от подстановки не будет, но и пользы — тоже никакой!

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

Поэтому, давайте создадим переменную NPROCS и присвоим ей число (количество ядер) и будем ее использовать в командах вместо конкретного числа.

...
export NPROCS=2
...

cd binutils-2.21.1-msp430
../binutils-2.21.1/configure --target=msp430 --program-prefix="msp430-"
make -j ${NPROCS}
sudo make install
cd ..

...

Хорошо, если вы знаете о своем компе — сколько у него ядер. А если не знаете? Или, допустим, вы забыли подкорректировать и скрипт запускаете его на другом компе, у которого иное количество ядер. Что делать?

Проблема решается просто. Нужно программно определить количество ядер проца. Это можно сделать как минимум двумя способами.

Например, вот так:

...
export NPROCS=`getconf _NPROCESSORS_ONLN`
...

или так

...
export NPROCS=`cat /proc/cpuinfo | grep processor | wc -l'
...

В первом случае тупо вызывается утилита getconf, которая возвращает значение переменной _NPROCESSORS_ONLN. А вот второй случай куда интереснее! Там используются аж два неименованных канала (пайпа, «|»), через которые передается информация от одно команды к другой.

Обратите внимание! В обоих вариантах использутся обратные апострофы — (`строка`). Это характерно для UNIX-систем!

Если строку взять в кавычки («строка») или обычные апострофы (‘строка’), то это так и останется строкой, которая будет присвоена переменной. Но если строку взять в обратные апострофы, те, что находятся над клавишей Tab, то строка (а точнее — команда в ней) будет выполнена, и вместо строки переменной присвоится результат выполнения этой команды. Мощно? — Хы! А то! Это — один из Джедайских мечей Линукса! Грозное оружие! Такого в хомячковой Венде нет. Даже пластмассового аналога.

Итак, во втором варианте сначала отрабатывает команда cat, которая в нормальном режиме выводит на экран всю информацию по процессору в компе. Попробуйте выполнить следующую команду в консоли:

$ cat /proc/cpuinfo

и вы узнаете много интересного о процессоре компа. Но в крипте мы заставили команду cat выдавать информацию не на экран, а канал («|»), или по другому — «орать в трубу».

С другой стороны «трубы» находится команда grep. Ее задача фильтровать поступающую информацию. Команда grep просматривает приходящие к ней строки, и если в строке содержится указанное слово (в нашем случае это «processor»), выводить эту строку на экран. Попробуйте:

$ cat /proc/cpuinfo | grep processor

Но в скрипте мы заставили команда grep тоже «кричать в трубу». (Только это уже будет другая труба.)

Вывод команды grep будет поступать на вход команде wc. Хочу заметить, что wc — это сокращение от «word counter» (счетчик слов), а не «water closet» (туалет).

Вообще, команда wc считает не только слова. Она считает во входящем потоке символы (буквы, цифры, знаки,…), слова и строки. Но в данном случае нас интересует только количество строк, поэтому мы ей указываем ключ -l (маленькая латинская буква «эль», l — от слова line, строка).

Если бы эта цепочка команд выполнялась в консоли

$ cat /proc/cpuinfo | grep processor | wc -l

то мы бы увидели на экране цифру — количество ядер проца. Но в нашем скрипе прописано присвоение этого значения переменной NPROCS, а не традиционный вывод на экран.

Собственно, после того как значение переменной определено, его можно будет использовать. Я не буду еще раз приводить здесь скрипты для Debian и для Ubuntu для компиляции и сборки тулчейна. Сейчас вы владеете знаниями и вам будет уже несложно самостоятельно подправить скрипты для ускорения работы. Я только подскажу, что дописать ключик -j ${NPROCS} нужно только в пяти местах.

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

Ну вот, тулчейн для создания ПО для MSP430 у нас создан, но успешно залить ПО в микроконтроллеры всё ещё не получится. Дело в том, что Линукс будет блокировать любые действия по работе программаторов под аккаунтом обычного пользователя. Безопасность системы превыше всего!

Наша задача, «рассказать» системе, что работа с программаторами не несёт ничего опасного и может выполняться из-под обычного пользователя.

Вообще, в Линуксе имеется целая система по работе с подключаемым оборудованием и драйверами. Называется она udev.

Мы должны указать системе, что пользователю, который входит в группу plugdev, работать с оборудованием, у которого идентификатор равным f432, а идентификатор производителя этого оборудования равен 0451, — можно. Осуществляется это с помощью создания файла с именем 46-TI.rules в директории /etc/udev/rules.d/.

Вот содержимое этого файла:

ATRRS{idVendor}=="0451",ATTRS{idProduct}=="f430",MODE="0660",GROUP="plugdev"
ATTRS{idVendor}=="0451",ATTRS{idProduct}=="f432",MODE="0660",GROUP="plugdev"

Здесь у меня аж две строки. Одна строка для MSP430-UIF  и для eZ430 — у этих программаторов одинаковые идентификаторы (f430). Другая строка для отладочной платы — Launchpad, у нее идентификатор f432.

Если у вас появится еще какое-то оборудование с другим идентификатором, то его тоже можно дописать в этот же файл.

Как узнать идентификаторы неизвестного устройства? — Очень просто! Подсоедините это устройство и посмотрите на последние несколько строк в файле /var/log/massages. Чтобы не ползать по файловой системе, существует специальная команда — dmesg, которая выводит на консоль содержимое этого файла.

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

$ dmesg | tail -20

Внимательно присмотревшись, вы увидите в сообщениях оба идентификатора подключаемого оборудования — идентификатор производителя и идентификатор самого оборудования.

Ну вот, пожалуй и всё! Если что, задавайте вопросы.

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