Сообщество

Планируется ли появление интерфейса CAN и увеличение числа АЦП до 16 (12 bit вполне достаточно при измерении от 0 до 3v0)?
Насколько я понимаю, SPI0 на отладочной плате LDM-MCp04111 можно задействовать, как альтернативную функцию GPIOB[0..7]? Хочу опробовать внешний SPI-экран.

В целом, наличие тех или иных периферийных блоков зависит от конечных потребностей. В этом плане, у TI весьма неплохо проработаны линейки TMS320F28xx. MultiClet мог бы стать достойной альтернативой TMS, который ещё не во всех сферах можно применять из-за экспортного регулирования США. MultiClet молод и очень хотелось бы надеяться, что в будущем линейки P...L разделятся на модификации, где, скажем, есть Ethernet/USB, а где его нет, но есть другая периферия — CAN, SPI, множество АЦП и PWM. Например, TMS широко используется для управления шаговыми двигателями, моторами и сервоприводами. Ethernet и USB — это излишки. Тот же Ethernet можно замечательно прицепить по SPI аж с аппаратной поддержкой 3-го и 4-го уровней OSI.

Могли бы вы дополнить тех. документацию на отладочные комплекты информацией о типовых значениях числа циклов перезаписи EEPROM, NAND. Всё это, конечно, можно найти по маркировке, но хотелось бы всё в одном месте. Ещё лучше сопроводить это ссылками на спецификации

Ещё бы неплохо помимо принципиальной схемы иметь пример разводки в виде PCB и руководство по дизайну своих собственных PCB, подобных такому . Особенности наверняка есть, которые надо учитывать :)

Увеличение числа АЦП до 16 будет реализовано в мультиклеточном процессоре серии "P" - performance, который в настоящее время готовится к выходу; интерфейс CAN планируется в серии "L" -liveness.
Линейки P...L конечно же разделятся на модификации.

А в пределах одной серии и 16 ADC, и CAN будут? В том же "L" к месту будут два CAN для резервирования.

В одной серии пока не планировали, такие комбайны будут в составе SiP с двумя кристаллами. А в L1 будет несколько и CAN и SpaceWare

Поясните, пожалуйста, что есть SpaceWare? Раньше не слышал и поиск не помогает.

SpaceWire, подробности тут http://www.star-dundee.com/SpaceWireKB

Могу даже кратко рассказать что и как работает, но в документах интересно и просто написано с примерами космических миссий.

Кстати, пока CAN ещё только на бумаге, есть ли какие-то драфты: что войдёт в состав CAN? Версия CAN 2.0A или 2.0B, упрощённая или полная реализация. В случае полной реализации, каково число Mailbox'ов, наличие плюшек вроде управления Auto BUS ON, диапазон доступных скоростей, возможность управления длиной TQ и, соответственно, длительностью сегментов, счётчики ошибок и т.д.

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

В целом, мне от CAN нужно несколько вещей:
1. 32 ящика (16 ящиков очень удобно использовать под payload при пересылке прошивок по xmodem-подобному протоколу, переточенному под CAN)
2. Понижение скорости до минимума-минимума. На TMS320F2808 @ 100Mhz этот минимум был 50kbps из-за предельных значений делителей (SJWREG=3, BRPREG=199, TSEG1REG=15, TSEG2REG=7). Связано это с длиной шины CAN и переходами. Кое-где используется блок щёток с валом, вращающимся до 5000 rps. Проблемы уже всплывают при 3200. На пяти тысячах связь вообще пропадает (или питание отваливается, передающееся через те же щётки).
3. Изменяемая длина ящика (1..8 байт)
4. Изменяемый порядок байтов (LSB/MSB) в ящике. Сталкивался при взаимодествии TMS320 с LM3S.
5. Auto Bus On. Полезно, если из-за проблем с шиной отключается ядро CAN, а потом вновь автоматом включается.
6. Регистры с состояниями TX/RX для каждого ящика (bitfields).
7. Отключение фильтра MSGID для приёма любых сообщений конкретным ящиком.
8. Внешний трансивер. На чипе только ядро с RX/TX на выходе.

У microchip есть внешний CAN-контроллер с весьма подробным описанием возможностей и блок-схемами: http://ww1.microchip.com/downloads/en/devicedoc/21801d.pdf
Есть ещё хорошая презенташка по CAN: http://www.slideshare.net/pantechsolutions/can-f28x

Расскажите, пожалуйста, про механизм запуска программы из внешней ПЗУ. Объём её превышает объём памяти. В описании на LDM сходу не попалась карта памяти, где бы фигурировала ПЗУ, из чего напрашивается вывод, что весь код выполняется в памяти, предвартиельно будучи скопированным из ПЗУ.
Я так понимаю, что выполнить код и из NAND нет возможности, т.к. флэшка просто висит на GPIO без отображения в область памяти MCp.

PS. Есть ли планы по защите от копирования прошивки средствами криптографии? Например, шифровать ПЗУ тем же 89-ым ГОСТом, а при отладке давать читать/писать средствами отладчика из/в защищённые области памяти только при "разблокировке". Для "экспортных" модификаций вместо ГОСТа можно использовать и AES, хотя это значит поддерживать две аппаратные реализации… или только блокировать отладочные средства в "экспорте".

Есть ли рекомендации по тому, должны ли неиспользуемые ноги быть повешены на землю, чтобы в воздухе не болтались?
Кстати, насколько UART (чистый, без FTDI) невосприимчив к неверной коммутации? Например, если землю повесить на RX/TX процессора, а внешний RX (или TX) на землю?

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

Я больше про кратковременное включение. От 10 до 40 секунд, пока не поймёшь, что не туда воткнул, а плата включена :) С TMS ничего не происходит, но его приходится по питанию дёргать — он не любит при включенном UART заземления то ли RX, то ли TX.

Разных типов портов у нас в текущий версии нет.

Не совсем понял.

PS. Про ПЗУ и по защите прошивок из сообщения выше сможете пояснить?

В текущем процессоре весь код выполняется в памяти, будучи предварительно скопированным из ПЗУ. Гарантировать, что пин UART выдержит 40 секунд не могу, но какое-то время продержаться должен. На такие эксперименты пока не было времени.

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

На космос больше будет ориентирована 3-я версия процессора, хотя и для неё применение криптографии пока не обсуждалось. Там ключ для расшифровки и через другие интерфейсы можно будет передать, не с флешкой же к спутнику лететь).

Загрузчик-то тоже должен откуда-то грузиться. Ключ, передаваемый по, в общем-то, открытым каналам, легко вылавливается. В таких случаях, ключ должен "лежать" в защищённой от чтения области внутренней ПЗУ (вплоть до однократно программируемой). Но весь процесс расшифровывания прошивки перед выполнением перекладывается на аппаратную часть (в случае внутренней FLASH ничего этого не нужно, т.к. просто блокируется доступ на чтение). Внешнего вмешательства для работы уже не требуется. Разблокировка доступа на чтение, как я писал выше, в случае использования внешней ПЗУ, может быть нужна только для отладки. Разблокировка на запись только в случае использования встроенной FLASH, которой, как я понимаю, не предвидется. Вопрос про разблокировку опционален, т.к. отлаживаться можно и на обычной прошивке.

В следующей версии процессора будет возможность загружаться из внешней памяти.

Следующая версия — это P2 или P3? Загружаться или выполнять код из внешней памяти без копирования из ПЗУ? Т.е. можно будет выполнять код (RX) прямо из NAND?

Т.ч. пока это просто фичареквест :)

Возможность сделать корпус с встроенной ПЗУ Flash типа предварительно установлена в конфигурации нового процессора. Но весь процесс расшифровки прошивки на аппаратную часть пока не планировали переложить. Ну смотря как зашифровать ключ даже и по открытому каналу. Можно же ещё процесс синхронизации сделать и тогда ключ будет каждый раз уникальный и не в открытом виде.

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

Возможность сделать корпус с встроенной ПЗУ Flash типа предварительно установлена в конфигурации нового процессора.

Если Flash будет встроенной, то тогда криптуха не нужна. Только защищённая область от чтения для хранения ключа (в той же ПЗУ). Тогда и не нужен аппаратный алгоритм on-the-fly расшифровки перед выполнением. Всё становится гораздо прозрачнее, проще и без ущерба производительности.

Ну смотря как зашифровать ключ даже и по открытому каналу.

Тогда это уже не блочное шифрование. Ассиметричные алогоритмы для передачи сессионного ключа (блочного) весьма накладны. Внешнее статическое хранилище ключа ничем не защищено. Взламывается обычной атакой MitM — добавляем промежуточное звено, которое прикидывается MCp при общении с хранилищем и потом использует полученный ключ для работы с MCp. Дальнейшая защита только путём усложнения схем взаимодействия между "доверенным хранилищем" и MCp.

В общем, достаточно встроенной Flash с защитой от чтения + защищённая область памяти от несанкционированного чтения/записи с разблокировкой по ключу, хранящимся во внутренней флэш. Можно ещё блокировать чтение GP-регистров отладчиком :)

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

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

micron_multiclet wrote:

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

Я пока не настолько углубился в новую для меня архитектуру. Знаком всего неделю. Из вводных данных, пока видится добротный источник энтропии для генератора случайных чисел (если уметь "снимать" эти состояния в виде 32-64-128 битных слов). Возможно, ещё что-то придёт в голову, но если есть какие-то задумки/задачи…

У нас мысль движется в сторону доп уровня защиты для USB токенов, как-то так, очень неопределенно пока и траст-процессоров

Про токены не совсем понятно. В студенческую бытность ковырял ruToken'ы (пытался прикрутить к pcsc в линуксе и помогал сокурсникам прогать их). UBS-токен осуществляет криптографические операции над данными, которые через него проходят (шифрование, подпись, верификация) + управление сертификатами на самом токене.

Траст-процессоры немного попонятнее. Выполнение подписанного (доверенного) кода, обеспечение (в том числе, на аппаратном уровне) целостности и защиты данных, передаваемых по открытым каналам (периферии) процессора, защита от НСД к данным выполняемого доверенного кода и т.д. Т.е. некий аналог ARM TrustZone, Intel TXT и TPM.

В руководстве на страницах 92-93 отсутствует информация о назначении выводов для корпусов LQFP-128 и LQFP-144. Пункты 6.3 и 6.4 не содержат заветных таблиц. Хотелось бы узнать различия выводов между QFP-208 и LQFP-144 (альтернативные функции). Если верить спекам на QFP-208, то LQFP-144 получается почти тот же QFP-208 за вычетом SPI1. ИМХО, три UART'а явно избыточны. Лучше вместо UART0 или UART1 было б вывести SPI1.

Документ доработаем. Спасибо!

Для удобства можно вынести на страницу распиновки помимо основной функции выводов их альтернативные функции:

GPIOC[4]/PWM0

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

mouse

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

Да, мы в курсе такой возможности, но в ближайшем новом процессоре это пока не применяем.