RP/M - годится название для операционки?

[vak]

Мысль у меня бродит.

Ко мне периодически обращаются, спрашивают, как бы приспособить RetroBSD для нынешних микроконтроллеров. Я сам давно задался вопросом, только маленько ширшее. Ясно, что идея юникса не годится (потом объясню), но вероятно её можно как-то изменить, приладить к реалиям современных чипов. И натолкнул меня на мысль тот самый компьютер Агонь Лайт, точнее его операционка MOS. Глянул я исходники - фактически народ удачно сваял с нуля подобие CP/M. Нашёл я и клон CP/M, перепёртый кем-то на Си для прикола (x86_cpm_22_0_1.zip). Внезапно осознал, что это оно самое и есть. Ну то есть почти. Реализация бог с ней, а основополагающая идея правильная. Однозадачная операционка по типу CP/M или MS-DOS с поддержкой файловой системы. Но без исторических кривостей и странностей. Ровно то, что по сути хотят сторонники RetroBSD. Пусть всего одна задача, зато с файловой системой, динамическим загрузчиком, загружаемыми драйверами, подключением к сети (отдельный интересный вопрос).

Для конкретики покажу платку, которую я подобрал для такой разработки.



Плата называется Sparkfun Thing Plus RP2040. Тот же процессор, что и Raspberry Pico: два ядра Cortex M0+. Пока задействуем одно ядро, а второе позже пригодится для стека TCP/IP. Имеем 256 килобайт оперативной памяти, 128 мегабайт Flash-памяти и гнездо для внешней SD-карточки.

Представьте, что вы подключаете платку через USB к компьютеру, открываете окошко доступа к консоли (виртуальному или физическому серийному порту) и видите знакомое приглашение:

c:/> _

Диск С: находится в Flash-памяти микроконтроллера. Дальше стандартными командами DIR, CD и прочими бродите по диску и запускаете с него нужные программы. На внешней SD-карточке лежит диск A:. К нему тоже можно обращаться, переписывать файлы туда-сюда, вызывать программы. Активировать и деактивировать загружаемые драйвера. Создавать и запускать BAT-файлы, то есть скрипты. Редактировать и компилировать программы из исходников. Скачивать файлы из интернета, или наоборот, посылать в интернет.

Система должна получиться более-менее переносимой. На этой платке свет клином не сошёлся, да и на микроконтроллере тоже. Два основных требования к процессору: размер RAM хотя бы в несколько десятков килобайт, и Flash-память, прямо отображаемая на адресное пространство процессора.

Как всё это будет фунциклировать - уточню позже, а пока перечислю основные компоненты:

• Командная оболочка, аналог /bin/sh в юниксе или cmd.exe в Windows.
• Файловая система exFAT.
• Набор системных вызовов, видимо подобие Posix.
• Динамический загрузчик, для связывания адресов в момент запуска программ.
• Механизм загружаемых драйверов.

Самый трудный вопрос: название. Пока лучшее, что пришло в голову - RP/M.

Comments

[vit_r]

Не знаю, насколько в файловой системе правильно делать диски отдельными, а не объединять всё под один корень.

Название с разделителем неудобное. Где теперь эти OS/2 и прочие. Гораздо лучше взять какое-нибудь древнее имя собственное от какого-нибудь эльфа, гнома или другого сказочного персонажа.

[vak]

Тогда пришлось бы диски монтировать отдельной командой, а тут они как бы stateless.

Были же всякие A/UX, RSTS/E, OS/360, OSF/1 и даже μC/OS-II.

[vit_r]

Сейчас время другое. Раньше и людей, что на Ассемблере программируют, найти было несложно. С точки зрения маркетинга название должно быть простое и запоминающееся.

[vak]

RP/M очень даже запоминается: Resident Program for Microcontrollers.

[vit_r]

Можно протестировать, насколько запоминается.

И смотреть надо, опять же, не на программистов, а на их начальников.

[tiresome_cat]

Интересньій концепт.

[vak]

Начальникам сходство с CP/M будет душу греть. 😀

[vak]

Вот и я в голове верчу который день - вроде полезная весчь может выйти.

[avnik]

А почему кстати однозадачное?

[kondybas]

Штоп планировщик не мешал прерывания обрабатывать.

[ufm]

Опубликован первый официальный выпуск операционной системы DiscoBSD, основанной на актуализированных исходных текстах Unix-системы 2.11BSD (RetroBSD) и предназначенной для работы на микроконтроллерах. Первый выпуск включает поддержку микроконтроллеров PIC32MX7 на базе архитектуры MIPS и STM32F4 на базе ARM Cortex-M4. Код проекта распространяется под лицензией BSD.

Из главных целей проекта называется обеспечение высокой переносимости ОС на устройства, имеющие ограничения по размеру памяти и не оснащённые MMU (Memory management unit). DiscoBSD может функционировать на системах со 128 КБ ОЗУ и 128 КБ Flash, при этом ядро загружается на Flash и использует около 32 КБ ОЗУ, остальные 96 КБ отдаются пользовательским приложениям. Корневая ФС размещается на SD-карте.

Для работы предлагается полноценное окружение, знакомое пользователям Unix-систем. Например, в состав входят такие утилиты, как sh, csh, grep, sort, uniq, find, uucp, file, kill, ls, cron, fdisk, mkfs, mount, vi, awk, cc, diff, getty, m4, more, sed, xargs, df, iostat, ps, su, tar и т.п.

Это я к вопросу "как-бы приспособить"

[juan_gandhi]

Ну так все равно же драйверы и прерывания, и чо бы сразу M/PM не всобачить. А то народ на прерывания будет вещать задачи.

[ichthuss]

Он не только мешает, но и помогает.

[archaicos]

Даёшь везде©сущую PANOS!

[izard]

полно тридцатилетних начальников, которым это ничего не скажет

[vak]

Ну наконец нашёлся крутой чувак, осиливший перенести RetroBSD на Cortex-M4. Надо будет глянуть детали. Это хорошо, RetroBSD получит новую жизнь. Но для микроконтроллеров, про которые я говорю, всё равно не пойдёт. Негде swap разместить.

[vak]

Что такое M/PM?

Был такой многозадачный DOS на писишках, но популярностью не пользовался.

[spamsink]

Крутая тема перед запуском процесса данные шелла (всякую там command line history и прочие красивости) сжимать, чтобы больше места процессу оставалось, а по окончании - разжимать.

[ufm]

Кому нужна многотаскливость - напишет себе DesqView :)

[juan_gandhi]

Многозадачная версия CPM.

[vak]

Примерно в эту сторону, да. Вроде там на Модуле-2 всё было написано. Интересно, что Модула-2 обещает скоро появиться в GCC.

https://www.theregister.com/2022/12/16/gcc_13_will_support_modula2/

[ircicq]

Если делать однозадачную ОС с POSIX API, то какой софт на ней заработает?
Программы под POSIX предполагают, что это UNIX или Linux и используют процессы.

[vak]

Какой софт люди захотят написать для микроконтроллера, такой и заработает. Обычно это всякие GPIO, SPI, I2C, управление моторчиками. Всё, что предоставляет родной для конкретного микроконтроллера пакет программирования. Для RP2040 это pico-sdk, к примеру. А подобие Posix нужно только для упрощения, чтобы для выдачи на консоль писать обычный printf() вместо какого-нибудь WriteConsoleOutput().

[vak]

Хотите многозадачное - стройте ваше приложение с применением какой-нибудь RTOS. В этом смысле RP/M вас не ограничивает. Берёте все векторы прерываний на себя, и вперёд. RP/M только помогает вам стартовать ваше приложение.

[sab123]

Можно диски назвать как в RT-11, по имени драйвера. Например, MX0:. Ну или с учетом новых реалий, SD0:.

[sab123]

Дык приложения нынче тоже с тредами. Так что планировщик не помешает, он же все равно маленький. Только если нет защиты памяти, то все сделать в виде тредов, как в раннем Виндовсе.

[vak]

Помню такое, да. Для PDP-11 имело большой смысл. К ней каких только дисков не было. Обычно машина была типа одна на лабораторию, и к ней присобачивали все имевшиеся носители. А когда к компьютеру подключено много дисков разных типов, хрен упомнишь, какой из них где. Приходилось именовать.

На писишках уже было не такое разнообразие. Один-два флопика, один-два диска. Помнить типы дисков уже не имело смысла.

На микроконтроллерах будет один, максимум два диска: внутренняя Flash-память и внешняя SD-карточка. Мне кажется, букв A и C будет достаточно.

[ircicq]

По опыту той же RT-11, задач надо предусматривать минимум 2: Background и Foreground.
Иначе пользователю для выполнения любого действия в shell придётся прибивать тот, возможно важный, процесс, ради которого он и использует микроконтроллер.

[vak]

Но тут не предполагается RT-11. Вообще никакого переключения задач. Как в MS-DOS: запустил программу, она и работает.

Интересно

[sla165]

А какой практический смысл?

[vak]

Ардуино всю дорогу ругают за отсутствие практического смысла. 😀

[iyak2]

Интересно, а чем не годится идея Unix для данной платки? Если это Гарвардская архитектура, то вряд ли это будет помехой. Есть идея такая, кратко. Например, с Flash-диска исполняем файл, .text процесса никуда в SRAM не загружается, сейчас .text'у достаточно readonly еще со времен PDP-11, самомодифицируемый нужен был только в PDP-7(9) из-за особенности архитектуры. Косвенную блочность для файлов не используем, используем только монолитные contiguous file. Для секций .data, .bss каждого процесса выделяем необходимую память(фиксированную или динамически изменяемую) - своп область в SRAM. Сколько процессов - столько и своп областей. Как минимум 3,к примеру, в UnixV1 их было 16, только на диске, правда. Создаем там же, в SRAM, еще одну область для .data, .bss, для текущего выполняемого процесса. Ясно, что она должна быть больше или равна любой своп области процессов. По итогу, Unix, мультизадачность,(мир, жевачка))и железное НЕТ деградации Flash-памяти свопингом! Классно, стильно, молодежно! В отличии от многих RTOS, программы можно компилировать отдельно от самой ОС, по идеи, т.к. .data,.bss не привязаны к разным участкам памяти, переключение задач честное.
Да, опционально для экономии памяти, кое-что нужно сделать с .data. При загрузке (exec) исполняемого файла изменяемые данные .data продублировать в своп область. А константными программа будет оперировать с Flash. Для такой особенности нужно немного переписать Си, как кажется. Кому-то далеко до этого. Но если закончить разбираться с ar+ld+as+stip, то может за полгода или год до Си, возможно, сначало изучив Би, вполне добраться. И ничего лучшего, чем понять и простить и портировать, наверное, нет (для усвоения материала).

P.S. Сам такое сделал бы давно, но, увы, с 2018 узнал(диагностировали), что давненько хожу с так называемым орфанным недугом. Вот-то оно и работается мне не очень, не более 1-2 часа в день. Делаю все как получается. А как хотелось рыбки вездесущего Unix для микроконтроллеров!!!

[vak]

Юникс для таких процессоров я уже делал. Для PIC32 с архитектурой MIPS есть RetroBSD: https://github.com/RetroBSD/retrobsd/wiki

Недавно его затащили на ARM Cortex-M4 под названием DiscoBSD: https://github.com/chettrick/discobsd

Но как-то Юникс не приживается. Есть несколько причин.

1. Для Юникса требуется место для swap, а его нету. Без swap не реализуется основополагающий механизм создания процессов fork(). Хотя бы два мегабайта нужно для RetroBSD. Приходится создавать специальный раздел на SD-карточке. В результате без SD-карточки ядро вовсе не может стартовать.

2. Никого не радует необходимость форматировать карточку как юниксную файловую систему. А переделать ядро на ExtFS не выйдет, там гораздо больше памяти потребуется.

3. Доступ к периферии микроконтроллера из юниксного процесса весьма затруднённый. Условно говоря, под каждый чих приходится драйвер писать. Просто так из программы ножками GPIO не подёргаешь.

Многозадачность как раз для народа некритична. Думаю, что подобие CP/M или PC-DOS подошло бы лучше.

[iyak2]

С первым пунктом согласен, с оговоркой, что все-таки с более примитивными Юниксами может что-то получится, и fork, и swap, хотя его возможностей маловато по нынешним меркам. Уже такое делали: https://github.com/MicrochipTech/avrfreaks-projects/tree/main/projects/phoenixu1-porting-unix-v1-atmega-8-bit
Про него в первом посте и писал, в общем-то.

Насчет второго, не знаю, полезная инфа или нет, но было вот такое: https://ru.wikipedia.org/wiki/UMSDOS
Насколько возможно отображать Юникс filesystem на FAT? Это вопрос.

А что касается третьего, наверное, есть и другая крайность, не стандартизированный доступ, порождает не очень хорошую переносимость. Ну к примеру, демосценеров, их собственно можно понять, скорость абсолютно важна, задействование напрямую специфических особенностей железа, это да. Насчет прямого доступа к USART,I2C,... Не знаю. Библиотеки всех спасут! Ну если народу зайдет, то и ладно, на здоровье!

Я когда в немного в истории железа копался, часто натыкался, на непростую генеологическую линию аэсок, много слухов ходит, якобы CP/M это есть как бы упрощенная RT-11, созданная Килдалом, а MSDOS это такоЕ некое творение Франкенштейна, все что смогли заимствовать сначала с CP/M, а потом Xenix, по частям.

А назвать аэску можно Microcontroller Control Program(MCP), по приколу, это во-первых напоминает CP/M, буквы переставлены немного, а во-вторых напоминает главпрограмму из фильма TRON. То же есть кому-то чо вспомнить.