ТЕМА: SoC для платы Марсоход2

To alman.
Я вижу следующее изменение процессора.
В области доп. регистров назначается регистр задачи.
Доп. регистры не переключаются между задачами.
Задачи не используют доп. регистры (только ОС).
Добавляются 16 регистровых окон по 16 регистров для стека возвратов
и 16 окон по 16 регистров - для РОН (больше не влезет в существующую м/с).
Такую реализацию на существующей архитектуре процессора вполне можно сделать.

Можно ли не переключать доп. регистры между задачами?

Николай.

Ynicky пишет: To alman.
Я вижу следующее изменение процессора.
В области доп. регистров назначается регистр задачи.
Доп. регистры не переключаются между задачами.
Задачи не используют доп. регистры (только ОС).
Добавляются 16 регистровых окон по 16 регистров для стека возвратов
и 16 окон по 16 регистров - для РОН (больше не влезет в существующую м/с).
Такую реализацию на существующей архитектуре процессора вполне можно сделать.

На 16 задачах вполне можно написать специализированную операционную систему. Даже не придётся использовать трюки с помещением нескольких драйверов в одну задачу.

Можно ли не переключать доп. регистры между задачами?

Да, конечно.

Есть некоторый момент с обработчиками прерываний. В простейшем случае обработчик прерывания посылает сообщение драйверу. Благодаря единой точке входа значительно упрощается написание драйверов - любой драйвер можно рассматривать как цикл, блокирующийся в ожидании сообщения. Если пришло сообщение о прерывании - обрабатываем его, если пришло сообщение с командами (например чтение/запись) от другой задачи (ядра системы или прикладной задачи), то обрабатываем его. Таким образом внутри драйвера не нужно сихронизировать структуры данных - они обрабатываются последовательно.

В оригинальной спецификации L4-X2 источник прерывания определяется номером задачи. В случае ST16 номер прерывания можно закодировать в первом регистре буфера сообщений.

Ещё один весьма важный момент. Команды для захвата и освобождения буфера сообщения могут быть не симметричы. Например, вот случай симметрии:
В этом случае освобождается тот же самый буфер сообщений, который был аллокирован командой выделения буфера. Однако, в реальном системном вызове работа с буфером сообщений не столь наглядна.

Инструкция ExchangeMessage имеет три аргумента - получатель сообщения, источник сообщения и таймаут (возможно, под это дело можно задействовать дополнительные регистры, или поместить аргументы непосредственно за кодом инструкции, или ещё как-то). Получатель и источник описывают фазы, которые присутствуют в команде. Таким образом инструкция ExchangeMessage может иметь следующие логические формы:

ExchangeMessage - содержит фазу передачи и фазу приёма.
SendMessage - содержит только фазу передачи (в качестве задачи-источника указан 0)
ReceiveMessage - содержит только фазу приёма (в качестве задачи-приёмника указан 0)

(На самом деле форм чуть больше, но не хочется усложнять пример - остальные формы вытекают из этих и не противоречат описанным)

Например, схема библиотечной функции, которая производит обращение к ядру.
Инструкция ExchangeMessage переключает контекст, перекоммутируя буфер сообщения задаче обработчику. Момент в том, что в процессе обработки сообщения назад может вернуться другой буфер. По большому счёту программисту не важно, какой именно буфер сообщения вернул системный вызов - UnlockMessage просто осободит активный буфер.

Однако, сообщение может не иметь фазы приёма или фазы передачи - именно этот момент демонстриует отсутствие симметричности. Например, задаче необходимо лишь передать сообщение, но не нужен ответ. Если ExchangeMessage не имеет фазы приёма, то после завершения команды у задачи не будет назначенного буфера и его не придётся освобожать. Верно и наоборот - если сообщение имеет только фазу приёма, то перед вызовом команды не нужно захватывать буфер, но после приёма и обработки сообщения буфер необходимо отпустить. Таким образом следующие виды команд вполне допустимы и имеют смысл:

Только передача сообщения
Только приём сообщения

Добавил к проекту генератор текстовых символов и порты ввода-вывода.
Описание не успел скорректировать.
На днях сделаю, тогда и выложу вместе с проектом.
Теперь можно будет добавить контроллер АЦП и выводить информацию
с него на экран. Но это следующим шагом.
Хочу на основе платы сделать зарядное устройство к щелочным (alkaline) батарейкам.
Уж больно они дорогие. А расходуются часто.

Символы на экране

Николай.

Как и обещал, выкладываю доработанный проект.
А также ссылку на ролик с цветовой палитрой.

Палитра










Николай.

To alman.
Небольшой вопрос.
Инструкции:LockMessage, ExchangeMessage, UnlockMessage - это именно ассемблерные инструкции
или, как я думаю, написанные на С?

Николай.

Ynicky пишет: To alman.
Небольшой вопрос.
Инструкции:LockMessage, ExchangeMessage, UnlockMessage - это именно ассемблерные инструкции
или, как я думаю, написанные на С?

Это три ассемблерные инструкции. LockMessage и UnlockMessage должны коммутировать расширенные регистры задаче, которая вызывает эти сообщения. А ExchangeMessage может перекоммутировть расширенные регистры задаче, с которой происходит обмен сообщениями.

В принципе, Вы совершенно правильно заметили - эти инструкции можно реализовать программно - именно так посутпают разработчики микроядра L4. К примеру, вот лучшая программная реализация микроядра L4 - github.com/l4ka/pistachio

А можно попутно вопрос про знакогенератор? Из видео трудно понять разрешающую способность - сколько символов по вертикали и горизонатли? Поддерживаются ли аттрибуты? Правильно ли понимаю, что для вывод символа на экран необходимо записать его код в определённую область памяти? Насколько я могу судить, при этот графический режим оставётся так же доступным - цветные полосы уживаются вместе со знакогенератором.

А можно попутно вопрос про знакогенератор? Из видео трудно понять разрешающую способность - сколько символов по вертикали и горизонатли? Поддерживаются ли аттрибуты? Правильно ли понимаю, что для вывод символа на экран необходимо записать его код в определённую область памяти? Насколько я могу судить, при этот графический режим оставётся так же доступным - цветные полосы уживаются вместе со знакогенератором.

Каждый текстовый символ имеет размер 8х8 элементов изображения.
У каждого символа есть атрибут цвета фона (3 разряда, т.е. RGB111)
и атрибут цвета символа (тоже 3 разряда, т.е. RGB111).
Текстовый символ кодируется следующим образом:
младшие 8 разрядов - собственно сам символ из таблицы символов ASCII;
следующие 3 разряда - цвет символа;
и последующие 3 разряда - цвет фона.
Код символа с атрибутами записывается по адресу 0xFC00 контроллера
текстовый символов.
Адрес символа на экране записывается по адресу 0xFC02 контроллера
текстовый символов.
Графический и символьный режимы VGA контроллера не различаются.
Контроллер VGA берет информацию для выдачи на экран из определенной
области памяти (начиная с 0x10000). Он оперурует только элементами
изображения, т.е. графикой.
Чтобы выдать символ на экран, его нужно преобразовать в графику.
Чем и занимается генератор текстовых символов.
Он просто преобразует код и атрибуты преданного ему символа
в графику и записывает ее в определенную область памяти VGA контроллера.
Небольшое описание генератора текстовых символов есть в файле:
src/Doc/to102msh2soc.

Николай.

To alman:
За эти выходные написал первую версию .md файла для получения компилятора.
Выкладываю исходники.
К сожалению, сами исполнительные файлы занимают много места.
Не могу вставить.
Если Вас еще интересует компилятор к процессору, посмотрите исходники.
Может будут вопросы.

Николай.

Спасибо, посмотрел. Я так понимаю, исходники из архива это доработка компилятора LCC под Ваш процессор? Т.е. содержимое архива нужно распаковать поверх исходников LCC?

содержимое архива нужно распаковать поверх исходников LCC?

Да.