XMOS startKIT:создание XMOS и Raspberry Pi Robot XMP-1

Введение

XMOS startKIT от Фарнелла (или Ньюарка) - это очень дешевая (12 фунтов стерлингов, включая НДС) процессорная платформа, которая хорошо работает с Raspberry Pi. Вместе можно создавать приложения для робототехники, практически не требуя пайки.

XMOS startKIT - это плата размером почти с кредитную карту с микросхемой XMOS на ней с несколькими «ядрами XMOS», которые могут быть запрограммированы на C. Технология XMOS позволяет работать параллельно на высокой скорости с низким джиттером. Это как раз те характеристики, которые могут быть идеальными для приложений робототехники.

Вместе с некоторым кодом для запуска на плате XMOS startKIT и на Raspberry Pi (RPI) платы используются для создания простой компактной мобильной платформы (с этого момента я буду называть ее XMP, XMOS Mobile Platform вместо робота. в духе XMOS - все должно начинаться с символа "X").

Хотя XMP-1 не очень похож на робота, пока у него не появятся некоторые датчики и дополнительные средства программирования, в будущем он может быть расширен для экспериментов с робототехникой. В XMP-1 используется дешевое стандартное оборудование и нет экзотических инструментов, кроме отвертки, кусачков и плоскогубцев.

В этой публикации рассказывается о взаимодействии между RPI и платой XMOS с использованием интерфейса последовательного периферийного интерфейса (SPI) и о том, как создать XMP-1 и управлять им из веб-браузера.

Видео здесь показывает, как XMP-1 обучается маршруту; первая попытка его использования! Было бы лучше, если бы пользовательский интерфейс был лучше. XMP-1 может передвигаться довольно быстро, но я не торопился с низкой скоростью. Справа находится элемент управления браузера, а внизу - вывод консоли, в котором просто генерируются сообщения о сохранении активности и статусе, чтобы увидеть, что происходит.

В следующем видео ниже показано, как XMP-1 пытается воспроизвести маршрут и причиняет страдания и боль по пути. Мои недорогие сервоприводы с непрерывным вращением (которые используются для привода колес) были не очень хороши, а XMP-1 еще не имеет датчиков.

Немного подробнее

Этот пост на самом деле является второй частью некоторых экспериментов с XMOS startKIT. Часть 1 содержит введение, терминологию, архитектуру XMOS и краткое руководство с примерами программ. Если вас интересует технология, возможно, сначала будет полезно изучить часть 1, чтобы эта часть 2 имела больше смысла. Эта часть 2 предназначена для создания простой структуры для высокоскоростной связи между Raspberry Pi и платой XMOS startKIT. Фреймворк должен быть достаточно универсальным, чтобы его можно было использовать во многих проектах (я не собирался использовать робототехнику). XMP-1 на самом деле является лишь побочным продуктом в стремлении протестировать связь Raspberry Pi с платой XMOS. Это записано здесь на случай, если это будет полезно. (Обратите внимание, есть также часть 3 под названием XMOS startKIT:XMOS и Raspberry Pi Oscilloscope XAE 1000, которая повторно использует возможности SPI, обсуждаемые в этом посте, и знакомит с тем, как использовать аналого-цифровой преобразователь (АЦП), который присутствует в микросхеме XMOS. , и как работать с графикой в ​​реальном времени в веб-браузере).

Если вас интересует только создание и использование XMP-1, вы можете просто взять код внизу сообщения, скомпилировать и сохранить его во Flash (как описано в части 1) на плате XMOS startKIT и Raspberry Pi, и просто следуйте разделам, описывающим аппаратную сборку XMP-1, пропуская все остальное здесь. Если вы заинтересованы в управлении любым оборудованием с помощью Raspberry Pi и веб-браузера, то часть кода здесь можно использовать повторно. Но чтобы получить максимальную отдачу от комбинации Raspberry Pi и XMOS startKIT, оставшаяся информация может быть полезна, если вы новичок в startKIT.

Обзор решения - оборудование и программное обеспечение

Вот фотография заряженного готового XMP-1. Для использования вне помещений я использовал устройство типа точки доступа 802.11 (MiFi), запустив браузер на мобильном телефоне.

На диаграмме ниже показано примерное расположение частей и деталей, если смотреть с задней стороны XMP-1. Как видите, это довольно просто - XMP-1 был всего лишь небольшим экспериментом.

Raspberry Pi (RPI) используется для обработки всей сетевой активности. Он запускает небольшой веб-сервер, и большая часть кода написана на JavaScript на платформе Node.js. RPI передает управляющую скорость двигателя (на самом деле сервоприводы непрерывного вращения использовались для XMP-1) через последовательный интерфейс (SPI) на плату XMOS startKIT. XMOS startKIT отвечает за подачу сигналов широтно-импульсной модуляции (ШИМ) на двигатели.

RPI подключается к сети с помощью USB-адаптера 802.11 WiFi.

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

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

Вкратце, зеленый блок обрабатывает веб-взаимодействие и определяет скорость и направление двигателей на основе пользовательского ввода. Зеленый блок предоставляет пользователю веб-страницу (index.html), которая включает пользовательский интерфейс. Программа xmos_servo - это небольшая часть программного обеспечения, написанного на C, которое преобразует желаемую скорость / направление в байты данных последовательного периферийного интерфейса, которые отправляются в startKIT. Программное обеспечение startKIT разделено на три части, которые работают одновременно на отдельных ядрах XMOS. Spi_process преобразует сигналы SPI в данные, которые хранятся в массиве. Код data_handler проверяет массив, чтобы решить, что делать (единственный вывод, который он делает сегодня, - это манипулировать сервоприводами). Процесс servo_handler выводит поток импульсов на сервоприводы, чтобы они могли вращаться с желаемой скоростью. Все эти блоки более подробно описаны ниже.

Последовательный периферийный интерфейс (SPI)

SPI полагается на четыре провода, известные как SS, SCLK, MISO и MOSI, и назначение ведущего и ведомого устройств для двух устройств, участвующих в обмене данными. В случае платы RPI и XMOS, RPI является главным устройством и отвечает за генерацию тактового сигнала. RPI передает данные по проводу MOSI, а полученные данные - по проводу MISO. Это означает, что интерфейс SPI может одновременно передавать данные двунаправленным образом. На практике, если требуются односторонние данные, то сигнал MOSI или MISO можно игнорировать в зависимости от направления интереса.

На снимке экрана осциллографа (отдельные сигналы и автоматическое декодирование SPI с осциллографа Tektronix MSO2024B) показан пример связи SPI с использованием Raspberry Pi. SPI можно настроить несколькими способами; вы можете видеть в этом примере, что три байта данных были переданы от ведущего устройства (RPI) к ведомому устройству (плата XMOS), и что они были 0x02, 0x00 и 0x10, и либо нет данных, либо 0x00, 0x00, 0x00 были переданы из раб к мастеру одновременно.

Провод SS - это сигнал выбора микросхемы (активный низкий уровень). RPI имеет два контакта на 26-контактном разъеме, которые можно использовать для SS; на схеме ниже они обведены синим кружком и помечены как CE0 и CE1. Это означает, что при желании RPI может взаимодействовать с двумя ведомыми устройствами SPI. В этом случае использовался только один из выводов CE - я выбрал CE1.

Управление сервомоторами для хобби

Серводвигатели Hobby генерируют движение на основе входного сигнала. Обычно они совершают менее одного полного оборота. Обычно сервопривод для хобби вращается в диапазоне около 180 градусов. Выходной вал может быть соединен (скажем) с рычагами, чтобы колеса поворачивались полностью влево или вправо (или что-то среднее между ними) в зависимости от входного сигнала.

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

Сервомашинки для хобби обычно имеют три соединения; 0В, 5В и сигнал. Сигнальный провод - это цифровой вход сервопривода, для которого требуется сигнал ШИМ. Размер ширины импульса определяет угол, на который будет перемещаться вал. Сигнал ШИМ должен повторяться каждые 20 мсек, а длительность импульса 1,5 мсек приведет к перемещению вала в центральное положение. При ширине 1 мс сервопривод полностью перемещается в одном направлении, а при ширине 2 мс сервопривод полностью перемещается в другом направлении (ниже будут видны следы сервоуправления осциллографом).

Существует вид модифицированного сервопривода, известный как сервопривод «непрерывного вращения». Это модифицированный сервопривод, в котором потенциометр удален вместе с любыми концевыми ограничителями, и схема убеждается, что сервопривод все еще находится в центральном положении. Отправка ШИМ с длительностью импульса, отличной от 1,5 мсек, заставит механизм вращаться по часовой стрелке или против часовой стрелки со скоростью, которая зависит от ширины импульса. В XMP-1 используются два любительских сервопривода с непрерывным вращением, по одному на каждое колесо. Они не являются оптимальным способом получения контролируемого движения (XMP-2 будет использовать щеточные двигатели постоянного тока), поскольку они используются для целей, отличных от первоначальной цели для сервоприводов для хобби, но у них есть то преимущество, что ими можно управлять с помощью цифрового логический сигнал, и они не требуют какой-либо внешней схемы H-моста.

Провода сервоприводов Hobby могут иметь различную цветовую маркировку в зависимости от производителя. Обычно центральный провод красный, и он идет на + 5В. Черный или коричневый провод - 0В. Белый или желтый провод - это вход сигнала ШИМ.

Начало разработки - Подключение плат

Для разработки программного обеспечения RPI и startKIT были соединены с помощью ленточного кабеля и разъема IDC - их можно собрать с помощью тисков или купить готовыми. Для версии с самостоятельной сборкой стоит купить дополнительный разъем IDC для использования в качестве разъема отладки в центре кабеля, чтобы облегчить жизнь при измерении сигналов с помощью мультиметра или осциллографа.

Реализация SPI (spi_process) на XMOS startKIT

Использование среды разработки XMOS (xTIMEcomposer) было рассмотрено в части 1. На снимках экрана ниже показана версия xTIMEcomposer для Windows, но версия для Linux выглядит идентично (и, возможно, версия для Mac тоже может выглядеть так же).

На этом этапе вы можете щелкнуть правой кнопкой мыши библиотеку функций ведомого устройства SPI в лаборатории xSOFTip и импортировать библиотеку в рабочую область. Я не являюсь экспертом по xTIMEcomposer, поэтому я, вероятно, неправильно использую его здесь, но исходный код и файл заголовка для библиотеки появились в отдельной папке в Project Explorer (показаны синим кружком ниже):

Файлы должны были находиться в папке spi-test (чтобы они выглядели так, как показано выше в зеленом кружке), поэтому для этого я вручную скопировал файлы spi_slave.h и spi_slave.xc из папки module_spi_slave / src в spi-test. / src с помощью проводника Windows.

Программное обеспечение использует концепцию портов для управления выводом или считывания ввода. Между этими логическими портами и физическим отображением контакта на микросхеме есть соответствие. Сопоставления можно изменять в определенных комбинациях (см. Рисунок 3 в документе PDF «Введение в порты XS1»).

Порты ввода / вывода на устройствах XMOS могут иметь ширину 1, 4, 8, 16 или 32 бита. При проектировании с использованием детали вы можете назначить определенные функции для 1-битных портов или другие функции для многобитовых портов, поэтому рисунок 3 будет очень полезен для определения, какие порты и контакты использовать.

Теперь, когда подчиненный код SPI находится в фильтре spi-test / src, этот код был немного изменен. Код библиотеки предполагает, что все порты, которые используются для интерфейса SPI, являются 1-битными портами, тогда как контакт Raspberry Pi SPI SS (CE1) подключен к 32-битному порту на плате XMOS. Рисунок 8 из PDF-документа startKIT Hardware Manual показан ниже. В центре зеленым цветом вы можете увидеть 2 × 13-контактный заголовок, который соединяет плату XMOS и Raspberry Pi. Слева и справа синим цветом показаны физические имена контактов на микросхеме (X0D0, X0D11 и т. Д.). Выделенные значения контактов - это номера логических портов. P1A, P1D и так далее - однобитовые порты. P32A1 - первая двоичная цифра 32-битного порта

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

Интерфейс SPI на устройстве XMOS инициализируется, как показано здесь. Это объясняется более подробно ниже.

+ развернуть исходный код

1. void spi_slave_init (spi_slave_interface &spi_if)
2. {
5. int clk_start;
6. set_clock_on (spi_if.blk);
7. configure_clock_src (spi_if.blk, spi_if.sclk);
8. configure_in_port (spi_if.mosi, spi_if.blk);
9. configure_out_port (spi_if.miso, spi_if.blk, 0);
10. start_clock (spi_if.blk);
17. return;
18. }

Как упоминалось в сообщении части 1, ввод-вывод можно синхронизировать с устройством XMOS и с него в точное время. В приведенном выше коде функция set_clock_on (определенная в файле заголовка XMOS xs1.h) используется для включения одного из встроенных механизмов синхронизации в микросхеме XMOS. На диаграмме ниже (из документа «Введение в порты XS1») этот механизм показан желтым цветом. Функция configure_clock_src используется для выбора внешних часов (показаны синим цветом на схеме). Он будет подключен к контакту SCLK на Raspberry Pi. Функции configure_in_port и configure_out_port используются для привязки портов к механизму синхронизации. Сигналы MOSI и MISO (показаны зеленым цветом ниже) настроены для привязки к механизму синхронизации.

Способ обработки последовательных данных на устройствах XMOS действительно изящный. Код здесь поясняется ниже. Во-первых, используется структура, содержащая сведения о портах, которые желательно использовать в качестве интерфейса SPI.

+ развернуть исходный код

1. typedef struct spi_slave_interface
2. {
3. часы blk;
4. в порт ss;
5. в буферизованном порту:8 моси;
6. выходной порт с буферизацией:8 мисо;
7. в порту sclk;
8. } spi_slave_interface;

Интересные строки выше относятся к переменным порта mosi и miso. Они были объявлены как порт типа:8. Если переменным назначены 1-битные адреса портов, то устройство XMOS автоматически десериализует поток битов 1-Wire в 8-битные значения.

Это действительно упрощает остальную часть кода SPI. Вот код, который управляет вводом данных SPI с Raspberry Pi:

+ развернуть исходный код

1. void spi_slave_in_buffer (spi_slave_interface &spi_if, unsigned char buffer [], int num_bytes)
2. {
3. данные типа unsigned int;
4. unsigned int vlen =0;
7. clearbuf (spi_if.miso);
8. clearbuf (spi_if.mosi);
11. для (int i =0; i
12. {
13. spi_if.mosi:> data;
14. data =data <<24;
15. буфер [i] =bitrev (данные);
16. если (i ==2)
17. {
18. vlen =(((unsigned int) buffer [1]) <<8) | (целое число без знака) буфер [2];
19. если (vlen ==0)
20. перерыв;
21. }
22. if (i> =vlen + 2)
23. {
24. перерыв;
25. }
26. }
27. }

В приведенном выше коде вы можете видеть, что есть цикл for, а внутри цикла строка spi_if.mosi:> data; используется для считывания 8 бит информации из строки MOSI в переменную с именем data.

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

Следующие несколько строк нуждаются в пояснении; они связаны с желаемым протоколом. Он был предназначен для создания кода общего назначения, который можно было бы использовать для многих вещей, а не только для XMP-1. Если Raspberry Pi отправляет данные на плату XMOS startKIT, плата XMOS должна знать, сколько байтов данных следует ожидать. Это можно было бы жестко запрограммировать, но было бы негибко.

Было решено использовать очень простой протокол «тег (или тип), длина, значение» (TLV). Первый байт, который должен передать Raspberry Pi, - это тег или идентификатор в диапазоне 0–255 (т. Е. Один байт). Пользователь сам решает, что представляют собой значения. Например, значение 1 может означать «установить скорость двигателя», а значение 2 может означать «установить яркость фар». Вторые два байта - это 16-битное значение, указывающее, сколько байтов значения (т. Е. Данных) должно следовать. Я решил ограничить это значение до 4 Кбайт (4096 байт), что должно соответствовать многим вариантам использования, но фактическое значение можно изменить, изменив определение BUFLEN в коде.

Следовательно, минимальное количество байтов, отправляемых через интерфейс SPI, составляет три (тег и длина 0x0000), а максимальное - 4099, что является тегом, и длиной 0x1000 (это 4096 в шестнадцатеричном формате) и 4096 байтов данных.

Протокол был немного доработан, так что нечетный номер тега означает, что Raspberry Pi ожидает ответа в следующем сообщении SPI, которое он инициирует после завершения текущего потока TLV, а четный номер тега означает, что Raspberry Pi не ожидает ответа. назад.

Это очень простой протокол, но он должен отвечать многим обычным требованиям. Это также объясняется в таблице ниже, где синее число - это байтовый индекс SPI в принимающем 4099-байтовом буфере.

Возвращаясь к предыдущему фрагменту кода, можно увидеть, что следующие несколько строк проверяют содержимое буфера [1] и буфера [2] на лету во время получения данных SPI. Ожидается, что содержимое будет иметь длину, указанную на диаграмме выше (см. Синий индекс буфера). Как только код определит длину остатка, он примет ровно это количество байтов данных, а затем процедура завершится.

Это касается ввода SPI на плату XMOS на линии MOSI. Вывод SPI с устройства XMOS на линии MISO работает аналогичным образом, проверяя длину одновременно на линии MOSI снова на лету, так что функция может выйти, как только будет передано запрошенное количество байтов.

Межпроцессное взаимодействие

Теперь, когда SPI был определен и протокол был реализован для обмена данными переменной длины в любом направлении до 4096 байт, некоторое внимание было уделено основной части программы. Было ясно, что ядро ​​XMOS будет предназначено для обработки задачи SPI, но остальной код, возможно, потребуется разместить в одном или нескольких дополнительных счетах XMO.

В части 1 было описано, как задачи выполняются параллельно на разных ядрах XMOS и как задачи могут взаимодействовать друг с другом, передавая значения в каналы. Существует еще один способ связи между ядрами, в котором используется концепция «транзакций через интерфейсы», а не каналов. Он более гибкий, потому что вы можете отправлять несколько переменных разных типов из одного ядра XMOS в другое. Типы транзакций определены во многом как прототип функции C. Все это становится намного понятнее, если посмотреть на пример.

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

+ развернуть исходный код

1. интерфейс program_display
2. {
3. недействительная подсветка (состояние int, цвет int); // тип транзакции 1
4. пустой график (int x, int y, int color); // тип транзакции 2
5. };

Обмен данными по интерфейсу является однонаправленным, поэтому, если дисплей хочет отправлять информацию, такую ​​как (например) состояние сенсорного экрана, тогда необходимо использовать другой интерфейс в другом направлении. Из этого ясно, что у интерфейсов есть клиентская и серверная стороны. На схеме показаны два ядра XMOS (фиолетовым цветом), два интерфейса (серым цветом), а первый интерфейс (называемый program_display) позволяет выполнять два разных типа транзакций (синим цветом) через интерфейс program_display.

Самое замечательное в использовании интерфейсов и типов транзакций заключается в том, что, как и в прототипах функций C, вы можете иметь возвращаемые значения и передавать ссылки на переменные, так что даже если связь всегда инициируется клиентской стороной интерфейса, передача данных может происходить в обоих направлениях. Еще одна очень интересная функция, не показанная на схеме, - это возможность серверной части отправлять «уведомление» клиентской стороне. Это может быть сигналом для клиента выполнить транзакцию обычным способом, возможно, для получения некоторых данных. Эта функция будет использоваться в коде XMP-1. Таким образом, более подробная информация о том, как именно кодировать интерфейсы и отправлять данные и уведомления, будет объяснена ниже.

Разработка архитектуры IPC для обработки содержимого SPI

Обработка интерфейса SPI уже описывалась. Теперь содержимое сообщений SPI необходимо представить задаче в удобной форме для последующей обработки. Вооружившись знаниями об интерфейсах и транзакциях, можно было приступить к распределению функций по отдельным ядрам XMOS и проектированию межпроцессного взаимодействия, чтобы перейти к универсальной структуре, которая позволила бы отправлять полезное содержимое сообщения из RPI в XMOS. доска и наоборот, и будет обрабатываться.

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

Когда Raspberry Pi желает отправить сообщение на плату XMOS, RPI построит сообщение в формате TLV, описанном ранее. Затем информация синхронизируется по сигнальному проводу MOSI (показан зеленым в верхней части диаграммы выше). Одновременно устройству XMOS необходимо отправить что-то обратно, но, поскольку информации для отправки еще нет, строка MISO может содержать мусор или все нулевые значения, как показано розовым цветом. Функция spi_process соберет сообщение в буфер (массив символов без знака), а затем инициирует транзакцию в отдельном ядре XMOS data_handler. Data_handler отвечает за обработку содержимого сообщения и, при необходимости, отправку информации обратно в ядро ​​XMOS spi_process, так что любой последующий обмен SPI может отправлять полезные данные обратно в Raspberry Pi вместо значений мусора.

Данные могут быть отправлены между spi_process и data_handler путем создания копии буфера. Однако вместо этого можно просто передать указатель на буферную память. Один из способов сделать это - «переместить» управление указателем и ячейками буферной памяти из spi_process в data_handler. После того, как data_handler завершит проверку сообщения, он может вернуть управление spi_process, используя возвращаемую переменную, которую можно использовать в транзакциях. Вот почему на приведенной выше диаграмме есть транзакция с именем array_data с параметром, определенным как перемещаемый указатель, и возвращаемое значение, определенное также как перемещаемый указатель. Таким образом, только одно ядро ​​XMOS имеет доступ к буферной памяти одновременно.

Вот используемые интерфейсы:

+ развернуть исходный код

1. интерфейс to_rpi
2. {
3. недействительный код (символ без знака c);
4. };
7. интерфейс from_rpi
8. {
9. unsigned char * movable array_data (unsigned char * movable bufp);
10. };

Код spi_handler выделяет пространство для буфера, а затем передает управление буфером коду data_handler, используя строку buf =c.array_data (move (buf)), показанную в этом коде:

+ развернуть исходный код

1. недействительно
2. spi_process (интерфейс to_rpi server s, interface from_rpi client c)
3. {
4. хранение беззнаковых символов [4099];
5. unsigned char * movable buf =storage;
6. …
7. buf =c.array_data (move (buf));
8. …
9. выберите
10. {
11. case s.code (unsigned char c):
12. if (c ==SEND)
13. {
14. spi_slave_out_buffer (spi_sif, buf, 4099);
15. }
16. перерыв;
17. }
18. }

Код data_handler получает управление буфером, а затем, если требуется отправить какой-либо ответ в RPI при последующей транзакции SPI, буфер заполняется ответом. Наконец, управление буфером возвращается процессу spi_handler.

+ развернуть исходный код

1. недействительно
2. обработчик_данных (интерфейс to_rpi client c, интерфейс from_rpi server s)
3. {
4. выбрать
5. {
6. case s.array_data (unsigned char * movable vp) -> unsigned char * movable vq:
7. // vq содержит данные из SPI. Здесь мы можем делать с ним все, что захотим.
8. // Здесь тоже строится любой ответ:
9. vq [0] =0x22; // тег
10. vq [1] =0x00; // длина
11. vq [2] =0x00; // длина
12. vq =движение (vp); // передаем элемент управления указателем обратно в spi_process
13. tosend =1;
14. перерыв;
15. }
16. если (отправить)
17. {
18.     c.code(SEND);  // send a code to spi_process so that it is aware there is data to send to RPI
19.   }
20. }

Earlier it was mentioned that if an odd tag value was sent by the RPI then this would be an indication that the RPI expected a response message from the XMOS startKIT board on the subsequent SPI exchange. This is implemented by both the spi_process and data_handler making a note that a return message is expected if the first byte received is an odd value. Once data_handler has finished constructing the return message in the buffer memory it moves the buffer pointer back to the spi_process XMOS core and also sends a code transaction which could contain a message such as “ready to send”. The spi_process XMOS core is now ready for any subsequent SPI exchange. If the data_process doesn’t want to send any message back to the Raspberry Pi (for example if the tag was even valued) then the code transaction is not sent (or a different code could be sent such as “not ready to send”).

In the graphic diagram earlier you can see that the subsequent SPI exchange did transmit data back to the Raspberry Pi on the MISO wire.

To summarize, the spi_process and data_process present a fairly general-purpose capability to exchange data bidirectionally between the RPI and XMOS board.

Implementing PWM (servo_handler) on the startKIT

To test out the general purpose architecture, it was decided to use it to control many devices. The devices ended up being hobby servos because they require very little electrical interfacing effort – no H-bridge or transistor driver is needed – and the servo input wire can be directly connected to an XMOS output pin. I didn’t have many servos, so although the code implements 8 servo control, only two were used for XMP-1.

The code could be modified to provide DC motor control too (with a suitable external H-bridge circuit).

It was decided to use a single XMOS core to handle the eight servos. The diagram below shows the total of three XMOS processes used in the solution. The new addition is the servo_handler task which is shown on the right. This task has an array that stores the current servo values. As soon as the task starts up, the values are initialized to a centered value (or standstill for a continuous rotation servo) and then every microsecond the task wakes up to check if the servo PWM signal needs adjustment.  If it does then the servo port output is toggled. After 20msec the process repeats.

For more detail:XMOS startKIT Building an XMOS and Raspberry Pi Robot XMP-1