Обновить

Двенадцать символов, двадцать один байт: как я научил голый RISC-V говорить «Привет, мир!»

Уровень сложностиСредний
Время на прочтение12 мин
Охват и читатели9K
Всего голосов 9: ↑9 и ↓0+11
Комментарии6

Комментарии 6

По делу надо еще этот UART сначала настроить, а потом для каждого символа дожидаться, пока регистр (Transmitter Holding Register в NS16550A, который в virt эмулируется) освободится. Впрочем, туториалов такого рода в интернете немало, и никто этого не делает... потому что никто не запускает их на реальном железе и не пытается напечатать что-то более длиннее hellord.

Спасибо, вы попали в больное место.
Полез проверять и упёрся в неожиданное: мой "стенд" эту ошибку показать не может в принципе.
QEMU отдаёт байты так быстро, как получится, скорость линии не моделирует, и THRE у него не снимается никогда.
То есть проверить себя мне было нечем, даже если бы я задумался.
Тема оказалась заметно больше комментария.
Разбираю её во второй статье: собираю стенд, на котором ошибку видно.
Спасибо за наводку, сам бы прошёл мимо.

QEMU действительно самостоятельно не эмулирует скорость линии, но THRE он снимать умеет. Он просто проксирует все на фронтенд устройства uart. Если фронтенд - это консоль, и пишем мы десяток символов, то оно пролетит моментально. А вот если, к примеру, устройство UART гостя отображается на реальное uart-устройство хоста, то настройки в госте (типа divisor) будут приводить к соответствующей перенастройке реального устройства, и наоборот, переполнение буфера реального устройства будет приводить к заполнению xmit FIFO на госте, и снятию THRE. Конечно, получается не вполне честное поведение (как минимум фактическая глубина FIFO будет больше, чем должно быть для 16550) - но если послать "войну и мир" в COM-порт, который замаплен на настоящий COM-порт, то средняя скорость передачи будет реально такой, какая была настроена в 16550 (и THRE большую часть времени будет снят).

Проверил, вы правы.
Написал программу на 300 тысяч записей, которая считает, сколько раз передатчик оказался занят.
С выводом в файл ноль раз. С медленным TCP-приёмником счётчик сразу упирается в потолок. THRE снимается нормально, просто у меня на другом конце была консоль, которая не тормозит никогда.
FIFO для этого даже не нужен, дело в tsr_retry. Проброс настроек в реальный порт тоже нашёл, всё так.
Статья ещё не опубликована, поправку внесу сразу. Спасибо.

в опроснике не хватает варианта: начинал на 8бит машине с POKE кодов команд из вcтроенного basic/monitor. встроенный basic в принципе тянет на ОС, можно использовать процедуры последовательного вывода на магнитофон. так что ожидание операции вывода там из коробки, и процессор при этом ничего другого делать почти не успевает .

Вариант добавил.
Спасибо за мысль. У вас забыть ожидание вывода нельзя физически: процессор там сам отсчитывает такты и сам работает устройством, ожидание и есть вся программа. Моя ошибка стала возможной только потому, что ждёт кто-то вместо меня. А эмулятор спрятал и это.
Выходит, чем удобнее железо, тем проще написать код который на нем же и развалится.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации