Железяку я таки сделал. В смысле, макет. Теперь осталось сочинить в нее софтину. Фирмварь, так сказать... Уффф! Больше я такими делами заниматься не буду - не с моим зрением собирать сложные железяки.
Вот так выглядит готовая железяка:
А так - она же с подключенной китайской пробной платой с МК.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Ратмир(31.10.2022)
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Ну вот, дело основательно сдвинулось. Докладываю.
Во-первых, надежда обработать цикл МПИ полностью программно не состоялась. Не зря Vslav в свой РЕ-мулятор поставил 120-МГц STM32F205 и программу для него написал на асме. Нет, может быть, если писать на асме, то, скорее всего, и F103 с его 72 МГц справится, но писать под STM-ки на асме - это слишком круто! А Си там такого нагенерил (я смотрел), что неудивительно: переход К СИА Н из высокого уровня в низкий правильно поймать невозможно - адрес, который следует зафиксировать по этому сигналу ловится крайне ненадёжно! Тогда я поступил по-простому: сделал для этого адреса аппаратную ловушку. Она ловит факт выбора моей платы - обращение по адресу 17772х, принимает этот факт выбора и биты этого "х" в 1533ИР22 и выдает все это в мой МК. Пока я еще не прикрутил аппаратный ответ "думаю, прошу не мешать", но это одна ЛА4-я, как припрёт, прикручу.
В общем, концептуально проект состоялся - обмен данными с МПИ работает в лучшем виде. Я даже уже прикрутил механизм передачи начального загрузчика, передает всё, что захочешь. СамогО загрузчика, правда, еще нет, вместо него передается демонстрашка. Вот:
Теперь надо двигаться дальше. Во-первых, нужна правильная работа с микро-SD-шкой. Это, помнится, грозился сделать Хунта. Во-вторых, надо согласовать регистры и порядок работы контроллера. Это собирался сделать Патрон, и сделал, но не совсем то, что у меня получается. Ну, и нужен драйвер для RT-11. Сделать железо под те 5 вариантов драйвера, которые сделал Патрон, я пока не могу, надо вносить изменения. И их очень желательно согласовать. (Патрон, ау!) Ну, и внести в эмулятор, чтобы железо соответствовало эмулятору.Код:173000 @177724G This code recieved from STM32 010032 @
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Ну, на самом деле это сделано уже (только адаптировать) в прошивке-эмуляторе кучи флопов для Готека. Взять и адаптировать.Сообщение от AFZ
Для этого было бы полезно иметь описание формата регистров и порядка работы получившегося железа.
2 Patron
Да, в общем-то, пока все свободно. Есть 3 регистра - 177720 -177724. Последний - для загрузки. Команда 177724G запускает передачу загрузчика, по окончании которой передает ему управление. Размер загрузчика, в общем-то, неограничен, в МК он представлен набором hex-констант. Есть недоделанная программа, которая конвертит .SAV-файл в этот набор констант.
Остальные два регистра доступны для записи и чтения. И запись, и чтение, кроме непосредственной передачи слова данных между МПИ и МК могут инициировать какое-то действие. Если действие короткое, оно выполняется немедленно, т.е. во время этого самого текущего цикла МПИ. Долгое действие (больше тайм-аута МПИ) переводит контроллер со стороны МПИ в состояние "Думаю, прошу не мешать". Окончание этого действия может вызвать прерывание.
В общем, чистый PIO-mode с прерываниями.
Как я понимаю, на этот базис почти ложатся HD V4 и V5. Но не совсем, поскольку ни один из них не знаком с концепцией блоков. А надо, поскольку мне для безблочных манипуляций с данными не хватает ресурсов МК. Ниже изложено моё видение обмена с псевдодиском в блочном варианте.
К числу длительных действий относятся:
- чтение первого слова блока. Ну, или, как вариант, передача команды "прочитать блок в буфер", после которой по отдельной команде "читать содержимое буфера" можно быстро передавать данные из буфера на МПИ. При этом, недочитанную ненужную часть блока можно просто бросить.
- запись последнего слова блока в буфер. Как вариант, подача команды "записать содержимое буфера на носитель", тогда заполнение буфера надо делать по отдельной команде, которая будет быстрой. Мне этот раздельный вариант нравится больше - очистку остатка блока при неполном блоке можно перенести на МК. Помню, какие сложности вызывала эта очистка в драйвере, а так, заполнил ту часть блока на которую есть данные (неважно, полный блок, или нет), дал команду "пиши", и МК сам очистит остаток блока, буде таковой найдется.
- разнообразные управляющие действия, типа смонтировать на привод HDx новый файл-образ, передать список файлов на хост-носителе и т.п. Да, подавать в качестве одного из HDx папку файловой системы хост-носителя, как это сделано на HD1 в эмуляторе, я пока не готов. Не справлюсь. Может быть когда-нибудь позже...
-----------------------------------------------------------
2 Hunta Ну, если оно готово, присылай. Собственно, мне нужны возможности открыть файл, читать/писать его, да небольшая работа с оглавлениями, типа findfirst/findnext. И, вроде-бы, твой Готек собран на F103 ? Тогда вообще идеально - оно ляжет на мой F103ZET6, практически, без переделки.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Видимо, я не точно выразился. Я не имел ввиду, что я написал, я имел ввиду проект
https://github.com/keirf/FlashFloppy
в котором используется стандартная библиотека fatfs для работы с FAT32, а сам проект можно использовать как пример работы с ней.
Врят ли я напишу за приемлемое время что то лучшее, чем эта библиотека, да и смысле ещё раз реализовывать то же самое как бы нет.
Patron, а где указать эмулятору, чтобы он использовал HD V4 или V5 ?
И еще. Я правильно понимаю, что если я добавлю в драйвер HD V4 и V5 в циклы чтения и записи ожидание бита готовности (0200) перед каждым принимаемым/передаваемым словом, то оно должно работать в эмуляторе? Это я к тому, что слона надо есть по кусочкам - сначала V4 в простейшем PIO-mode, а когда заработает, буду двигаться дальше. Оно, конечно, неэффективно (лишние две команды в цикле передачи данных, который мог бы быть на эти две команды короче, но это требуется вмешательство в эмулятор), но для начала сойдет. Поскольку отлаживать одновременно и железо (точнее, софт в МК), и драйвер, это сложнее не вдвое, а больше.
- - - Добавлено - - -
Нет, конечно, я понимаю, что в рамках V4/V5 тоже можно организовать поблочную работу - аккуратно отсчитывать заполнение блоков и делать ожидание только в момент окончания очередного блока, в том числе, для V5 ждать прерывания, но это солидное усложнение драйвера, а я основательно подзабыл приёмы драйверописательства для RT-11, и сейчас заниматься еще и этим как-то не с руки.
А отлаживать драйвер одновременно с железом на ДВК, как новое устройство - так у меня на ДВК-шнике, кроме моей железки, ничего нет, не через HX же гонять MACRO с LINK'ом? То есть, конечно, можно все сгенерить в эмуляторе, засунуть драйвер в HX.DSK, или как там его, загрузить ДВК с HX и пробовать. В крайнем случае так и сделаю...
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
При эмуляции тип эмулируемого контролера HD задаётся "секретным" параметром: HD_InterfaceType в разделе HD.ini. Значение по умолчанию HD_InterfaceType = 2 соответствует обычному контроллеру HD.
Нет, цитирую описание:Имитировать "безблочную" работу так не получится - надо делать в эмуляторе новое устройство.После подачи команды записи - контроллер снимает флаг READY ( 0200 ) и в регистр данных нужно (без каких-либо других обращений) записать количество слов, равное текущему значению "СЧЁТЧИК СЛОВ", после чего контроллер снимает флаг NO.DMA и выполняет запись. Завершение записи приводит к установке в CSR флагов READY и NO.DMA.
На мой взгляд - сначала надо детально продумать работу "блочного" контроллера (всем миром), потом добавить такой контроллер в эмулятор и написать для него драйвер (это я сделаю).
Например - в любой из фаз работы контроллера операционка может вылететь и запустить начальный загрузчик. Как начальный загрузчик выполнит сброс контроллера на любой из фаз его работы, сколько времени это займёт, нужно ли начальному загрузчику ждать готовности контролера после сброса или при неготовности контроллера после сброса - завершить работу с выдачей сообщения, чтобы пользователь сам дождался завершения сброса контроллера и перезапустил начальный загрузчик.
Недоглядел. Жаль, я бы уже начал.
В смысле, блочную...
ОК. Думаем. Мне больше импонирует, так сказать, "раздельное заряжание". То есть, при записи подаем отдельную команду "принять с МПИ в буфер", передаем без ожиданий любое количесво слов от 1 до 256 включительно, затем даем команду "писать на СД", и контроллер запишет это дело по заданному адресу, с отключением и переходом в состояние "Думаю, прошу не мешать". Ну, и при чтении - даем команду "читать с СД в буфер", контроллер, опять же, отключится, прочитает блок с СД-шки, подключится снова, выдаст прерывание, и, получив команду "передать содержимое буфера на МПИ" быстренько передаст прочитанное.
Я, конечно, не настаиваю, но, ИМХО, так будет лучше.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Я и не хочу, чтобы ты писал что-то своё. Мне нужен готовый проект с faffs, который без плясок с бубном собирается в Кейле и из которого можно выдернуть работу с fatfs и SD-картой. И желательно, чтобы оно не было собрано из кубиков.
- - - Добавлено - - -
Ладно, у меня пока есть небольшая заглушка, которую можно использовать для отладки, а потом разберемся и с FATFS.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
