Программируем микроконтроллеры в QtCreator

Это копия моей статьи, опубликованной на хабре

qbs03
Почему-то в интернете мало документации про qbs, пора немного исправить эту ситуацию.

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

Но поверьте, это довольно быстро задалбывает. Под виндовс – MSVC, под ARM – CooCox или Keil (приношу свои соболезнования вынужденным работать под IAR), под MSP – CCS, под андроид – eclipse, под ios – Xcode, под пики – MPLAB. И ладно бы, со всем этим работать можно было бы, но ведь фиг: везде свои заморочки, тонкости и неписанные правила. Все это накладывается на общую тормознутость так популярного эклипса помноженную на криворукие дополнения от производителей.

Некоторое время назад я начал сводить все свои разработки под мобильные и десктопные приложения под одну платформу. После довольно долгого чеса по интернетикам мой выбор остановился на Qt. Есть все, что надо, при необходимости можно подцепить нативный код. В общем, задача закрылась.

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

Желающие могут пошариться по инету сами, но если кратко, то это заменитель всяких make и cmake, использующая нормальный (тут должен быть смаил) язык программирования. И сам QtCreator собирается с ее помощью, значит она уже вылезла из штанишек …

Да, документации по ней как обычно кот наплакал, но исходники еще никто не отменял, поэтому довольно быстро ко мне пришло понимание, что это практически то, что я искал. Посудите сами: сидишь в одной среде разработки (самой по себе очень приятной и быстрой) и спокойно пишешь и редактируешь файлы под несколько платформ. И тебе, как кодописателю, пофиг на наличие всяких там заморочек с “родными” средами.

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

Открываем QtCreator, выбираем создать Non-Qt Project (что бы пока не заморачиваться сильно) и далее выбираем то, где присутствует C и Qbs. Обратите внимание на приятные взгляду слова Platform independent

qbs01

В результате получаем один main.c и qbs. Можно уже нажать “build” и получить вывод Hello World.

Открываем qbs и ничего не понимаем. Поэтому все стираем, вооружаемся интернетом и начинаем писать. Яваскрипт и все такое.

import qbs

Так, тут вроде понятно. Импортируем всякое необходимое для работы самого qbs.

Project {
name: "simple"
}

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

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

Project {
name: "simple"
Product {
name: "desktop"
}
}

Теперь для нашего “десктопного” укажем исходник.

Project {
name: "simple"
Product {
name: "desktop"
files: "main.c"
}
}

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

Project {
name: "simple"
Product {
name: "desktop"
files: "main.c"
Depends {name: "cpp"}
type: "application"
}
}

И вот теперь при попытке собрать приложение QtCreator пошуршит немного диском и в панельке Application Output появится искомое

qbs02

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

Depends {name: "cpp"}

Читаю документацию и понимаю, что данной командой я устанавливаю зависимость проекта от какого-то модуля с именем cpp. Понятней стало? Мне нет.

Простым поиском нахожу что-то подобное в /usr/share/qtcreator/qbs/share/qbs/modules/ (Если у вас другая операционка, то скорее всего аналогичное лежит где-то неподалеку от QtCreator). Если говорить коротко, то там куча яваскрипта, которая в зависимости от платформы подбирает компилятор под эту платформу. Полностью повторять подобное мне смысла нет, поэтому оставляю как есть.

type: "application". Из документации: The file tags matching the product’s target artifacts. Артефакт … An Artifact represents a single file produced by a Rule or Transformer. … ерр .. Rule? Creates transformers for input tags. Напоминает ситуацию про сепулькарий .. Transformer? Creates files, typically from other files.

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

Но вернемся к нашему проекту. Давайте добавим еще один продукт, только уже для микроконтроллера

Project {
name: "simple"
Product {
name: "desktop"
files: "main.c"
Depends {name: "cpp"}
type: "application"
}
Product {
name: "micro"
files: "blink.c"
}
}

При попытке что-то сделать, нам сразу выскочит сообщение, что вообще-то файла blink.c нет. Ну, ок, добавим в проект фаил blink.c. Как видно из названия, это тот же HelloWorld, только для микроконтроллеров. Я взял из примеров для микроконтроллера семейства msp430.

#include <msp430.h>

int main(void)
{
WDTCTL = WDTPW + WDTHOLD;
P1DIR |= 0x01;

while (1) {
P1OUT ^= 0x01;
__delay_cycles(1000000); // 1 second @ 1MHz
}

return 0;
}

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

Теперь QtCreator не ругается, но и в микроконтроллер ничего не заливается. Странно, да?

Добавлять Depends {name: “cpp”} смысла нет, потому что установленный в системе родной gcc не в курсе про существование такой платформы, да и в дальнейшем пригодится, например для пиковских контроллеров, где вообще все свое.

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

Для начала, я предпочитаю в микроконтроллерных проектах расписывать каждый функционал в своем файле. Записывать каждый файл руками? Лень. Подсматриваем решение и переписываем блок

Product {
name: "micro"
Group {
name: "msp430 sources"
files: 'src/*.c'
fileTags: ['c']
}
}

Тут создаем группу файлов, которые обзываем “msp430 sources” и тупо включаем в нее все файлы, которые подходят под маску src/*.c. Для дальнейшей работы с ними тегируем их буквой С.

Что с ними делать? У qbs есть на этот случай две штуки – Rule и Transformer. По сути они близки, но немного разные. Счас попробую описать на пальцах разницу.

Rule умеет срабатывать на каждый файл, попадающий под что-то. Может срабатывать по разу на каждый фаил (например, для вызова компилятора), а может один раз на все (линкер).

Transformer предназначен для срабатывания только на один фаил, с заранее определенным именем. Например, прошивальщик или какой-нибудь хитрый скрипт.

Ок, добавляем правило, которое должно будет сработать на все наши файлы, промаркированные как “с”.

Product {
name: "micro"
Group {
name: "msp430 sources"
files: 'src/*.c'
fileTags: ['c']
}
Rule {
inputs: ["c"]
prepare: {
var cmd = new JavaScriptCommand();
cmd.description = "file passing"
cmd.silent = false;
cmd.highlight = "compiler";
cmd.sourceCode = function() {
print("Nothing to do");
};
return cmd;
}
}
}

В принципе из синтаксиса уже все понятно. Есть inputs, есть prepare, в который засовывается яваскрипт, который выполняет необходимое. В данном случае он должен в окошке Compile Output показать file passing, и куда-то вывести Nothing to do. Ну по документации вроде так.

Запускаем перекомпиляцию всего и смотрим. Не знаю, как у вас, но я ничего не вижу. Почему? Потому что qbs больно умный, а документация к нему страдает лакунами.

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

Ок, за это отвечают те самые артефакты. Под ними подразумеваются результаты деятельности Rule или Transformer. Лучше всего это объяснить на примере компиляции. Когда мы компилируем .с файл, то на выходе мы получим объектный файл .о. Он нам нужен для дальнейшей линковки, но с другой стороны, мы его можем удалить, так как потом спокойно сможем сгенерировать заново.

Опять копируем пример из документации и чуть-чуть модернизируем.

Rule {
inputs: ["c"]
Artifact {
fileTags: ['obj']
filePath: '.obj/' + qbs.getHash(input.baseDir) + '/' + input.fileName + '.o'
}
prepare: {
var cmd = new JavaScriptCommand();
cmd.description = "Compiling "+ input.fileName
cmd.silent = false;
cmd.highlight = "compiler";
cmd.sourceCode = function() {
print("Nothing to do");
};
return cmd;
}
}

Теперь мы говорим, что после нашей деятельности останутся артефакты в каталоге .obj (ну и я добавил вывод того, над каким файлом мы сейчас работаем). Запускаем. Опять ничего в ответ. Почему? Ответ тот же – никому не нужны файлы с тегом ‘obj’.

Хорошо, для проверки сделаем так, что они нужны нам. И вообще, наше приложение – это один сплошной obj.

Product {
name: "micro"
type: "obj"
Group {
name: "msp430 sources"
files: 'src/*.c'
fileTags: ['c']
}
Rule {
inputs: ["c"]
Artifact {
fileTags: ['obj']
filePath: '.obj/' + qbs.getHash(input.baseDir) + '/' + input.fileName + '.o'
}
prepare: {
var cmd = new JavaScriptCommand();
cmd.description = "Compiling "+ input.fileName
cmd.silent = false;
cmd.highlight = "compiler";
cmd.sourceCode = function() {
print("Nothing to do");
};
return cmd;
}
}
}

Пробуем, и удача! В окошке появился заветный “Compiling blink.c”. Теперь давайте добавим, что бы оно реально компилировало и сразу по-быдлокодерски, то есть тупо забив все необходимое в одну кучу.

prepare: {
var args = [];
args.push("-mmcu=cc430f5137")
args.push("-g")
args.push("-Os")
args.push("-Wall")
args.push("-Wunused")
args.push('-c');
args.push(input.filePath);
args.push('-o');
args.push(output.filePath);
var compilerPath = "/usr/bin/msp430-elf-gcc"
var cmd = new Command(compilerPath, args);
cmd.description = 'compiling ' + input.fileName;
cmd.highlight = 'compiler';
return cmd;
}

Перекомпилируем все с нуля и смотрим в каталог .obj

$ ls -R1
.:
f27fede2220bcd32

./f27fede2220bcd32:
blink.c.o

Ура! Файлик появился. Теперь, для проверки я делаю еще один файлик, с хитрым названием hz.с. Если я прав, то после перекомпиляции рядом появится еще один объектный файл.

В выводе появилось

compiling blink.c
compiling hz.c

а в каталоге

./f27fede2220bcd32:
blink.c.o
hz.c.o

Все вроде ок. Теперь необходимо все это дело слинковать. А значит опять правило, только теперь для линковки.

Rule {
multiplex: true
inputs: ['obj']
Artifact {
fileTags: ['elf']
filePath: project.name + '.elf'
}
prepare: {
var args = [];
args.push("-mmcu=cc430f5137")

for (i in inputs["obj"])
args.push(inputs["obj"][i].filePath);

args.push('-o');
args.push(output.filePath);
var compilerPath = "/usr/bin/msp430-elf-gcc"
var cmd = new Command(compilerPath, args);
cmd.description = 'linking ' + project.name;
cmd.highlight = 'linker';
return cmd;
}
}

Где отличия? Во-первых, добавился флаг multiplex, который говорит о том, что это правило обрабатывает сразу все файлы данного типа скопом. А во-вторых, во входных параметрах исчез input. Появился inputs, который является массивом файлов данного типа. Ну и я вопользовался именем продукта, что бы брать имя для финальной прошивки.

Ставим тип приложения elf и пробуем собрать. Через некотрое время мы в каталоге для сборки обнаружим файл simple.elf

$ file simple.elf
simple.elf: ELF 32-bit LSB executable, TI msp430, version 1, statically linked, not stripped

То, что нам и необходимо. Его можно уже заливать в плату и наслаждаться мигающим светодиодиком.

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

На всякий случай конечный qbs

import qbs
Project {
name: "simple"
Product {
name: "desktop"
files: "main.c"
Depends {name: "cpp"}
type: "application"
}
Product {
name: "micro"
type: "elf"
Group {
name: "msp430 sources"
files: 'src/*.c'
fileTags: ['c']
}
Rule {
inputs: ["c"]
Artifact {
fileTags: ['obj']
filePath: '.obj/' + qbs.getHash(input.baseDir) + '/' + input.fileName + '.o'
}
prepare: {
var args = [];
args.push("-mmcu=cc430f5137")
args.push("-g")
args.push("-Os")
args.push("-Wall")
args.push("-Wunused")
args.push('-c');
args.push(input.filePath);
args.push('-o');
args.push(output.filePath);
var compilerPath = "/usr/bin/msp430-elf-gcc"
var cmd = new Command(compilerPath, args);
cmd.description = 'compiling ' + input.fileName;
cmd.highlight = 'compiler';
return cmd;
}
}
Rule {
multiplex: true
inputs: ['obj']
Artifact {
fileTags: ['elf']
filePath: project.name + '.elf'
}
prepare: {
var args = [];
args.push("-mmcu=cc430f5137")

for (i in inputs["obj"])
args.push(inputs["obj"][i].filePath);

args.push('-o');
args.push(output.filePath);
var compilerPath = "/usr/bin/msp430-elf-gcc"
var cmd = new Command(compilerPath, args);
cmd.description = 'linking ' + project.name;
cmd.highlight = 'linker';
return cmd;
}
}
}
}

PS Вынос “захардкоденных” переменных в более удобное место оставлю на вашей совести, ибо это уже к обучалке по яваскрипту.

MSP430 и Fedora Linux

В принципе, в программировании микроконтроллеров под Linux нет ничего сложного. Более-менее доступны средства разработки, а некоторые производители и вовсе официально поддерживают Linux как среду разработки.

TI тоже имеет свою фирменную среду, но она … скажем так, для хардкорных железячников. Старый, тормознутый эклипс и какие-то невнятные настройки. Залитие прошивки и ее отладка тоже доставляют много удовольствия привыкшим к нормальным средам.

В общем, долой разврат – будем делать все по-правильному, что бы программирование доставляло удовльствие, а не требовало героического преодоления трудностей.

Расписывать я буду под Fedora Linux (21), потому что я сейчас под ней. Под другие дистрибутивы инструкций как-то больше.

В чем проблема с федорой? Ведь они кровь и плоть от редхата, а тот официально поддерживает msp430-gcc, который использует и сама TI. Проблема в том, что это федора, а значит в ней все нестабильное и вообще может не работать.

И с MSP430 случилось ЭТО. В 20й версии он работал, а в 21й – уже нет. Подробнее можно посмотреть тут. Если кратко, то в федоре сломали линкер.

Что делать? Есть несколько вариантов, из которых самый простой это взять старую версию компилятора из CCS или Energia. Но добрый Brandon Nielsen решил эту проблему по-другому: просто сделал репозиторий со правильными версиями.

Открываем рутовую консоль и подключаем нужный репозитарий

dnf copr enable nielsenb/msp430-development-tools

И ставим все необходимое, соглашаясь с тем, что никто ни за что не отвечает.

yum install msp430-elf-gcc msp430-elf-binutils msp430-elf-gdb mspds msp430flasher msp430-gcc-support-files dos2unix srecord

Теперь скопипастим Makefile
#
# Makefile for msp430
#
# 'make' builds everything
# 'make clean' deletes everything except source files and Makefile
# 'make install' builds everything, and programs the MSP430 using MSPFLASHER
# You need to set TARGET, MCU and SOURCES for your project.
# TARGET is the name of the executable file to be produced
# $(TARGET).elf $(TARGET).hex and $(TARGET).txt nad $(TARGET).map are all generated.
# The TXT file is used for BSL loading, the ELF can be used for JTAG use
#
TARGET = project0
MCU = msp430f5529
# MSP430Flasher name
MSPFLASHER = MSP430Flasher
# List all the source files here
# eg if you have a source file foo.c then list it here
SOURCES = main.c delay.c
# Include are located in the Include directory
INCLUDES = -IInclude
# Add or subtract whatever MSPGCC flags you want. There are plenty more
#######################################################################################
CFLAGS = -mmcu=$(MCU) -g -Os -Wall -Wunused $(INCLUDES)
ASFLAGS = -mmcu=$(MCU) -x assembler-with-cpp -Wa,-gstabs
LDFLAGS = -mmcu=$(MCU) -Wl,-Map=$(TARGET).map
########################################################################################
CC = msp430-elf-gcc
LD = msp430-elf-ld
AR = msp430-elf-ar
AS = msp430-elf-gcc
NM = msp430-elf-nm
OBJCOPY = msp430-elf-objcopy
RANLIB = msp430-elf-ranlib
STRIP = msp430-elf-strip
SIZE = msp430-elf-size
READELF = msp430-elf-readelf
MAKETXT = srec_cat
CP = cp -p
RM = rm -f
MV = mv
########################################################################################
# the file which will include dependencies
DEPEND = $(SOURCES:.c=.d)
# all the object files
OBJECTS = $(SOURCES:.c=.o)
all: $(TARGET).elf $(TARGET).hex $(TARGET).txt
$(TARGET).elf: $(OBJECTS)
echo "Linking $@"
$(CC) $(OBJECTS) $(LDFLAGS) $(LIBS) -o $@
echo
echo ">>>> Size of Firmware <<<<" $(SIZE) $(TARGET).elf echo %.hex: %.elf $(OBJCOPY) -O ihex $< $@ %.txt: %.hex $(MAKETXT) -O $@ -TITXT $< -I unix2dos $(TARGET).txt # The above line is required for the DOS based TI BSL tool to be able to read the txt file generated from linux/unix systems. %.o: %.c echo "Compiling $<" $(CC) -c $(CFLAGS) -o $@ $< # rule for making assembler source listing, to see the code %.lst: %.c $(CC) -c $(ASFLAGS) -Wa,-anlhd $< > $@
# include the dependencies unless we're going to clean, then forget about them.
ifneq ($(MAKECMDGOALS), clean)
-include $(DEPEND)
endif
# dependencies file
# includes also considered, since some of these are our own
# (otherwise use -MM instead of -M)
%.d: %.c
echo "Generating dependencies $@ from $<" $(CC) -M ${CFLAGS} $< >$@
.SILENT:
.PHONY: clean
clean:
-$(RM) $(OBJECTS)
-$(RM) $(TARGET).*
-$(RM) $(SOURCES:.c=.lst)
-$(RM) $(DEPEND)
install: $(TARGET).txt
$(MSPFLASHER) -n $(MCU) -w "$(TARGET).txt" -v -z [VCC]

Если при попытке компиляции Вы получите

Makefile:48: *** missing separator. Stop.

то это означает лишь то, что вы нарвались на tab-hell. Все отступы выше – это не пробелы, а символы табуляции. Если отвлечься и открыть этот фаил в mc, то вы должны увидеть следующее:

mc_tab

Обратите внимание на символы “<---->” – именно ими mc показывает табуляцию. Поправьте где надо.

Теперь осталось поправить параметры MCU под мой процессор и SOURCES под мой проект и запустить make. Если все сделано правильно, то вы должны увидеть побежавшие строки, завершающиеся чем-то похожим.

Linking blink.elf

>>>> Size of Firmware <<<< text data bss dec hex filename 2906 214 152 3272 cc8 blink.elf unix2dos: converting file blink.txt to DOS format...

Если оно так, то можете себя поздравить. Теперь можно развиваться дальше.

PS С автором, чьи наработки я использовал, можно познакомиться тут

Загадочный AES

В процессе обкатки модулей для супер-мега-экстра часов добрался до СС модулей от Texas Instruments. Документации куда больше, чем на nRF серию от Nordic, демоплатки тоже завелись без проблем.

Читаю документацию к SimplyciTI (это такой фирменный сетевой стек для этих чипов, сразу позволяет делать точки доступа, репитеры и прочее). Добираюсь до секурности – ведь никто не должен знать температуру за моим окном или включать-выключать свет в туалете (это одна из моих претензий к noolite)

There are 3 components of the encryption scheme that can be used to maintain security: the 128 bit key, a 32-bit Initialization Vector (IV) and a 32-bit counter. The key and the IV are fixed at build time.

Офигеть. Даже мне, далекому от криптографии, становится смешно. 32 бита “энтропии”, которые меняются по жесткому алгоритму … Ну ладно, что там еще

The scheme encrypts 64-bit blocks using an encryption scheme available in the public domain (XTEA: EXtended Tiny Encryption Algorithm). The 64-bit block is a concatenation of the 32-bit IV and a 32-bit counter. Changing the counter for each encryption guarantees a unique block for each encryption action. The key length used in the encryption is 128 bits.

Читаю дальше …

Because SimpliciTI does not support guaranteed delivery there must be a mechanism to synchronize the counters. Otherwise correct decryption could not occur. The synchronization is done by supplying a counter hint in the frame containing the encrypted payload. The hint is a single byte representing the least significant byte (lsb) of the 4 byte counter value used to encrypt the accompanying payload. It is sent in the clear over the air.

Вот так вот просто, берут и выдают последний байт счетчика в открытом виде в воздух. Круто, разом на треть уменьшают и без того маленький “ключ”

И как-то все. В задумчивости сижу, думаю, что не так.

Потом вспоминаю рекламные зазывалки.

The CC1110’s integrated AES-128 co-processor makes it ideal for wireless payment systems, since strong encryption can be done on the chip itself

Ну AES-128 это круто. Странно, что не написали в аппноуте, как до него добраться. Но счас почитаю оставшуюся документацию.

(пропущено несколько часов ползанья по докам и исходникам)

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

И тут открылось обычное. На более-менее приличных сайтах, которые не занимаются тупой перепечаткой, нет ни слова про AES. Вообще.

Вот такой вот AES. То он есть, то его сразу нет …

ЗЫ И именно поэтому я не люблю маркетологов, которые уцепившись за циферку 128, сразу прилепили к ней слева магические (в 2009 году) буквы AES.

Мега-часы. 2. Новые горизонты

Опытно-промышленное тестирование бутерброда из Arduino Leonardo и Arduino Wifi Shield показало, что wifi shield … В общем, очень плохо работает. Может тупо не запуститься или взять и повиснуть прямо на середине работы. А может завестись без каких-либо проблем и проработать сутки под нагрузкой.

В итоге wifi (да и вообще вся сетевая) часть переезжает на raspberry. Там с этим гораздо лучше просто по определению.

Следующее тестирование (в предидущих постах можно прочитать подробнее) показало, что первоначально выбранный контроллер nRF24 оказался тоже не очень хорошим. То ли китайцы чего-то не так распаяли, что ли у меня руки кривые, но дальность действия радиочасти оказалась ниже плинтуса. А я уже раскатал губу про выносные датчики и прочие штуки …

Но не одним nordic’ом полон мир. Тут же на замену был приобретен комплект разработчика на чипе MSP430+СС1100 от Texas Instruments производства нашей ТерраЭлектроники . Что бы дополнительно “замативировать” себя, взял еще СС430-Chronos. Настоящие умные часы, которые можно запрограммировать так, как тебе надо, а не просто менять циферблатики.

IMG_0269

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

Так как я с MSP430 не работал до этого момента, то из launchpad был вынут “крутой” проц и засунут простой.

IMG_0272

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