Интегрированная среда разработки CodeMaster-Lynx (CM-LYNX) предназначена для отладки и работы с процессорами серии 1967ВНхх. CM-LYNX базируется на функциональности, предоставляемой Eclipse CDT, с собственным программным комплексом для компиляции и генерации исполняемого машинного кода (tool chain). CM-LYNX также имеет набор программных библиотек для процессоров 1967ВНхх. На данный момент среда находится стадии постоянной доработки. Информацию о доступной актуальной версии можно получить на сайте, например, ссылка

Эта статья будет посвящена тому, как начать работать с процессорами ЦОС Миландр в среде CM-LYNX. Мы научимся создавать проект в данной среде, выполним его настройку, и запустим обычный "HelloWorld", то есть помигаем светодиодами.

Среда CM-LYNX поставляется на диске в составе комплекса разработки и отладки для процессоров серии 1967ВНхх. В состав этого комплекса также входят программатор JEM LYNX и электронный ключ SafeNet, поэтому помимо установки самой среды, необходимо выполнить установку драйверов, находящихся на диске.

В нашем проекте мы будем использовать отладочный комплект для процессора цифровой обработки сигналов 1967ВН028. Однако для процессора 1967ВН044(034) создание и настройка проекта будут такими же. Отдельно пример HelloWorld для 1967ВН044(034) приведён в статье подключаем библиотеки HAL в среде CM-LYNX. Ну а теперь продолжим.

Вставляем ключ, подключаем программатор - поехали!

P.S. Разъём программатора подключается к отладочной плате красным проводом строго к «1», как показано на рисунке ниже

При запуске среды нам предлагается выбрать путь для рабочего пространства. По умолчанию конечная папка пути так и называется "workspace", но мы добавим в ней еще одну папку с названием "leds".

Нажимаем OK и попадаем в среду CM-LYNX. Начинаем, как всегда, по традиции: вкладка File→New→C Project.

Далее присваиваем имя проекта. Оставляем "Use default location", таким образом, наш проект сохранится в ранее созданном "workspace". Project type: Milandr Executable Project. Milandr DSP1967 LLVM Cross C/C++. Переходим Next.

При использовании toolchain "Milandr DSP1967 Cross C/C++" дальнейшие настройки будут аналогичными LLVM.

В окне Select Configurations оставляем выбранными поля Debug и Release. По умолчанию проект настроен для работы с процессором 1967ВН044. Чтобы изменить проект для работы с другим процессором выбираем пункт "Advanced settings…". В открывшемся окне в пункте "Processor" выбираем процессор 1967ВН028.

Далее в окне создания проекта нажимаем кнопку "Finish".

На предложение "связать с перспективой C/C++" соглашаемся.

Теперь наш проект доступен в поле Project Explorer. Следующим шагом добавим Source-файл, где мы будем писать код. Нажимаем правой клавишей мыши на проект New→ Source File.

В поле Source file указываем имя. Пускай оно будет main.c (*необходимо обязательно указать расширение файла). В поле Source folder указана папка нашего проекта, а в Template оставляем Default C source template.

Итак, мы создали пустой проект, а также провели первое знакомство с интегрированной средой разработки CM-LYNX для процессоров цифровой обработки сигналов Миландр. Теперь пора перейти к "Hello World".

//Содержимое файла main.c

#include <sysreg.h>

// Прототип функции задержки, реализованной ниже
void Delay(int waitTicks);

int main(void)
{

   // Основной цикл
   while(1)
   {
     __builtin_sysreg_write(__FLAGREGST, 0x01); // зажигаем светодиод FLAG0
     Delay (5000000);
     __builtin_sysreg_write(__FLAGREGCL, 0x00); // гасим светодиод FLAG0
     
     __builtin_sysreg_write(__FLAGREGST, 0x02); // зажигаем светодиод FLAG1
     Delay (5000000);
     __builtin_sysreg_write(__FLAGREGCL, 0x00); 
     
     __builtin_sysreg_write(__FLAGREGST, 0x04); // зажигаем светодиод FLAG2
     Delay (5000000);
     __builtin_sysreg_write(__FLAGREGCL, 0x00); 
     
     __builtin_sysreg_write(__FLAGREGST, 0x08); // зажигаем светодиод FLAG3
     Delay (5000000);
     __builtin_sysreg_write(__FLAGREGCL, 0x00);
   }
}

//Функция задержки
void Delay(int waitTicks)
{
  int i;
  for (i = 0; i < waitTicks; i++);
}

#include <sysreg.h>

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

//  Прототип функции задержки, реализованной ниже
void Delay(int waitTicks);

//  Функция задержки
void Delay(int waitTicks)
{
  int i;
  for (i = 0; i < waitTicks; i++)	
}

Delay() - простейшая реализация функции задержки на цикле. Значение задержки здесь необходимо подобрать экспериментально.

Чтобы мигнуть светодиодом, в основном цикле используется такой код:

__builtin_sysreg_write(__FLAGREGST, 0x01); // зажигаем светодиод FLAG0
Delay (5000000);
__builtin_sysreg_write(__FLAGREGCL, 0x00); // гасим светодиод FLAG0

В CM-LYNX доступ к системным регистрам осуществляется с помощью специальных функций

__builtin_sysreg_read(int reg); // чтение значений из регистра reg
__builtin_sysreg_write(int reg, unsigned int value); // запись значения value в регистр reg

Здесь значение int reg берётся из библиотеки sysreg.h. Unsigned int value, как понятно из названия, - беззнаковое целое число, записываемое в выбранный регистр.

Регистр FLAGREG – 32-битный регистр, который контролирует направление выводов FLAG0-FLAG3 (вход (0) или выход (1)) и обеспечивает значение (1 или 0), когда выводы сконфигурированы как выход. Направление выводов FLAG0-FLAG3 задаётся в первых 4 битах регистра (3:0), за значение флагов при выдаче отвечают биты 7:4. Таким образом, чтобы настроить FLAG0 на выход, при этом чтобы он выдавал логическую 1, в регистр FLAGREG необходимо прописать значение 0x11 (8'b0001_0001). Однако непосредственно в регистр FLAGREG записывать значения нельзя! Для этого существуют два отдельных регистра FLAGREGST и FLAGREGCL. FLAGREGST позволяет записывать 1 (установка бит) в регистр FLAGREG. FLAGREGCL позволяет записывать 0 (сброс бит) в регистр FLAGREG.

Обратите внимание, чтобы зажечь светодиод нам необходимо установить вывод FLAG0 на выход (FLAGREG[3:0] = 4'b0001) и при этом вывести на вывод значение логического 0 (FLAGREG[7:4] = 4'b0000)!

__builtin_sysreg_write(__FLAGREGST, 0x01); // зажигаем светодиод FLAG0

Итак, подав логический 0 на вывод FLAG0, мы всё же зажжём светодиод, но как это происходит? Всё дело в схемотехнике отладочной платы и вывода порта GPIO. На отладочной плате соединение светодиода, процессора и кнопки выглядит следующим образом

Светодиод подключен к питанию 2.5 В. Чтобы его зажечь, необходимо замкнуть цепь, нажав на кнопку и соединив светодиод с землёй. Тоже самое происходит, когда мы, настраивая FLAG0 на выход, подаём логический 0, т.е. соединяем выход вывода с землёй. Схематично такое подключение представлено на рисунке ниже.

Чтобы погасить светодиод, просто переключим вывод FLAG0 на вход.

__builtin_sysreg_write(__FLAGREGCL, 0x00); // гасим светодиод FLAG0

Чтобы посмотреть, как исполняется разобранная нами программа, запустим проект в режиме жука отладки (debug). Но для начала нам необходимо выполнить компиляцию проекта. Поскольку нас интересует режим отладки (он же debug) нужно убедиться, что выбран именно он. Для этого переходим по вкладке Project→Build Configurations→Set Active→Debug. Также это можно проверить, нажав на стрелку у значка часов (выделен красным) или нажав на сам значок и проверить, что режим Debug активен (выбран Active). Значок молотка (выделен зеленым) выполняет компиляцию. Нажав на стрелку рядом, можно выбрать, что мы будем компилировать. Значок документа (выделен синим) скомпилирует все конфигурации (Сtrl+B).

Итак, воспользовавшись молотком, собираем наш проект. После компиляции в окне Project Explorer видим, что в проект добавилась папка Debug с выходными файлами.

Теперь приступим к созданию конфигурации режима отладки. Для этого нажимаем на стрелку у значка жука и переходим в Debug configurations.

В открывшемся окне слева выбираем тип "Milandr DSP 1967 LLDB" и выбираем иконку "New".

Создастся конфигурация Project1 Debug. Это имя нас устраивает, оставляем его. В поле "DSP cores" указываем количество процессоров, объединённых в JTAG цепочку. На отладочной плате у нас 2 процессора 1967ВН028, поэтому выбираем "DSP cores = 2".

Теперь мы можем выбрать с каким именно процессором на отладочной плате мы хотим работать: с первым, со вторым, или с двумя сразу. Здесь мы рассмотрим отладку только одного процессора, описание многопроцессорной отладки описано в статье Запускаем отладку многопроцессорной системы. Чтобы выбрать необходимый нам процессор, оставляем напротив него в столбце "Core" галочку, все остальные галочки убираем.

Переходим во вкладку "Debugger". Здесь в поле "Debugger" мы можем выбрать как будет осуществляться отладка: с помощью отладчика на процессоре, либо с помощью симулятора. Так как мы работаем с отладочной платой, выбираем "JEM", а остальные параметры оставляем по умолчанию.

Переходим во вкладку "Control". Здесь можно настроить действия, выполняемые при запуске и завершении режима отладки. Оставим все параметры по умолчанию.

На этом настройка конфигурации и запуска отладки завершена. Подключаем к плате отладчик, подаём питание на плату и нажимаем кнопку "Debug".

Среда предложит нам открыть перспективу Debug режима. Соглашаемся. Здесь мы можем поставить breakpoints, открыть Dissassemblery, посмотреть значение регистров.

Теперь нам остается только запустить исполнение программы с помощью кнопки "play" (выделена синим).

Приостановить выполнение программы можно с помощью кнопки "suspend" (выделена фиолетовым).

Завершение процесса отладки осуществляется нажатием на кнопку stop (выделена зелёным).

1. Может возникнуть ситуация, когда проект не собирается из-за того, что ничего в проекте не поменялось.

Если Вы считаете что это не так, кликаем правой кнопкой мыши на название проекта и выбираем пункт Clean Project, после чего пробуем собрать проект снова.

2. В случае возникновения ошибки: "Error stoping at main" процессор не готов принимать инструкции по JTAG. помогает отключить, а затем включить питание на плате.

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

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