Сообщение от AFZ
fatfs там есть, работы с SD картой нет, кейл автор не использует, выдернуть работу с fats можно, а поскольку с твоей стороны описания желаемого api нет - чего писать - я просто не представляю. Где ТЗ?
А тебе не кажется, что использование fatfs (а уж тем более написанной кем-то работы с SD) - это уже использование кубиков?
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Меня вполне устраивает чановский API, в принципе, запустить бы пример от Чана. Просто его сэмплы недописанные - начинаешь смотреть, а там то и дело "// здесь надо преобразовать то-то в то-то".
Под кубиками я подразумеваю STM32CubeMX с его кривыми, как бумеранг, драйверами HAL. Сильно не хочется воевать с ошибками этого HAL'а вместо собственных...
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Великое дело сделали. Причешете... Всё хорошо будет
Тады ой! (с) То есть из моего проекта ты выходишь? Ладно, придется собрать FATFS из кубиков, оно, вроде-бы, как-то работает. Коряво, конечно, но для сельской местности сойдет!..
Только учти, что FPGA - это, конечно, круто, но воевать с писюшной ФС ты на нем конкретно устанешь, а ерунда по типу WD, когда непонятно, что делать с полученным диском на писюке - это несерьезно. Диск PDP-11 на писюшном носителе должен быть файлом в писюшной ФС. Согласись, круто, когда сделал в эмуляторе что-то работающее, залил файл-образ диска из под этого эмулятора на носитель для PDP-11, включил, и оно работает. Я тут почитал, с каким геморроем народ разбирается с теми самыми WD...
Так, что правильным решением будет все-таки ставить туда какой-то МК, на котором соберётся FATFS, а на FPGA делать только интерфейс между МПИ и этим МК. Это, конечно, идеальный вариант.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Вообще то - не собирался. Одно другому не мешает, да и начнётся мой проект даже не через месяц. Как я уже писал - трудно заниматься железом без осциллографа.
Просто я действительно пока не понимаю, чем могу сейчас помочь. Написать код-пример работы с файлом с использованием API из FATFS? Готековская прошивка - весьма неплохой и уже готовый пример. Единственно но - автор не использует Keil. Но смотреть пример работы с FATFS это не должно помешать.
Кто сказал, что воевать с ФС будет FPGA? В том то и прелесть FPGA, что на нём можно собрать ЧТО УГОДНО.
Может, кому и не понятно, но у меня проблем это не вызывало. Ибо есть эмулятор PDP и не один. Но авторы WD реализовали одну "ценную" вещь. С этого всё и завертелось.
У меня не WD, а WQ, в котором авторы НЕ сделали одну очень "ценную вещь" - таблицу разделов. Всё. (почти) Все проблемы по работе с носителем на PC решены. Ибо, как я уже писал - есть эмуляторы.
На МК есть только одна полезная вещь. Пакет FATFS, показывающий - как работать с FAT или FAT32. И то, только потому, что Windows на PC (!!) умеет работать с FAT или FAT32 системой. В остальном МК бесполезен.
И да, я почитал, с каким трудом рождается интерфейс обмена инфы между PDP и МК. Потому что то, что надо - на МК нет, а то что есть - по большей части не надо.
Автор PDP-2011, конечно, не реализовал поддержку на SD карте файловой системой, зато он показал - как SD карта может прикидываться другим устройством, о котором знает PDP. Так что теперь можно делать аналоги любых родных для PDP (или их аналогов) устройств - с точностью до работы контроллеров. Осталось только сделать удобной работу с SD картой для Windows на PC. Мысли на этот счёт есть. Времени свободного мало. И мышление с программистского на железячное надо научиться переключать. Подвижки есть
А потом набраться знаний - и избавиться от МК
Тогда все замечательно.
Да, конечно. Только вот большинство народа пользуется именно виндой. Впрочем, линюхи ведь тоже умеют работать с ФАТами. Ну, и главное - это то, что SD-шки изначально идут с ФАТом.
Нет, конечно, там вполне можно прописать еще один процессор PDP-11. Только вот соберется ли под него FATFS ? Свежих Си под него ведь нет...
Да ничего особо сложного нет. Да, Кейл генерит не очень хороший код, который не успевает правильно поймать адрес в момент перехода К СИА Н из высокого в низкий. Можно было бы написать это дело на асме, но я плюнул и поймал это дело аппаратно - всего три м/с, довесок так сказать. После чего все заработало в лучшем виде. Я еще планировал делать аппаратную "заглушку" на тему ДПНМ, но сегодня почитал про внешние прерывания STM32 и спокойно сделал эту заглушку софтово. Завтра с утреца напишу еще кусочек, может успею сделать чтение с псевдодиска.
Угу. Посмотрел. Что-то там до фига всякого, вникать в это совершенно не хочется. К тому же SD-шка там, вроде-бы, подключена по SPI, а мне хотелось бы по SDIO, хот это и некритично. Если бы ты выдрал и прислал мне готовый кусок для работы с FATFS, это бы мне помогло.
К тому же есть еще один аспект, про который пока не вспоминали. Ограниченное количество записей на SD-шку. Пусти простое копирование под RT-11 и посчитай, сколько раз там переписывается оглавление. Такими темпами ресурс SD-шкиной флеши будет съеден очень быстро. Поэтому очень бы желательно организовать кэширование с отложенной записью, это сразу сократит количество перезаписей оглавлений раз в 10. Для этого, правда, придется приделать к контроллеру какой-то источник питания - батарейку, или ионистор, чтобы при выключении ДВК-шника успеть сбросить кэши.
Да и еще есть о чем подумать...
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
А можно - и не PDP-11
Ок, постараюсь - быстро только не обещаю...
Докладываю. Макет, вроде-бы, работает. Осталось сделать обработку ошибок, пока у меня по каждой обнаруженной ошибке программа зацикливает на отдельном while(1); дальше смотрю в отладчике. Кое-что еще не совсем гладко, опять же, и уровень HD минимальный, но все это решается программированием, аппаратура, вроде-бы, устаканилась. Я, правда, еще не сделал прерывание, но, вроде-бы, с этим особых проблем не должно быть и дополнительной аппаратуры, вроде-бы, не надо.
Как мне кажется, можно уже потихоньку начинать проектировать печатку. Мне кажется, что печатка будет не очень сложной и ее можно будет развести так, чтобы плату можно было сделать не только на заводе, но и лазерным утюгом. Впрочем, как получится.
Да, FATFS я таки собрал из кубиков. Тоже не все еще понятно, но, вроде-бы, работает. Только вот выяснилось, что эта FATFS жрет ресурсы МК, как свинья помои! То есть, по-хорошему, надо бы сменить МК. И F407 в этом свете выглядит очень приличным решением. Так, что можно не жалеть о сборке проекта из кубиков - делать для 407-го что-то, помимо кубиков, это закат Солнца вручную!..
Теперь пора заняться драйвером, а то сочинять для каждого движения отдельный тест, а потом набирать его вручную, весьма утомительно. Остаток этой недели, вероятно, передохну, а потом займусь драйвером.
Patron, как, будем считать это устройство разновидностью HD или нет? Мне сменить адрес особых проблем нет - он у меня в одном месте. На мой взгляд, HD изначально планировалось, как устройство с ПДП, так пусть оно таким и останется. А моё устройство в эту идеологию ни разу не вписывается и тянуть его за уши в один ряд с HD, ИМХО, не стоит.
Назову его, допустим, HZ (H - это от Host-based или HFS-based, а Z - понятно...), адрес/вектор сообразим. Некоторое же время спустя, если энтузиазм не иссякнет, можно будет продолжить эту разработку, используя ПДП, тогда можно будет вернуться к идее аппаратной реализации устройства HD.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Угу, пока оно не горит. На "прям сейчас" у меня есть заглушка, потом соберу из кубиков, как получится, ну а заполируем с тем, что ты пришлешь.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
А я основательно продвинулся. Написал всё для минимального набора команд HD T4. Добавил две команды: RDbuf = 015 и WRbuf = 016. По команде RDbuf с адреса 177722 последовательно выдаются все 256 слов блока. По команде WRbuf данные, записываемые в 177722, последовательно заносятся в буфер. Команды CmdRea и CmdWri запускают операции чтения и записи, при записи остаток буфера будет заполнен нулями. Если в буфер ничего не заносилось, запишется целый сектор нулей. То есть, заполненность буфера определяется по последнему сеансу записи в него (WRbuf).
И даже отладил чтение. В процессе отладки нашел одну ошибку у себя в программе МК и целых 4 в тестовой программе на ДВК - я ее писал на скорую руку, да и отвык я программировать на Макро-11...
Кстати, оценил скорость чтения SD-карты. У меня в тесте был свободен R5, так я сделал ожидание чтения следующим образом.
Так вот, после окончания ожидания в R5 оказалось число 077703, разница 074 (60). Получается, этот цикл выполнился 60 раз, и сектор был прочитан в буфер. Т.е. выполнилось 240 циклов шины. Передача сектора из буфера контроллера в память ДВК займет минимум 256 х 3 = 768 циклов шины. Видно, что SD-шка читается быстро, но не мгновенно. И имеет смысл поработать на тему совмещения времени чтения SD-шки и передачи, т.е. один сектор прочитали и передаем, а второй в это время читается во второй буфер.Код:MOV #77777,R5 MOV #CmdRea,@R0 ; передать команду чтения сектора 1$: DEC R5 TSTB @R0 BPL 1$
Но это потом. Сейчас буду отлаживать запись, потом настанет время заняться драйвером (если, конечно, Патрон не подкинет готовый), потом займусь подчисткой хвостов, и только после этого можно будет думать об улучшении...
- - - Добавлено - - -
Да, а еще надо заняться прерываниями. Надеюсь, что прерывание у меня получится без аппаратных "довесков". Но продвижение по-любому весьма заметное...
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
