Эмулятор ДВК

[Patron]

Ярослав (Jarik65535) сочиняет контроллер карточек микро-SD на системную шину УКНЦ. Я посоветовал делать интерфейс с системой "по мотивам" HD

Если делать с прерываниями и DMA, то лучше придумать новый аппаратный интерфейс ( контроллер SD ) "по мотивам" контроллера MY. Из команд оставить только ЧТЕНИЕ, ЗАПИСЬ, ЗАГРУЗКА, НАСТРОЙКА, РАЗМЕР и СОСТОЯНИЕ, а в блоке параметров передавать не головка-сектор-цилиндр, а сразу номер блока ( как в HD ).

Обсудите все тонкости такого интерфейса ( особенно если есть желание адресовать на диске более 64 К блоков ), после чего я могу добавить устройство SD в эмулятор ДВК.

[form]

"по мотивам" контроллера MY

Добавлю, что лучше не по мотивам MY, а с набором регистров через которые передаются все параметры для операции, которые можно читать, в которых счетчик слов убывает в процессе выполнения, а адрес диска и памяти растет. Это упростит реализацию и позволит выполнять последовательные однотипные операции просто установкой одного бита GO в CSR.

[Patron]

Добавлю, что лучше не по мотивам MY, а с набором регистров через которые передаются все параметры для операции, которые можно читать, в которых счетчик слов убывает в процессе выполнения, а адрес диска и памяти растет. Это упростит реализацию и позволит выполнять последовательные однотипные операции просто установкой одного бита GO в CSR.

Тогда можно просто разместить блок параметров "в стиле" MY сразу после регистра данных контроллера - в результате адрес этого блока не надо будет передавать контроллеру при каждой операции, а контроллеру не потребуются циклы DMA для его чтения и записи.

[form]

разместить блок параметров "в стиле" MY сразу после регистра данных контролера

Ну да, это и имел в виду - просто чтобы этот самый блок не таскать взад-вперед по DMA.

[AFZ]

Если делать с прерываниями и DMA

С DMA, скорее всего, будут сложности. ПЛИСка у этих PsOC4 довольно убогая, а DMA у наших машинок, кроме обычных счетчиков адреса и регистров передачи данных (которые легко и непринужденно делаются на GPIO Кортекса-М0 и его внутренних ресурсах), имеет довольно сложную логику. Не факт, что она влезет в эту ПЛИСку.

Тогда можно просто разместить блок параметров "в стиле" MY сразу после регистра данных контроллера

Увы, пока регистры контроллера оказались на адресах 176560-66, поскольку для начальной загрузки штатными средствами УКНЦ контроллер поначалу прикидывается сетевым адаптером. А сразу за ним - стык С2, 176570...

И вообще, мне, как раз, понравилась идея последовательной передачи "задания" контроллеру с прямым указанием компонента, который сейчас передается: дали команду, что передаем дисковый адрес (номер блока) - даем младшее слово номера блока, и т.д. Вместо адресов памяти, скорее всего придется ввести пару команд типа "залить данные в буфер сектора" и "считать данные из буфера сектора". Затем, при записи, после заливки данных сектора в буфер, подадим команду "писать", а при чтении подадим команду "читать", затем будем читать данные из буфера сектора, вестимо, в PIO-mode. Естественно, для сигнализации о завершении сравнительно длительных операций - передачи туда-сюда между карточкой и буфером сектора, будут задействованы прерывания, а что касается обмена между основной памятью и буфером сектора, так PIO-mode на FORK-уровне RT-11, ИМХО, самое то.

[form]

С DMA, скорее всего, будут сложности.

Тогда тем более делать все параметры в регистрах. А DMA - и фиг с ним - достаточно чтобы были прерывания, говорящие о том, что очередное слово готово к чтению контроллером или для чтения из контроллера.

[Jarik65535]

А сильно ли нужны эти прерывания? Просто RT11 обычно не сильно многозадачная, а ресурсов PSoC4 вряд ли хватит. Сейчас уже реализован доступный по чтению регистр с флагом готовности. Ждать нужно будет только во время чтения/записи данных в карту.

[form]

Просто RT11 обычно не сильно многозадачная

Ну во-первых FB/XM/ZM очень даже многозадачные, во-вторых даже в однозадачном RT-11 есть возможность запустить операцию ввода-вывода и продолжать выполнение, не ожидая завершения - как завершится - будет оповещение (или в нужный момент можно дождаться), ну и в-третьих зачем ограничивать себя сразу рамками RT-11?

[AFZ]

А сильно ли нужны эти прерывания?

Я думаю, что ресурсов PSoC хватит. Прерывание ведь инициируется с контроллера, значит его можно делать на Кортексе, а не на ПЛИС. От ПЛИС потребуется только пропустить или не пропустить (в зависимости от какого-нибудь отдельного бита GPIO) через себя сигнал ППР. То есть, если мы не собираемся прерывать, то ставим этот бит в состояние"пропускать" и не вспоминаем о прерываниях вообще, а соберемся прерывать - ставим "не пропускать, после чего Кортексом, через другие GPIO, отрабатываем процедуру прерывания, опять же, в коротком цикле.

Ну во-первых FB/XM/ZM очень даже многозадачные, во-вторых даже в однозадачном RT-11 есть возможность запустить операцию ввода-вывода и продолжать

А в третьих, я таки лелею надежду, что по окончании работ над УКНЦ-шным вариантом его таки удастся доработать для ДВК, а там и RSX работает нормально, и Демос, и ДИАМС...

[Patron]

А сильно ли нужны эти прерывания?

Прерывания очень полезны, но первую версию контроллера можно сделать без них. Чтобы легко отличать версию без прерываний - можно сразу предусмотреть в CSR бит разрешения прерываний 0100, который невозможно установить у версии без прерываний.

Работу с регистрами можно сделать довольно оригинально - задавать номер одного из 8 регистров в битах 010..002 CSR, после чего читать/писать этот регистр через регистр данных, а младший бит CSR использовать для запуска выполнения. Регистр с номером 00 может содержать слово состояния контроллера, а регистр с номером 01 - команду, которая будет выполнена при записи 1 в CSR. Поэтому для выполнения новой команды - надо сначала записать 02 в биты 010..002 CSR ( что откроет доступ к регистру команд через регистр данных ), потом записать код команды в регистр данных и затем установить бит 01 в CSR для выполнения команды. Поскольку этот бит всегда читается нулём - его установка может производиться командой INC.

Обмен данными можно организовать в стиле DW - после начала выполнения команды ЗАПОЛНИТЬ БУФЕР или ОПОРОЖНИТЬ БУФЕР - снимается бит READY в CSR и следующие 256 обращений к регистру данных попадают в 256 последовательных 16-битных ячеек буфера контроллера, причём при заполнении учитываются только циклы записи, а при опорожнении - только циклы чтения. Таким образом можно будет (например) подать команду ЗАПОЛНИТЬ и затем инвертировать содержимое буфера, подав 256 команд COM @#DATA. После 256 учтённых обращений команда завершается и устанавливается бит READY в CSR.

Завершение любой команды приводит к установке бита READY в CSR, очистке в CSR битов номера регистра 010..002 ( т.е. выбору регистра состояний для проекции в регистре данных ) и записи в регистр состояний кода завершения команды.

Запись в CSR при сброшенном бите READY завершает выполнение любой команды на любом этапе. Записанное слово проверяется только на бит 040000, если он установлен - производится обычный сброс контроллера, а если нет - сброс контроллера дополняется записью кода ошибки в регистр состояния 00. Ошибки при выполнении команд отражаются кодом ошибки в регистре 00. Включение питания, INIT шины и установка бита 040000 в CSR - сбрасывают контроллер в начальное состояние с запрещением прерываний, установкой проекции регистра состояний 00 в регистре данных и очисткой кода ошибки в регистре состояний.