Comments 12
Возможно от усталости в данный момент из-за работы эмоции берут выше, но автор молодец. Классная работа. Доступно и интересно! Респект!
Круто! Молодец.
(оффтоп) Название статьи хорошо обыграно, вспомнилось популярное в рыбацких регионах "In Cod We Trust"
Добрался домой с дачи и решил написать развернутый коментарий.
Совсем не понятна мотивация за использование Rust. Компиляторов C/C++ для RV32 как грязи - бери любой (лучше всего от SiFive, у них есть готовый под винду). Но если захотелось чего-то эдакого, то почему бы не написать это на ассемблере ? Ваш проект очень простой, на асм хорошо ложится и это было бы полезно для изучающих архитектуру. Ну да ладно.
Почему модуль note не формирует сигнал ready ? Как драйвер этого усторйства узнает о том, что новая нота успешно детектирована ? Аналогичный вопрос по модулю микрофона. В basic_graphics_music у модуля микрофона нет сигнала ready и это большая беда - это не позволяет верхнему уровню узнать о том, что регистр данных содержит обновленные данные и весь код детектирования ноты очень сомнителен.
Загрузка программы через последовательный порт это круто! Но питоновый скрипт bin2hex здесь лишний, так как утилита objcopy умеет генерировать на выходе IntelHEX и еще много других полезных форматов. Ниже пример из моего проекта:
objcopy -v -O ihex -I binary --set-start 0x80000000 --change-addresses 0x80000000 hello.bin hello.hex
Не понятно зачем была вся эта возня с перекомпиляцией компилятора и атомарными инструкциями на одном ядре в однозадачном приложении ? Зачем Вам здесь понадобились мьютексы ? Если от мьютексов избавиться нельзя, то не проще было бы перегрузить методы lock/unlock или Rust этого не позволяет ?
Аналогичный вопрос: зачем в аллокаторе мьютексы на одном ядре и одном потоке ?
Не понял как сделано выключение нот. Включение вижу, не вижу где отправляется выключение и по какому событию.
Для себя сделал вывод: Rust это язык не для низкоуровнего программирования, так как необходимость в мьютексах (атомарных операциях) очень глубоко сидит в синтаксисе языка. В этом свете мне кажется очень странным решение Торвальдса затягивать Rust в ядро Linux - кто-то должен был его остановить от необдуманных поступков. :-)
PS: В ПЛИСах Gowin GW1NR (платы TangNano) есть большой кусок динамической SDRAM памяти - можно весь видео фрейм-буфер туда вынести.
PPS: А ссылка на репозиторий где ? :-)
В том то и дело что как грязи. Но и SiFve и Syntacore делают компиляторы для своих процессоров и их релизная политика зависит от реализации их собственных продуктов.
Простой проект для изучения архитектуры уже был - https://habr.com/ru/articles/726250/
Это Proof of concept. В перспективе делать на asm работу с MIDI сообщениями? Есть готовые крейты, но у них в зависимостях мьютексы. Достоинство и недостатки пакетной системы с зависимостями в одном флаконе.Тут все просто, особенность инструмента в том что ноты идут подряд, нота меняется старую выключаем, новую включаем. Скорости хватает. Что касается самого фильтра, то на канале подготовки лаб про это много обсуждений было, чем кончилось не помню. Опять же это POC. Возможно возьмусь за эту лабу и сделаю ее лучше.
Загрузка через последовательный порт пришла из проекта MIPSfpga и перенесена в проект YRV-Plus Юрием Панчулом. -O ihex дает не совсем тот результат, необходимый для загрузки, ток что все равно какой-то скрипт нужен. Ну и так как YRV бывает с шиной в 16 и в 32 бита то проще две прошивки делать.
Никакой перекомпиляции компилятора не было, я добавил две инструкции в ядро процессора YRV и получил возможность использовать "стоковый" Rust и порешал проблемы со всеми крейтами в которых была зависимость от mutex. Как минимум мне нужны будут крейты для работы с MIDI сообщениями. Достаточно глупо использовать Rust не используя всю мощь Cargo.
Это стандартный крейт https://crates.io/crates/linked_list_allocator Никакого колхоза. Для esp есть крейт который использует critical section https://github.com/esp-rs/esp-alloc
Спасибо за код, буду посмотреть.
Не понял вот это:
Загрузка через последовательный порт пришла из проекта MIPSfpga и перенесена в проект YRV-Plus Юрием Панчулом. -O ihex дает не совсем тот результат, необходимый для загрузки,
Я помню эту дискуссию, но я полагал что там стандартный IntelHEX, разве нет ? Может быть тогда имеет смысл исправить код самого YRV, чтобы он поддерживал стандартный формат ?
Аналогичным образом выполнен один из режимов загрузки отечественного микропроцессора СКИФ. Но там IntelHEX, я его туда cut-n-paste-ом с консоли запихиваю и все дела. :-)
Это два разных стандарта: IntelHEX и "Verilog IEEE Std. 1364-2005, §17.2.9 Loading memory data from a file" и оба хексы. Но у СКИФа судя по полноценной консольке все-таки софтовый парсер. Можно конечно поставить еще один YRV для консоли и загрузки, но как бутить тогда его )))
Если я правильно понимаю, то Verilog HEX это формат файла для инициализации массивов в момент синтеза, их можно инклудить прямо из .sv кода и это совсем не подходящий метод в данном случае. У Вас же исполняемый файл, который Вы генерируете стандартным компилятором и на это в компиляторе уже есть поддержка традиционного Intel HEX. Считаю, что YRV надо доработать на поддержку именно Intel HEX! Любопытно, на сколько это сложная задача.
Да, в СКИФе есть свой BROM в котором есть парсер Intel HEX и небольшой "монитор" для чтения/изменения ячеек памяти и передачи управления по адресу - как в старые добрые времена. :-)
Кстати, а можно ли YRV снабдить "монитором" на стадии синтеза ?
Парсер intelhex на vhdl видал, так что задача решаема. Я думаю что при некоторых компромиссах доработка будет несложной, надо более подробно ключики посмотреть.
Да это хороший кейс, поставить второй YRV и использовать его как монитор сам то проц невелик 2000 лутов, по нынешним временам ерунда))
Идея с монитором такая: при синтезе помещать код монитора в верхние адреса RAM, как на старых 8-битных ПК, и передавать ему управление при сбросе. В мониторе сделать парсер HEX и прочие мелкие прелести для отладки и вывода текста в консоль. Программа пользователя помещается в нижнюю область и может, при необходимости, смело затереть монитор и использовать эту область памяти, скажем, под стек или для данных.
Да, все хотел спросить, Вы пробовали синтезировать два ядра YRV с разделяемой памятью ?
In RISC-V Rust