Контроллер дисковода для УКНЦ, работающий с образами на micro-SD карте.

[AFZ]

Люди, я бы все-таки обратил внимание не на HX, а на HD.

Управлять подключением образов к приводам контроллера со стороны ДВК практически нереально.

Почему? Передаем через .spfun (другой, не 373) строчку с именем файла, и вперед. Перед этим, пользуя в цикле третий .spfun со значением "получить очередную строку списка файлов на карте", можно будет получить оглавление этой CF-ки. А потом спокойно пишите программу СFMO[unt], хоть простую утилиту командной строки, хоть нечто, подобное Командиру Нортону. Единственное, что не выйдет - перемонтировать системный диск, система такого, естественно, не переживет.

что делать с еще не инициализированными томами-файлами

Ничего делать не надо. Если файл есть и его подключили, то надо определить его размер и возвращать этот размер системе, причем следует учитывать, что RT-11 не понимает дисков более, чем с 65535 блоками, но, в то же время, кроме RT-11 есть и другие операционки, которым доступно больше, чем 32М дискового пространства. Впрочем, это легко решается в обработчике .SPFUN 373 драйвера RT-11: если размер файла более 32М, возвращаем 65535, и вперед. Разбивать большие файлы на несколько томов RT-11, ИМХО, не имеет смысла - никто не мешает сделать файлы CF требуемого размера и не морочить голову.

Единственное, что может понадобиться, если вдруг решим дополнить программу CFMO дополнительным функционалом в виде создания нового файл-образа, типа "вставить новый пустой диск" - вот здесь придется давать, кроме имени для нового файла, еще и его размер (в блоках), причем в версии для RT-11 не более 65535 блоков, для других ОС ограничение снимается, но это будет (если будет) делаться средствами тех самых "других" ОС.

[Advertiser]

[Patron]

Люди, я бы все-таки обратил внимание не на HX, а на HD.

Существенное отличие HD и HX в том, что в HD передача параметров команды и кода команды выглядит так:

UNIT NUMBER -> DATA
Команда SET UNIT NUMBER -> CSR
BLOCK NUMBER -> DATA
Команда SET BLOCK NUMBER -> CSR
WORD COUNT -> DATA
Команда SET WORD COUNT -> CSR
Команда READ -> CSR

а в HX передача команды и её параметров выглядит так:

Команда READ -> DATA
UNIT NUMBER -> DATA
BLOCK NUMBER -> DATA
WORD COUNT -> DATA

[AFZ]

Так вот, пока все хорошо, вариант HX без вопросов. Однако, при каких-либо нарушениях, вариант HX становится уязвимым к разным косякам, которые должны исправляться на уровне протокола, в то время, как вариант HD к этому нечувствителен. Элементарно: идет обмен с "диском", что-то сбойнуло, машинка вылетела в останов. Я в таких случаях давил на ДВК букву G, которая без предшествующей цифры интерпретируется, как 0G, RT-11SJ благополучно перезапускалась, и вперед. И не поймешь, что там дальше будет... А так - все четко: команду толкаем в одно место, данные в другое. И выданная команда обязана отменить всю предыдущую незавершенку и привести контроллер в правильное состояние.

[Patron]

Jarik65535 чётко сказал, что отмена незавершёнки не предусмотрена. Программно сбросить контроллер в начальное состояние невозможно. Сигнал INIT на шине также его не сбросит. Уж если контроллер начал приём или передачу пакета, то не вернётся в начальное состояние до завершения работы. Поэтому полезно иметь в CSR не только бит READY ( 0200 ), но и бит DONE ( 0400 ), устанавливаемый контроллером в фазе ожидания кода команды.

- - - Добавлено - - -

Я понимаю ситуацию так. Допустим, у контроллера есть команда "СООБЩИТЬ КОЛИЧЕСТВО ОБРАЗОВ НА КАРТЕ", в ответ на которую он помещает в регистр DATA соответствующее число. После записи кода этой команды в регистр данных - контроллер снимает биты READY и DONE, пересчитывает образы на карте, устанавливает бит READY и ожидает чтения регистра данных, чтобы передать количество образов. Если в этот момент попытаться записать в регистр данных код новой команды, то контроллер никак не отреагирует, потому что для завершения цикла выполнения команды ему надо передать клиенту все слова пакета. И хотя пакет в данном случае состоит всего из одного слова - контроллер не перейдёт в начальное состояние, пока это слово не передаст.

[AFZ]

Jarik65535 чётко сказал, что отмена незавершёнки не предусмотрена. Программно сбросить контроллер в начальное состояние невозможно.

Не думаю, что все так категорично. Если средствами той ПЛИС можно сделать хотя бы один триггер, устанавливаемый в произвольное время со стороны ЦП с возможностью чтения и сброса его через GPIO контроллера, то вопрос решается. То есть, возможно, в текущей реализации это и не предусмотрено, но оно нужно. И, как я понял Ярослава, вроде-бы реализуемо.

- - - Добавлено - - -

Более того, я тут прикинул, похоже и триггер этот не нужен - достаточно в тот самый "короткий" цикл обмена с ЦП добавить проверку адреса - с РД общается ЦП, или с РС и по записи в РС сбрасывать "незавершёнку". То есть достаточно незначительного усложнения программы контроллера.

[Jarik65535]

А в чем проблема подождать пару миллисекунд? У нас объем данных не превышает 64К. Кроме того старший байт CSR используется в контроллере СА для получения номера станции, так что можно использовать другой бит. Еще всегда, (когда готов) контроллер можно перевести в исходное состояние, записав 4 в CSR, что делает штатный УКНЦшный загрузчик из сети.

[Patron]

А в чем проблема подождать пару миллисекунд? У нас объем данных не превышает 64К.

Имеется в виду, что если сбой произошёл в драйвере во время обмена с контроллером и синхронизация с контроллером потеряна - восстановить её без сброса контроллера невозможно. Во всех остальных случаях бит DONE решает все проблемы. Например, драйвер заказал запись 1024 слов, начиная с последнего блока диска - тогда после загрузки в контроллер количества слов - тот выставляет бит ERROR, но не выставляет бит DONE, что означает ситуацию: "частичное выполнение команды". Затем контроллер принимает от драйвера 256 слов и выставляет бит DONE, хотя драйвер заказывал запись 1024 слов. Теперь в CSR установлены биты ERROR и DONE, что означает: "досрочное завершение выполнения". Если перед каждым обращением к регистру данных драйвер проверяет биты READY и DONE в CSR - он никогда не потеряет синхронизацию.

[AFZ]

Еще всегда, (когда готов) контроллер можно перевести в исходное состояние, записав 4 в CSR, что делает штатный УКНЦшный загрузчик из сети.

А когда неготов? По-хорошему, нужно принимать этот бит всегда, выставили его, дождались готовности, и начинаем работу сначала. То есть, после какого-либо сбоя (а может и вообще, первым действием) приводим контроллер этой командой в начальное состояние.

[Jarik65535]

А когда неготов? По-хорошему, нужно принимать этот бит всегда, выставили его, дождались готовности, и начинаем работу сначала. То есть, после какого-либо сбоя (а может и вообще, первым действием) приводим контроллер этой командой в начальное состояние.

А когда не готов - получим зависание. И если кортекс зависнет, то вывести можно будет только выключением питания. Просторы для фантазии не ограничены, в отличии от ресурсов и возможностей PSoC4, всегда приходится чем-то жертвовать, ну нельзя сделать аппаратный сброс контроллера через запись в его же регистр, здесь все-таки софтварная эмуляция работы с шиной.

[AFZ]

А когда не готов - получим зависание.

Ладно, это не особенно важно. А нельзя добавить сигнал управления шинными драйверами, чтобы прикрутить это дело к ДВК? Этот самый CY8CKIT-049 у меня есть, возьму четверку 589АП16, и вперед! Как я понимаю, драйверы должны будут всегда включены на передачу от шины к контроллеру, а в момент, когда контроллер соберется переключить свои GPIO на вывод, т.е. на выдачу данных в шину, надо будет перед этим выдать этот самый сигнал переключения.