Первое знакомство с микроконтроллерами Atmel, STM и другими.

Первый рассказ
Предэксплуатационный ремонт отладчика Atmel AVR Dragon
Цветное изображение на монохромном LCD
Конвертер растровой графики для монохромного LCD (128х64)
Дизеринг для монохромных LCD и конвертер растровых изображений
ZP-STM32 и беспроводной последовательный порт
Куда уходят миллисекунды? Способ повышения FPS
Open Logic Sniffer в действии
AVR XMEGA – разгон, вольтмод и производительность SDRAM

А надо ли при DMA передаче из памяти в периферию как-то ждать пока данные (каждый байт) передадутся или они там сами как-то друг с другом договариваются?

Fasterpast
А какой смысл в DMA, если надо ждать? Если процессор нечем занять, так он быстрее и без DMA сам все сделает, у него всегда приоритет при работе с шиной. DMA и нужен для асинхронного распараллеливания. Каждый DMA канал имеет свое прерывание, срабатывающее по окончанию трансфера или при ошибке, там свою логику и задавай.
Другое дело, что практического выигрыша можно не получить, особенно гоняя с DMA большие блоки и интенсивно гружа процессор работой с той же шиной, тут выгадать можно лишь несколько процентов. Нужно четко все продумать и понимать, как все будет работать, а не ждать чуда в виде двойной ПСП.

я имею ввиду, что если я задам для DMA передачу блока в 40кб из адреса оперативки с инкрементом, а адресом назначения задам регистр ввода-вывода усарта? А сам усарт при этом работает на скорости всего 57600бод. Сможет ли DMA сам ждать пока закончится передача каждого байта или придётся передавать побайтно каждый раз проверяя флаг статуса передачи усарта?
Поэтому и спрашиваю, что если флаг надо проверять, смысла в использовании ДМА нет в данном случае.

Нужно ставить блок в 1 байт, повтор 40к, USART будет сам запускать, но прерывание после каждого байта будет.
Тебе проще тогда буфер статичный под USART выделить, и по кольцу его пустить, как при аудио выводе, с подгрузкой буфера по DMA, а триггер программный, по указателю считанного положения в буфере.

Новости с фронта.
Собрал платку на Cortex-M3 STM32F103RDT6, ради поддержки SDIO, которая у ST появляется только на 64-ногих МК. Атмеловские 64-ногие AVR32 SDIO не имеют, только 64-ногие Cortex-M3 ATSam3, но пока их у Farnella в наличии нет. Вот-вот в продаже должны появиться и Cortex-M3 STM32F2, которые пойдут для робота, так как имеют встроенный интерфейс для видеокамеры.
STM32F103RDT6 в работе (дисплей слева подключен к XDB на XMega128):

#77

Как говорится, и на старуху бывает проруха - на плате была позорно перепутана полярность у всех ножек питания МК . При первом включении (питание от USB) стабилизатор FAN1540B сильно нагревался, хотя линия 5v и защищена на 200мА. Сначала думал выкинуть плату и решил ее добить. Подал напряженте 1.6В после стабилизатора. Ток уходил за 2А . Но на другой день решил попробовать подать правильную полярность, это было совсем несложно - четыре надреза на плате, три перемычки проводами и два нулевых резистора вместо индуктора и конденсатора в цепи питания аналогового блока, минут 20 все заняло. Но надежды на работоспособность МК оставалось мало. Однако, мк живучий, зараза, заработал. Правда, первый день грелся градусов до 50, но все порты GPIO работают, хотя за всю встроенную периферию поручиться нельзя. К тому же, на следующий день он "переболел" и температура стала в норме, может что из периферии внутри и отвалилось.

Плата рассчитана на работу с XDB как вспомогательный DSP процессор, SDIO и USB интерфейсы, а для связи с XMega128 будет использована параллельная 16 или 8-битная передача данных, на ней пока LCD сидит в 8-битном параллельном подключении.

Собрал второй вариант дисплея, он слева на фотке, подключен одним шлейфом к плате XDB, на которой вертится слайд-шоу с флэшки (16МБайт 104МГц Spansion), она работает от 25МГц SPI, что дает скорость заполнения экрана 320х240х16 в 95мс, но я пускаю через SRAM, чтобы получалось побыстрее раза в два, плюс реализованы различные программные эффекты смены кадров (различные скроллинги, слайсинги и прочая ерундовые видеоэффекты). На плате дисплея установлен отключаемый SPI тачконтроллер 7843А (на XDB стоит тачконтроллер I2C TSC2007). Кроме того, стоит 3-х осный акселерометр MMA8453Q от Freescale для определения ориентации и мосфет для PWM регулировки подсветки.
Дисплею, однако, тоже не повезло - на него был пролит соус, который разъел бумажные наклейки (боже, чем я питаюсь?) на тыльной стороне LCD и задубил шлейф, слегка вздыбив LCD над платой. Я пока жестко его не крепил, так как еще потребуется небольшая доработка модуля.

Пара слов про I2C на XMEGA, так как до этого этот интерфейс на этом МК не пробовал.
На XDB установлен контроллер тача I2C TSC2007 (отключаемый, так что можно выбирать, использовать ли контроллер на плате дисплея (7843А), или TSC2007, или же вообще отдельно установленный. Посмотрел я на недоделанный драйвер TWI из атмеловского фреймворка 2.4 и решил его не использовать, так как формат пакета, как ни пыжилысь разработчики, не универсальный и все равно требует доработки, да и нагромождение в угоду универсальности я тоже не принимаю на МК. А если еще все и по MISRA делать, так туши свет.

Что хорошо у XMEGA с TWI - так это уменьшение прерываний, то есть, к примеру, после генерации старта прерывание не происходит, в отличие от простых МК MEGA и т.д.
Что плохо - в процессе написания собственного драйвера обнаружились локауты на шине. Errata по ревизии H чипа ATXMega128A1, хоть и изобилует нюансами по I2C, не помогла.
Чтение флага статуса TWI в начале обработчика прерывания показало, что кроме стандартных состояний шины, проскакивают статусы 0x02, который и приводит к локауту (хотя и не всегда) и 0x22(горадо реже) . Последний вариант вообще удивителен, так как флаг CLKHOLD взводится только при наличии флагов RIF или WIF. А при 0x02 и 0x22 - как вообще прерывания вызываются? Загадка, однако.

Борьба с эти злом такая - считаем прерывания со статусами 0x02 и 0x22, (т.е когда реальные флаги прерываний не установлены), ложными-ошибочными, и сразу выходим из разработчика, пробовал другие варианты с переводом в IDLE и т.д., но этот самый лучший, так как работа с пакетом не нарушается. Для примера взят TWIC :



После этого все работает пучком.

Кстати, без EBI мой экземпляр ATXMega128A1 на плате XDB стабильно работает на 60MHz, а с EBI (EBI = 100MHz, внешний модуль SDRAM 8MB на ISSI IS42S81600D) полная устойчивость только на 50MHz. Разумеется, эксперименты с TWI проводились и при номинальном режиме без разгона, на режимах I2C 100 KHz и 400KHz, но статусы 0x02 и 0x22 вылазили и в этих условиях.

Еще нюанс - ни с того, ни с сего на плате XDB сдох MCP2200, отвечающий за связь XDB с ПК по USB (на самом деле, это обычный, но уже запрограммированный МК PIC18F14K50 от Microchip), пришлось менять. Пулл -ап подключает, но не распознается как USB устройство, еще интересно, что при этом на его ноге Vusb напряжение стало 3.1-3.2В вместо 3.3В. От пяти вольт тоже больше не заработал, пришлось его менять, похоже на то, что слетела внутренняя прошивка.

zauropod
Привет. Че не докладываем обстаконовку с фронта.
Жду прибытия белых мух, как только полетят готов открыть второй фронт.

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

С маленькими МК я уже наигрался, даже добавка USB не спасет в моих глазах AVR XMega, полностью перехожу на ARM. Купил себе несколько китов, потихоньку осваиваю Линукс.
...
А пока я ждал STM32F2, уже вышел STM32F4, 168МГц, с поддержкой камеры и с FPU. Тоже прикупил себе пару плат STM32F4-Discovery, так как она стоит как сам процессор, плюс взял еще отдельно старший процессор из серии, че-нить изваять свое. Процессор на Discovery разгоняется у меня до 250 МГц (на 260 стартует, но через пять минут виснет).
К новому году должен в продаже появиться LPC43xx, двухъядреный, тоже интересная штука.
А атмеловцы что-то дремлют, правда скоро должны выйти новые дешевые армы-926 с 2Д ускорителем, ну так он у них и раньше был, еще на AP7xxx. A на AVR плавающая точка у них куда-то делась, до сих пор серия AVR32uc3c только в китах доступна, ручная работа. Да и всего только 66МГц.

Кинь плиз ссылочку, уже скачал мануал с даташитом, если осилю 1315 страниц то может тож поиграюсь.
В STM32F4 понравилось наличме переферии и частота которой не хватает в XMega но ее не брошу,
буду добивать.
Очень рад, что откликнулся, а то уже заскучал.

Так в поисковике любого дистрибутора (mouser, farnell, digikey, ...etc) набираешь STM32F4 и смотришь. Но плат STM32F4-Discovery сейчас в наличии ни у кого нет - первый транш расхватали в три дня. Ближайший вброс будет у Farnell, там около 500 штук появятся дней через 10, но их наверняка тоже быстро разберут. Я брал из первого замеса на маузере.

А по цене - отдельный МК STM32F407VGT6 по каталогу маузера стоит более 14 евро, а плата с этим МК - 13.96. А ведь на плате еще стоит отладчик ST-Link V2, который перемычками превращается в standalone debugger для прошивки-отладки других плат на STM32, плюс аудиочип CS42L22, с усилителем для наушников и гнездом для их подключения, трехосный акселерометр и MEMS-микрофон, micro-USB и прочая мелочевка, поэтому я и взял две штуки, одну чисто под нож на детали.

Не понравилось, что сразу установлены два ряда гребенок ножками вниз, неудобно. Это наводит на мысль, что скоро появится какая-то несущая плата, наподобие платы от Embedded Artists для платок LPC Expresso на МК от NXP, но они там по умолчанию гребенку не припаивают. Там я сам припаял, так как они однорядные и ставятся и на стандартную отладочную плату, в отличие от STM32F4-Discovery.
Кроме того, сэкономили на часовом кварце, хотя место и разведено, я установил Epson-Toyocom MC306 (разведен именно его типоразмер) и пару его нагрузочных конденсаторов.
Потихоньку ковыряюсь - подключил дисплей, контроллер тача, rtc, сейчас буду файловую систему ставить, как раз FatFS обновилась до версии 0.9, теперь реализована разбивка тома на логические разделы.

Кстати, утилита ST-Link Utility требует обновления. Версия 2.0 не работает с платой, 2.1 работает, хотя и неправильно показывает тип МК и не показывет размер флэша. Вчерась на сайте появилось описание версии 2.2, с поддержкой STM32F4, но пока есть даунлод только на старую версию (2.1).

zauropod
Почитал (пока мельком) мануал STM32F4 понял почему XMegу не могут поднять по
частоте, STM32F4 одноцикловае обращение к флешу делает на той же частоте
(если правильно врубился), еще не понял как STM32F4 выполняет инструкции
из срама. Очень понравились шины в STM32F4, в XMegе столкнлся с тем что при
подаче команд по ДМА в LS020 нельзя дергать шину процем (все сбивается).
И вообще толку от 4 канального ДМА если шина одна да еще общая с процем.

STM32F4-Discovery пока не закозал на маузере специальное предложение
мне выставили в 18$.
Щас буду искать руский манул на предыдущее поколение STM32F4, англ
у меня попрежнему страдает.

Врубился неправильно.
Во-первых если под "не могут поднять по частоте" понимать частоту работы процессорного ядра, то к встроенному флэшу это имеет второстепенное отношение. Чудес не бывает и пока вся широкораспространенная флэш-память работает на частотах до нескольких десятков МГц. Если ядро быстрее, то при обращении к флэш вводятся циклы ожидания. Например, для STM32F4 на 168МГц устанавливается (рекомендуется, установить можно и 0) 5 пустых циклов ожидания для доступа к флэш. Другое дело, что шина доступа к ней у STM32F4 128-битная и применяется кэширование с предсказанием, что дает такое практическое быстродействие, как будто бы флэш также работает на частоте 168МГц без задержек.

Во-вторых, разрабатывать свои процессоры очень дорого, поэтому проприетарные поделки выходят чрезмерно дорогими. Гораздо дешевле обвесить периферией какое-нибудь уже хорошо отлаженное ядро ARM, которое производится в несравненно бОльших объемах и стоит копейки (копания ARM продает лицензии на произодство и этих денег ей вполне хватает на поддержание своих передовых позиций). Проприетарный процессор просто не выдерживает конкуренции - на базе ядра ARM получается и быстрее, и функциональнее, и дешевле. Производитель своих процессоров вынужден подстраиваться под цену на ARMы, что, вероятно, выводит его на крайне низкий уровень рентабельности. Поэтому на рынке между ценой и производительностью МК отсутствует корреляция. Собственные процессоры требуют денег на R&D, а где их брать, если продажи ограничены? И какую тогда цель ставить, если ARM работает во всех сегментах и выигрывает по всем параметрам у проприетарной технологии? Замкнутый круг.

А из RAM инструкции выполняют многие процессоры, 32-битные так все, наверное, включая AVR (насчет Microchip не знаю), имеются разные опции загрузки. Но если имеется встроенная флэш, то инструкции из нее выполняются быстрее за счет оптимизации доступа и кэширования.

Про DMA на XMega - согласен, толку мало. Незапинающийся аудиоплеер у меня не получился, независимая подкачка кольцевого буфера не очень получается. Хотя из RAM все звучит красиво, даже на встроенном 12-битном DAC. Но перезапись в RAM долгая, да и 8MB всего. Что касается "все сбивается" то тут скорее всего некорректная реализация.

Кстати, версия утилиты ST-Link 2.2 не показывает размер флэш у STM32F4 (1 MByte) - пишет "unknown". Наверное, самому молодому доверили апгрейд. Процессорное семейство теперь правильно определяется, а флэш нет. Хотя на работу это и не влияет.

Неужто на STM32F4 портировать будешь?
Еще вопрос по электропитанию, почитал получается что STM32L экономичней XMega,
а STM32F4 на той же частоте не намного больше жрет. А как на практике если протестил?

Разорочеровало малое количество регистров на Cortex®-M4. В своей программе я регистрам
присвоил опредиленные функции и сторался чтоб они были одинаковые во все подпрограммах
и прерываниях, чтоб проще и быстрее было скакать по коду (отпадает необходимость их сохранять при
переходе)


Не правильно выразился, сбивается командный код LS020 (начинает не там выводить), а так если проц
не мешал во время передачи команды области вывода, данные выводятся нормально даже если проц отнимал
шину у ДМА, хотя особо не проверял.

Возможно, но в следующем году. Поскольку младшие кортексы не имеют встроенного менеджмента памяти (MMU), то прямая сборка стандартного ядра Linux под armel не прокатит. Есть специальные сборки под cortex-M3, но я пока особо не вникал (да и в самих исходникая ядра линукса есть заточки под процессоры без MMU, в частности, под AVR32). Пока нужно на обычном 926 арме потренироваться. Уже разработал несколько своих вариантов борды, на imx233 и AT91SAM9g20, развел платы, но делать не стал. Обычные платы у меня и так есть (на атмеловском AT91SAM9g45 и самсунге sc2440), захотелось сделать что-то законченное в виде "убийцы iPAD" . Но нужен красивый (по крайней мере, не страшный) корпус, поэтому купил новую готовую китайскю финтифлюшку с пятидюймовым дисплеем 480х272 (выбранные процессоры, увы, и это с трудом проглатывают на видео), вот сейчас туда буду проектировать свою начинку. Для начала сделаю несколько разных плат, на STM32F4, AT91SAM9g15 и imx233. Для STM32F4 (возможно и для LQFP imx233 , но там можно на внешнем регистре сделать 16-битную rgb шину) будет эпсоновский контроллер дисплея, уже парочку приобрел (они в 100-ноговом LQFP). Также взял несколько чипов sil для радио и пару wi-fi модулей от ровинга. Наверное, только к Новому году че-то сделаю.

Конечно, была бы возможность дешево делать 6-слойные платы, можно было бы взять за основу фрискейловый 535, а так только голая плата обойдется больше сотни баксов, плюс большая вероятность, что нормально не заработает с первого варианта разводки (да и со второго), а если еще ошибочка вкрадется... Если это не бизнес, то в трубу вылетит слишком уж много денег, в разы больше розничной стоимости самого распрекрасного сегодняшнего миникомпьютерного девайса. А на 2х-слойке можно спокойно развести корпус BGA-217, не говоря уже о LQFP и на частотах процессора 400МГц еще можно исхитриться добиться устойчивой работы. Я даже показывал эскиз платы на базе 169-ногой BGA imx233 изготовителю печатных плат, там требуются 0.1мм проводники и зазоры (при разводке на двухслойке), производитель плат готов попробовать, но я решил все же сначала сделать на imx233 в урезанном исполнении LQFP-128.


Энергосбережением я пока детально не занимался. Но самыми экономичными сами себя называют поделки от Energy Micro, новой норвежской компании, делающие процессоры EFM32 Gecko (ессно, на базе ARM).


Батенька, это вы о чем? Каких регистров меньше?
То, что архитектуры разные, не смущает?
Или как смотрится наличие у STM32F4 CCM-памяти в 64 килобайта против 32 байт регистров XMega?
XMega хороша наличием аж целых 16 GPIO регистров, но в сравнении с серией других восьмибитных AVR-ок. С армами даже и сравнивать смешно. Да и внутренней SRAM у STM32F4 в 25 раз поболее, чем у ATXMega128A1.

zauropod хоре, я ж писал что прочитал мельком: процессор Cortex®-M4 содержит 16 32-битных регистров,
банкированных регистров у него как я понял нет, но если в режиме быстрого прерывания они автомотически или
одной командой записываются в CCM-памяти то это конечно круто.

Не всякий тулчейен, видимо, одинаково работает с FPU. Интересную штуку обнаружил.
STM32F4-Discovery + Atollic True Srudio Lite 2.2 for STM32.
Простейшая программа, в цикле 10 млн. вычислений дистанции, плюс мелочевка ( результат операции с FPU нельзя использовать сразу, иначе получаем лишний такт):



И затем такой же кусок с переменными типа double (Cortex-M4F поддерживает только сингл, даблы будут всегда делаться программно).

Без FPU:

#77

C FPU:

#77

Очень даже неплохо. На точность переменной x на сингле внимания обращать не стоит, если цикл в сто тысяч итераций и выше, то накапливаемая ошибка дает знать.

Развернем цикл на 10 вычислений дистанции в цикле, это стандартная практика, если выполняется поток в поллинге.

#77

Софтверный дабл, как и положено, от этого выиграл, но аппаратный результат стал раз в шесть хуже!

Ищем дизассемблером, где собака порылась. Оказывается, только первая дистанция в каждом развернутом цикле вычисляется аппаратно (ассемблерная команда vsqrt), а последующие вызывают функцию <sqrtf> из стандартной гнусной матбиблиотеки.

Надо при случае проверить, как другие тулчейны. Кикстарты Кейла, правдв, идут без дизасма, а у IAR в обрезках он есть. Если у кого есть другие - от Rowley etc, проверьте, дюже интересно стало.

Вообще Atollic много мелких пакостей в бесплатном варианте наделал - к примеру убрал перенаправление ввода-вывода, поэтому printf, putchar, etc не работают и линкуются на пустышки, пришлось использовать для своего ввода-вывода другие имена. Может и с FPU чего-то ограничили.

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

STM32F4 и без FPU, хоть и работает на меньшей частоте, но быстрее AT91SAM9260, а FPU при фиксированной точке будет равен 400МГц AT91SAM9g45, а на DSP-задачах с плавающей точкой и побыстрее будет.

В этом году так и не собрался сделать новые платы, отложил на январь. Пока суть да дело — набросал основу будущего 3D-фреймворка для STM32F4.
FPU все-же классная штука - операции над числами с плавающей точкой одинарной точности производятся за 1-2 процессорных такта (разве что деление и вычисление квадратного корня требуют по 14 тактов). Поддерживаются float DSP MAC операции (в смысле умножения со сложением Multiply–ACcumulate, а не обработка MAC-адреса).
Пока написал самое простое — матричную математику, создание и обработка примитивов как объектов, поддержка некоторых рендерстейтов. Скоро добавлю подгрузку 3D моделей. Растеризатора пока нет, сейчас рисуются грани треугольников, видимых по нужному знаку 2D кросс-продукта после проекционной матрицы. Ввиду отсутствия достаточного объема памяти и подключения LCD по SPI, размер буфера рендеринга ограничен 128х128х16, а еще будет нужен (для растеризации) z/w буфер и еще куча чего. С нормальным LCD интерфейсом и памятью в пару мегабайт — фрейм с 10K полигонов с освещением, текстуризацией и прочими чудесами не будет проблемой FPS > 20 на QVGA.

А еще можно сделать многоконвейерную обработку, благо 3D задачи хорошо распараллеливаются — можно несколько процессоров соединить по принципу FSMC->DCMI у «центрального» МК к сопроцессору, а у того, в свою очередь, от своего FSMC на DCMI «центрального». И таких графических сопроцессоров может быть много. Так можно и GeForce256 переплюнуть.

Вот сохраненный в файл бэкбуфер, где по двум осям вращается 3х3х3 = 27 кубиков. FPS =50, с учетом передачи фронтбуфера по SPI.

#77

Статичная картинка не дает возможность оценить трехмерность, поэтому при желании можно посмотреть динамику здесь (mpeg4 700 килобайт)

На Mouser уже доступен двухъядерник LPC4350 от NXP. Он по многим параметрам получше STM32F4, включая поддержку RGB LCD, SDRAM, QUAD SPI и т. д., прада у него поменьше таймеров, нет CCM, и еще есть масса различий, но STM32F4 давно уже продается в полном ассортименте, а LPC4350 есть пока только в корпусе BGA-256, хотя и с редким ныне шагом в 1мм. И за время подготовки к выпуску NXP дважды повысила частоту для обоих ядер М0 и М4 — сначала со 160 до 180, а затем и до 208 МГц. Но цена крайне конкурентная у него - вдвое ниже флагмана от STM. Скоро и Freescale представит своего Cortex-M4 флагмана Kinetis K70, там тоже 200МГц и еще больше SRAM, чем у NXP.
A Atmel только анонсировала SAM4S, без FPU, без HS USB и с меньшей почти на треть частотой — 120 МГц против 168МГц у STM32F4.

Загрузчик моделей из файлов написал, пока только для неанимированных моделей.
#77

На картинке модель содержит триста с хвостиком полигонов, файл 14кбайт. Воздушный бой уже можно делать. Для моделей высокого разрешения нужно побольше памяти, да и без растеризатора они на разрешении 128х128 совсем не смотрятся, каша получается.
Геометрия в грубой основе сделана, приступаем к "пиксельному шейдеру".

Так на какой OSи все это крутишь?
STM32F4 я так и не прикупил, да и серьезно с другой архитектурой разбираться решил отложить.
Наконецто добил свою XMEGAМЕНЮ Вер0.0. Теперь буду прикручивать XPLAIN к трансу сварочного.
Управляюшая прога в настроечном режиме тоже (надеюсь) готова.
Так что скоро начну гнуть силовые магнитные линии.

"Стандартная" ОСь для МК подобного класса, даже при наличии большого объема внешней памяти, строго противопоказана. Это если говорить о базировании на ядре Линукс. Пользы от нее будет меньше, чем вреда, для этого нужна архитектура и быстродействие Cortex-A. Тем более, Cortex-M4 не имеет MMU, что предполагает выбор uCLinux. Если готовая ось нужна, надо выбирать и соответствующий МК.

OCь нужна для обеспечения стандартного подхода к решению задач, возможности использования уже имеющегося ПО и быстрого сопряжения с внешним миром. Мне ничего этого не надо. Для того, чтобы реализовать 3D сцену Ось не нужна.

Делаем инициализацию МК, файловой системы и прочего, затем впадаем в стандартный цикл, вот как он у меня сейчас:



Там, где многоточие - еще тачскриновое управление, безо всяких прерываний. как оказалось, 375мкс для определения координат касания тача, на мои задачи не влияет.
Нужна, естественно, математическая библиотека - но это просто написать, если знаешь матричное исчисление (или кватернионы), есть и ARM CMSIS DSP Library для M4, но ее нужно переработать для 3D. Я оттуда взял только таблицу углов в градусах. Кстати. сама процедура arm_sin_cos в этой библиотеке работает неправильно.

Для поклонников XMEGA - где-то уже месяц как на Mouser прилетели первые XMEGA c USB, пока с флэшкой 32К, если делать выборку по ключевому слову "XMEGA", то они будут на одной из последних страниц, сразу их и не увидишь.