Ведь всё равно скорее всего же нет такого оборудования, которое требует моментальной реакции на прерывание да сохранения-обработки полученных данных, а для копирования образов или отдельных файлов - просто шикарно :v2_dizzy_snowball:
Ведь всё равно скорее всего же нет такого оборудования, которое требует моментальной реакции на прерывание да сохранения-обработки полученных данных, а для копирования образов или отдельных файлов - просто шикарно :v2_dizzy_snowball:
А не суть важно. Оно исполняется на системном уровне при открытых прерываниях, приоритет выше, чем у всех заданий, но прерывания открыты. Примерно там же, где и .FORK.Цитата:
Сообщение от Alex
Докладываю. Добился безукоризненной работы контроллера в варианте без прерываний. Заглушку сделал аппаратную, 3 м/с: селектор адресов 177730-177736 (2764), регистр выбора контроллера по МПИ и младших битов адреса (1533ИР22) и логика сигналов выбора и выдачи К СИП Н (1533ЛЛ1, все 4 элемента). Когда подключил эту заглушку, обнаружилась ошибка в программе основного МК - я выдавал с него сигнал "Думаю, прошу не мешать" в произвольный момент времени, заглушка отключалась мгновенно (десяток-другой НС), если в это время проходит фронт (вернее, спад) К СИА Н и я его, естественно, пропускаю, итого - trap to 4. Дождался высокого уровня на К СИА Н и только после этого снял ДПНМ, и все заработало, как часы. В варианте с заглушкой на F103C8T6 заглушка отключалась долго, в результате trap to 4 возникал изредка и я грешил на общее несовершенство мира, а надо было искать ошибку в программе. :)
Работает очень шустро. Файл 5000 блоков с AZ0: на AZ1: копируется 44 сек, на NL: - 18 сек. Это раза в три (навскидку) быстрее, чем DW: и, вроде-бы, в 1.5 раза быстрее, чем WQ:
Сейчас размышляю на тему прерываний. Программно на STM32 это точно не получится, опять же нужен аппаратный довесок, опять огород в 3-4 м/с. Варианты:
1. Плюнуть и обойтись без прерываний.
2. Сделать это дело на рассыпухе.
3. Сделать это дело на ПЛИС.
Первый вариант, в общем-то, не так и плох. Прерывания во время прополки контроллера открыты, так, что потерь быть, вроде-бы, не должно. Конечно, если в оперативном разделе FB/XM монитора запустить копирование внутри SD-шки, то фоновый раздел ляжет, но так, обычно, не делают. Для больших систем (RSX, TSX, конечно, будет похуже, но тоже не очень критично - не системным диском единым жива операционка, да и Time Sharing никто не отменял...
Второй - понятно. Огород. Сильно не хочется.
Третий. Большие ПЛИС я еще не освоил. Вроде бы, разобрался с GAL/ATF, но нет в жизни счастья - простым GAL16V8 и GAL22V10 не хватает ног и логических возможностей, чтобы запихнуть всё это, вместе с заглушкой, в одну м/с. Им даже на одну заглушку ног не хватает. Правда, двух ГАЛок на заглушку хватит, а на 3-й даже и контроллер прерываний можно, вроде-бы, сбацать, но три м/с - это тоже, в общем-то, огород. Да еще и ГАЛки как вылетели из страны отправления, так и (если верить отслеживанию Али) зависли где-то в воздухе... :)
В принципе, может быть, все запихнется в две ГАЛки, если одна из них будет GAL6001D, но TL866, к которому у меня есть доступ, их не шьет, в отличие от первых двух.
В общем, пока думаю...
form, я тут начал заниматься прерываниями, и обнаружил проблему. У меня в процессе обмена с SD-шкой контроллер занят, и работает аппаратная заглушка "Думаю, прошу не мешать". Пока она у меня на рассыпухе, и у меня получилось сделать ее только на чтение CSR. Делать еще и запись - большой огород. Нет, когда приползут с Али ГАЛки, скорее всего, справлюсь, но они уже месяц, как ползут и, думаю, еще будут ползти с месяц. Так вот, при нормальной работе это по барабану - кончится длинная операция, придет прерывание, и все ОК. А вот при отмене текущей операции будет лажа - надо снять бит разрешения прерываний от моего контроллера, а CSR недоступен.
Я так мыслю, что мне в точке входа отмены операции надо будет подождать, пока контроллер завершит текущую операцию и снять бит разрешения прерываний. Но это место исполняется при открытых прерываниях и, если я буду дожидаться подключения CSR на запись, то ничего не успею сделать - прерывание произойдет сразу же, и черт его знает, что там сделается. ИМХО, проще всего, закрыть прерывания на время этого ожидания. Это, в общем-то, ИМХО, не фатально - аварийные завершения происходят достаточно редко. На ДВК все просто: MTPS #200, и вперед (у моей железки будет IRQ4). А если процессор "взрослый", без PSW на шине?
Внимание, вопрос: как в драйвере процессорно-независимо закрыть прерывания. Помню, на эту тему, вроде-бы что-то было, но подробности давно улетучились, а беглый поиск не помог.
Самое простое - использовать макрокоманду .MTPS - она, не трогая регистров, вызывает подпрограмму которая или делает MTPS, или MOV ...,@#PS (код патчится во время загрузки).Цитата:
Сообщение от AFZ
Если критичны пара MOV и один JSR перед собственно командой - можно патчить код драйвера при загрузке (работает только в 5.2 и новее), опираясь на бит LSI$ в слове $CONFG в RMON.
Как вариант, просто использовать команду MTPS, забив за процы где ее нет (навскидку мне известен только один такой - Э100/25).
Если только Э-100/25, то, скорее всего, забью. Она же UNIBUS-ная? А мой контроллер только под МПИ/Q-Bus, вряд ли я стану его переделывать под UNIBUS.Цитата:
Сообщение от form
Да.Цитата:
Сообщение от AFZ
Собственно насчет MTPS/MFPS в Э100/25 уверен не на 100%, но на 99% - память подсказывает, что я проверял, но времени много прошло. Ну а в описании команд процессора точно нету.
В любом случае если где еще нету - это наверняка все UNIBUS машины.
Команда MTPS в отличие от MOV ...,@#PS не работает в пользовательском режиме, но для драйвера это неактуально: он всегда в KM работает.
Пока ГАЛки машут крылышками :) (я же говорил, что они вылетели из Китая и где-то зависли), решил сделать прерывания на 559ВН1. Достал из кладовки м/с, достал панельку, достал макетку, примерился и сел рисовать в любимом Оркаде DC003. Нарисовал, пригляделся к ней внимательнее и ужаснулся: у DC003 18 ног, а у ВН1 - 20!
Срочно полез искать что-нибудь, нашел 5-й том Нефедова, подписал на DC003 ножки ВН1, потом перешел на следующую страницу Нефедова и увидел, что ноги 10 и 11 не подключены! То есть, у тех наших ребят, которые цельно тянули DC003, в номенклатуре не оказалось 18-ногого кузова и они, по-простому, запихали этот кристалл в 20-ногий, бросив ноги 10 и 11, я правильно понял? Нефедов в этом месте не ошибается?
Ну, вот и все. Работа с железом по этому проекту закончена. На макете. Схема готова, плату будет разводить и заказывать наш коллега СуперМакс. Делать будем для МПИ, Для Q-Bus, желательно, сначала попробовать на макетке. Ну, или, когда оно у нас пойдет в МПИ-варианте, то воткнуть его через переходник Q-Bus-МПИ.
С самого начала мы собирались работать над проектом втроем: я, Хунта и СуперМакс: я сочиняю схему и программную часть работы с МПИ/Q-Bus, Хунта - программную часть работы с микро-SD, Макс по моей схеме делает плату. Увы, Хунта из нашего проекта вышел - нашел себе занятие поинтереснее, с FPGA. Поэтому работа с файл-образами на карточке осталась в минимальном варианте - два файла на одной карточке (два псевдодиска, AZ0: и AZ1: ), никаких динамических переназначений, имена файл-образов псевдодисков жестко прописаны в программе микроконтроллера. Впрочем, всё это никак не завязано на железо, соответствующая часть программы легко может быть дописана/переписана и заменена прямо на готовой плате.
Прерывания "в железе" я так и не проверил - макет весь опутан проводами, с ним стало тяжело работать. Лезть подпаивать новые провода к макетке, рискуя что-нибудь оторвать - никакого желания. А теоретически - 559ВН1 aka DC-003 подключена по стандартной схеме, все должно работать.
У меня есть 5 макеток Q-Bus буржуйского покроя.Цитата:
Сообщение от AFZ