Вопросы по программному обеспечению

Как программировать коммутатор?

Не предполагается написание пользователем программы для микросхемы 1892КП1Я. Мы предоставляем управляющее ПО в бинарном виде. Оно прошивается во внешнее ПЗУ, подключённое к выводу nCS[3] (накристального ПЗУ нет), и самостоятельно осуществляет настройку и управление коммутатором. В итоге пользователь получает коммутатор SpaceWire, работающий в полном соответствии с требованиями стандарта.

Как запрограммировать данное ПЗУ?

Если используется микросхема Flash/EEPROM/etc - она может быть запрограммирована средствами микросхемы 1892КП1Я. Предоставляется утилита MCPROG, которая связывается с микросхемой 1892КП1Я по JTAG (с помощью нашего эмулятора MC-USB-JTAG) и через порт внешней памяти осуществляет запись в эту микросхему. Перечень поддерживаемых типов памяти приведен в документации на MCPROG. Если задействована неподдерживаемая микросхема Flash/EEPROM, можно самостоятельно добавить поддержку микросхемы, так как MCPROG предоставляется в исходниках: https://github.com/Kostroff/mcprog

Как осуществляется конфигурирование таблицы маршрутизации и других настроек коммутатора?

Возможны три варианта:
настройка через UART. Протокол работы по UART приведен в описании управляющего ПО. Вариант является "отладочным" и как правило неудобен в работе на конечном изделии;

настройка бинарного файла управляющего ПО. Для этого предоставляется отдельная утилита SpiNSAW. Скорректированный бинарный файл прошивается в ПЗУ, и с этого момента коммутатор по ресету/включению питания всегда инициализируется с одинаковыми настройками;

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

Вопросы по технической части

Каковы требования к внешнему ПЗУ?

интерфейс статического асинхронного ОЗУ (SRAM);

разрядность шины данных - 8 или 32 бита;

время доступа - не более 1 мкс;

объем - не менее 256 Кбайт (текущая сборка управляющего ПО имеет размер около 40 Кбайт, пока не предвидится существенного увеличения размера файла).

На отладочном модуле MCK-02REM-3U для 1892КП1Я установлена микросхема SPI-флэш. Можно ли прошить управляющее ПО туда? Можно ли заложить SPI-флэш в собственное устройство?

В настоящее время не существует и не запланировано сборки управляющего ПО, рассчитанного на загрузку из SPI-флэш. SPI-флэш заложена в отладочный модуль в расчете на появление такой сборки, но пока данная сборка не запланирована. Поэтому заложить в свое устройство SPI-флэш можно, но только в расчете на далекую перспективу. В ближайшее время работать все равно придется с параллельной флэш на nCS[3].

На отладочном модуле MCK-02REM-3U для 1892КП1Я установлено внешнее ОЗУ. Необходимо ли оно для работы управляющего ПО? Нужно ли ставить его в собственное устройство?

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

Oбеспечит ли коммутатор 1892КП1Я (модуль MCK-02REM-3U) скорость SpaceWire40 Мбит/с?

Да, обеспечит. Согласно ТУ на м/сх, максимальная скорость передачи данных по каналу SpaceWireсоставляет 250 Мбит/с.

Нестандартные вопросы

Есть сеть из 5 устройств. Если одно из устройств перестаёт вычитывать данные из SpaceWire, то тогда вся сеть перестаёт работать. Какие есть варианты восстановления сети для обмена данными с другими устройствами? К микросхеме коммутатора есть доступ по UART.

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

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

Предполагаем два варианта развития событий:

Управление коммутатором при помощи протокола RMAP. Для решения проблемы предлагаем передавать RMAP пакеты перед отправкой данных для коммутатора (до забитого устройства они все равно не дойдут), чтобы убедиться, что требуемый порт не занят. Если выполнять подобную проверку, то можно будет избежать ситуации, когда забиваются все каналы сразу. Также можно будет понять, в каком порту проблема, и устранить её. Таким же способом может быть установлен бит LINK_DISABLED для отключения забитого канала.

Написание собственного ПО для коммутатора.

Можно ли таким образом отключить линк и через UART? Если контролировать заполнение буфера через UART и если буфер заполнен, то после отключения линка через LINK_DISABLED отправленные на этот линк пакеты должны будут отбрасываться?

Да, всё так. Но в случае, если Вы восстановите соединение с нерабочим устройством, скорее всего оно будет снова не готово принимать данные, и при отсылке данных зависание повторится, так как LINK_DISABLED не выполняет процедуру очистки буферов.