Project

General

Profile

Хотелось бы...

Added by HEMAH about 11 years ago

Под таким весьма незатейливым названием думаю, будет весьма удобно, разработчикам РЭА размещать свои пожелания по элементной базе.
Ну и свои собственно, хотя сам являюсь более схемотехником и более отношусь к категории "ПЛИСовод-затейник".

Итак:

  1. На отладочной плате, хотелось бы увидеть графический дисплей. Вы не атмеги "за рубль - ведро" производите, а вполне серьёзный камень для обработки данных, поэтому предоставление в качестве средства индикации семисегментного дисплея это, ну по крайней мере по моему мнению, "маловато будет". Тем более есть МЭЛТовские МТ12864, которые по цене не сильно поднимут общую стоимость, однако в качестве отладочного интерфейса, графическому дисплею цены нет, да и выводов он мало занимает.
  2. Общий недостаток, но это у всех, причём поголовно, и сам, когда что-то подобное делаю, часто забываю. Сделайте на плате отладочного комплекта дополнительные клеммы заземления. Когда подключаешь внешнюю аппаратуру, всегда дефицит))) Штуки две-три, больше не нужно, однако не придётся использовать всякие, не предназначенные для этого вещи.

Replies (72)

RE: Хотелось бы... - Added by mouse over 10 years ago

Планируется ли появление интерфейса 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, подобных такому . Особенности наверняка есть, которые надо учитывать :)

RE: Хотелось бы... - Added by Natalia_multiclet over 10 years ago

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

RE: Хотелось бы... - Added by mouse over 10 years ago

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

RE: Хотелось бы... - Added by micron_multiclet over 10 years ago

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

RE: Хотелось бы... - Added by mouse over 10 years ago

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

RE: Хотелось бы... - Added by krufter_multiclet over 10 years ago

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

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

RE: Хотелось бы... - Added by mouse over 10 years ago

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

RE: Хотелось бы... - Added by DmitryK_multiclet over 10 years ago

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

RE: Хотелось бы... - Added by mouse over 10 years ago

В целом, мне от 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

RE: Хотелось бы... - Added by mouse over 10 years ago

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

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

RE: Хотелось бы... - Added by mouse over 10 years ago

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

RE: Хотелось бы... - Added by krufter_multiclet over 10 years ago

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

RE: Хотелось бы... - Added by mouse over 10 years ago

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

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

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

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

RE: Хотелось бы... - Added by krufter_multiclet over 10 years ago

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

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

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

RE: Хотелось бы... - Added by mouse over 10 years ago

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

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

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

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

RE: Хотелось бы... - Added by krufter_multiclet over 10 years ago

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

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

RE: Хотелось бы... - Added by mouse over 10 years ago

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

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

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

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

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

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

RE: Хотелось бы... - Added by micron_multiclet over 10 years ago

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

RE: Хотелось бы... - Added by mouse over 10 years ago

micron_multiclet wrote:

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

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

RE: Хотелось бы... - Added by micron_multiclet over 10 years ago

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

RE: Хотелось бы... - Added by mouse over 10 years ago

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

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

RE: Хотелось бы... - Added by mouse over 10 years ago

В руководстве на страницах 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.

RE: Хотелось бы... - Added by Natalia_multiclet over 10 years ago

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

RE: Хотелось бы... - Added by mouse over 10 years ago

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

GPIOC[4]/PWM0
Ещё есть одно пожелание, но оно сильно завязано уже на аппаратную часть. Для сокращения числа выводов или увеличения плотности функциональных выводов, назначать несколько альтернативных функций на один вывод. При этом, придётся расширить поля у GPIOxBPS до двух бит на один GPIO, что повлечёт за собой появление ещё одного GPIOxBPS. Например, может быть нужно три SPI, пара UART и ни одного USB/Ethernet (если комбинации альтернативных функций позволили бы так сделать). И что хуже всего, всё это повлечёт сильное перетряхивание вентилей внутри микросхемы.

RE: Хотелось бы... - Added by krufter_multiclet over 10 years ago

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

mouse

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

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

(26-50/72)