OSDev

Товарищи.

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

Рабочее название проекта GenOS, что расшифровывается как Operation System Generator.

Целевое назначение - быстрое прототипирование, радиолюбительская разработка, узкоспециальное железо, тестирование и изучение, домашняя робототехника. Предварительно AVR, ARM, работа в качестве linux приложения.

В качестве основных источников вдохновения - Arduino, Contiki, Linux.

Язык разработки - C++ (Или, если точнее, си с классами). Это объясняется тем, что основная идея проекта - модульность, а также наследственностью от Arduino.

Genos - это набор модулей, выполняющих узкие системные функции. Набор модулей собирается пользователем аки конструктор и в нужной конфигурации заливается в устройство. Модули делятся на общие (инвариантные к архитектуре) и архитектурно зависимые.

Примеры общих модулей-классов:
- Событийный диспетчер.
- Вытесняющий диспетчер.
- Централизованный флаговый автомат.
- Служба времени.
- Многообразие Print классов.
- Консоль.
- Командный интерпретатор.
- Модуль работы с блочными устройствами.
- Комутатор файловых систем.
- Elf загрузчик.
- Модуль, для работы с IP.
- Handshake-server (Отвечает за связь с родственными Genos сборками, что позволяет реализовывать удалённое управление.)

Примеры архитектурно зависимых:
- SDIO wifi.
- SDIO flash-карта
- Print класс для работы со стандартным вводом выводом linux среды.

Обоснование:

По собственному опыту, люди желающие изготовить дома что-то сложнее последовательного опроса датчиков, сталкиваются с очевидными проблемами, требующими использования управляющего кода http://easyelectronics.ru/avr-uchebnyj-kurs-arxitektura-programm.html. Стандартное решение - привлечение готовых ОС. Например FreeRTOS.

К сожалению, порог вхождения у таких систем высоковат. Это в частности объясняется избыточностью готовых ОС.

Предлагаемая концепция предлагает пользователю самому решить, какая часть ОС ему нужна и сосредоточиться на ней.

Намеренная модульность и явная инкапсуляция удобны для чтения, изучения и дополнения.
То, что проект собирается, как конструктор, позволяет пользователю начать сборку с нуля без необходимости сразу вникать в механизм работы всей системы. (Используется подход Arduino.)

В качестве недостатков языка с++ - малое количество готовых решений по сравнению с чистым си. Поэтому выдирание кода с чужих проектов несколько осложняется... Код приходится постоянно допиливать под концепт, однако радует возможность практически мгновенного подключения всего Arduino хозяйства.


Короче говоря, це есьм некоторая надстройка над Ардуино, только ориентированная не на железо, а на системную работу.

Проект прошёл несколько стадий. Зарекомендовал себя в моих личных проектах под AVR (http://www.youtube.com/watch?v=iNjnnPqxjHk), был в качестве теста портирован на ARM, где с матом и булочками его удалось запустить.

После этого было решено собрать Contiki подобную систему сборки, с тем чтобы впредь не надо было изобретать велосипед при переходе между архитектурами.

_________________
http://osdev.ru/viewtopic.php?f=4&t=893 - GenOS

Думал как-то позаниматься коптерами, точнее их контроллерами, вижу что-то похожее
Наверное всё же Operating System Generator ?
Надо бы пример использования приложения. А то для Ардуино уже есть родная среда разработки, соответственно - зачем что-то новое ?
То есть всё же предполагается не linux приложение (как сказано выше), а некая ОС для микроконтроллеров ?
Опять похоже и на ОС и на приложение для линуха. Диспетчер подразумевает ОС, но Elf загрузчик подразумевает линуха - что за адская смесь ?
Опять непонятно - что надо делать ? ОС или приложение ? Или оба вместе ? Или ? И главное - зачем ? То есть пример использования гипотетического софта снял бы много вопросов.
В общем как я понял - надо всё же ОС, но хочется не только под Ардуино, но и для других контроллеров. Кроме того нужно и что-то под обычной ОС (типа линухА), что бы готовить прошивки и всё такое. Правильно ? А теперь всё же как принято в нормальных софтовых конторах, так сказать, юз кейс в студию То есть всё же нарисуйте (словами) красивую картину светлого будущего, где все ваши мечты реализованы и вы просто рассказываете нам про то, что же происходит в ваших мечтах. Пример - запускаю софт под линухом, рисую алгоритм управления электродвигателем, заливаю на железяку, она мне на минидисплее весело подтверждает готовность, позволяет прогнать тесты, снять логи через USB, и вообще всячески радует. Как-то так ...

Кей! Понял вас.

В силу своей модульной природы Genos полиморфен. А потому может работать как в качестве ОС на голом железе, так и быть скомпилированым в качестве linux приложения.

Пример использования:

Дано: Смартфон под управлением Андроид, ПК (linux), радиоуправляемая тележка с одноплатником, в качестве основного вычислителя и авркой в качестве контроллера шасси (связь по USART, или I2C).
(Одноплатник рулит авркой.)

Задача - научить их работать сообща. Смартфон, ПК и одноплатник могут работать в одной wifi сети, но для каждого придётся отдельно писать и настраивать клиент-серверы для передачи информации. Управление тележкой со смартфона. ПК рисует графики, выводит видео.

Поступаем следующим образом на каждом устройстве вертится сборка genos. Под Андроид и под ПК genos собирается как приложение родной ОС. Genos на одноплатнике может работать и под линуксом, и в качестве ОС. AVR на контроллере шасси работает под управлением genos.

(Разница только в том, что в одном случае Genos имеет дело с драйверами, а в другом с API родительской системы.)

Каждая сборка имеет интегрированную консоль и систему поиска "братьев" (handshake-сервер). В совокупности это позволяет получить доступ к консоли любого genos управляемого устройства с любого устройства в рамках этой сети (причем одноплатник прокидывает сеть на контроллер шасси).

Разумеется, сборки могут сильно отличаться. В частности управлялка на смартфоне может не иметь диспетчера и консоли, а просто скидывать информацию на одноплатник по условленному алгоритму, предварительно пропустив её через ИМУ.

Таким образом унификация каналов связи и система поиска позволяет вместо четырёх разрозненных устройств, получить своеобразное облако.



Что касается использования самого Ардуино, то возможно когда-нить я потяну и оболочку типа Ардуино IDE... Но пока нечего паковать.


Адская смесь объясняется целевым назначением. Мы должны запускаться везде и всегда, уметь запускать всё,что пинается, а что не пинается - пинать и запускать.

Мы можем это делать не лучшим образом. Главное, чтобы быстро и гарантировано (ну, более или менее).


P.S. Мой контроллер квадрокоптера, кстати тоже на этом чуде работает.

P.P.S Всегда думал, что "operation" пишется ...

_________________
http://osdev.ru/viewtopic.php?f=4&t=893 - GenOS

В переводе на ТЗ - требуется платформно-независимая софтина, позволяющая управлять железом некоторого набора платформ, в том числе удалённо, при помощи подключаемых модулей. Управление реализуется в виде консоли с расширяемым набором функций. Набор платформ прилагается - ПК, Андроид, одноплатный комп, контроллер АВР. Похоже ?
А почему двойная система ? АВР вроде от 8 до 32 бит контроллеры делает. Старшие модели не потянут всё в одном флаконе ? Или там вай-фай не прицепить ? Или какой-нить блютуз ?
То есть к удалённому управлению добавляется функция ретранслятора ?
Видимо не консоль, а набор компонентов, управляемый с удалённой консоли. А консоль нужна на ПК или Андроиде (как средство визуализации и подачи команд). Так же на ПК с Андроидом, видимо, управлять железом не очень надо ?
Видимо проще - позволяет удалённо управлять неким набором устройств с клиентской станции (телефон/планшет/ПК) ?
Облако, это не совсем удалённое управление. Это миграция приложений, например. Зачем мигрировать приложение с АВР на ПК ? Кто будет его с АВР на ПК пропихивать, в смысле кто инициатор ? АВР станет обладать ИИ ? Видимо всё же требуется просто одностороннее удалённое управление.
Ну что сказать, нужно следующее:
1. Консольная часть, работает с пользователем, должна быть платформно-независимой.
2. Часть, обеспечивающая связь, тоже может быть платформно-независимой.
3. Протокол удалённого управления, тоже независимый.
4. Приёмная часть, обеспечивает раздачу принятых команд, тоже независимая.
5. Куча переходников под разные целевые системы, заточенных с одной стороны под приёмную часть, а с другой - под целевую систему.
6. Система запуска/останова принятого по сети софта, мониторинга его работы, передачи ему команд и прочего, характерного для процессов ОС, тоже независимая.

Под словом "независимая" имеется в виду обязательная для каждой платформы, но требующая перекомпиляции, что означает наличие ещё и компилятора под каждую платформу. Ну а если есть компилятор - уже недалеко и до Java ОС С ней байткод даже перекомпилировать не понадобится - написал один раз и запускаешь везде. Ну да это отступление

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

Похоже, ну да не очень...
Я написал лишь вариант применения, который может быть создан из этого конструктора.

Основная цель - быстрое прототипирование. Поэлементная отладка.

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

Замах безусловно на годы. Учитывая, что только на постановку задачи ушло полтора года...

Что до квадрокоптера:
- событийный диспетчер.
- консоль.
- система Print потоков.
- ИМУ на кватернионах.

_________________
http://osdev.ru/viewtopic.php?f=4&t=893 - GenOS

Для "быстро попробовать" нужна большая готовая инфраструктура. Нужно на ПК написать свой прототип, нужно связаться с железякой, нужно заслать на железку свой код, нужно запустить код на железке, нужно получить отчёт о работе кода на железке, нужно иметь возможность остановить его, заглянуть в память, что-то изменить, возобновить исполнение, потом опять всё остановить, что-то поправить на ПК, опять закачать на железо, и опять весь цикл по новому кругу.

Собственно в этом разрезе предложенный выше набор компонентов мне видится удобным. Предложены средства общения с человеком через ПК/Андроид, средства связи с железякой, средства обслуживания кода на стороне железяки, средства получения нужной информации обратно на ПК. То есть всё это средства поддержки описанного выше цикла прототипирования.
Не понял. Надо бы поконкретнее и с примерами, как для детей.

Диспетчер - это просто одна функция обработчика прерываний от таймера. Наверное ваша реализация всё же малость пошире ?

Консоль должна иметь экран. Как он помещается на квадрокоптер ? Видимо опять имелось в виду нечто вспомогательное.

Принты по сути есть преобразователи входных байт в трансформированные выходные. То есть простые конвертеры. Не совсем компонент, но с натяжкой можно им считать.

ИМУ на кватернионах - это нечто не совсем понятное. Вроде по смыслу некая система управления 3-д положением. Здесь замешаны в кучу математический аппарат (подмножество матричных операций) и некая ИМУ, под которой видимо понимается система расчёта сигналов управления для контроллеров электродвигателей. Хотя может я совсем неправильно понял это шифр.

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

Затык в терминологии. У микроконтроллерщиков понятие консоли куда размытей.
В плане функционала консоль, в текущей реализации, представляет собой, read-line библиотеку + парсер. В настоящее время место консоли занято перепиленным проектом microrl.
Фактически такая консоль является преобразователем символьного потока в argv-argc структуры. На вход этой консоли подаётся символьный поток (я его не слишком удачно назвал print-потоком). На выходе структуры, пригодные к вызову в качестве функций. Тобишь, по сути, shell.

Отдельно следует остановиться на концепции символьных потоков. Я уделяю этому вопросу большое внимание. В том виде, в котором они реализованы в проекте, символьные потоки наследованы от Ардуино. Символьный поток представляет собой класс, имеющий функции write и read, отвечающие за запись и чтение символа. Все символьные потоки наследуются от классов Stream и Print, которые предоставляют, в частности, перегруженную функцию print, которая умеет выводить на печать практически всё, благодаря чему работа с системой ввода-вывода становится очень удобной.

В силу того, что символьные потоки фактически дуплексны, их очень удобно комутировать друг с другом. В том числе и между устройствами.

Это позволяет связать напрямую две консоли на разных устройствах, тем самым позволяя им общаться между собой посредством командного интерпретатора. Минус такого способа связи очевиден. Обработка строк требует времени, но в то же время, такой способ связи легко настраивать и мониторить.

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




IMU - расшифровывается как Inertial Measurment Unit - инерциальный измерительный блок. Но опять же тут более широкое понимание.
В современной робототехнике получили распространение MARG системы, тоесть наборы датчиков, состоящие из акселерометра, гироскопа и магнетометра.
Я счел возможным абстрагироваться от конкретного типа датчиков и считать систему, расчитывающую ориентацию объекта аппаратно независимой. (При условии наличия этих трёх датчиков).
IMU - модуль - отвечает за расчет ориентации объекта.


В общем-то я именно так и делаю, спасибо ... Возможно скоро мне удасться осчастливить здесь присутствующих работающим кодом.

_________________
http://osdev.ru/viewtopic.php?f=4&t=893 - GenOS

Имеет смысл выделить протокол обмена данными и под него уже писать парсеры и прочее. То есть протокол отдельно и модули его обработки тоже отдельно. В модулях стоит выделить сериализатор и десериализатор, то есть преобразователи из объектной модели (структуры данных) в поток байт и обратно. В результате помимо протокола нужно разработать модель данных, которые будут гоняться туда-сюда с использованием протокола и превращаться в байты при помощи сериализатора, а потом опять в объектную (структурную) модель десериализатором. Модель данных должна быть изолирована от протокола, то есть ни как от него не зависеть. Протокольные данные (а ля источник, приёмник, какие-то частоты, скорость и прочие атрибуты передачи данных) так же должны быть выделены и описаны. Для примера можно поглядеть на готовые архитектуры вроде этой.
Единственный (но важный) плюс таких потоков - удобочитаемость. Поэтому подумайте о выделении некоего "визуализатора" вашей модели данных, который переводит объектную модель в текст. Это тот же сериализатор, но не в байты, а в другое представление.
Коммутируемой должна быть связь, а данные к коммутации отношения не имеют. То есть если вы реализуете простой передатчик набора байт, то вам останется всего лишь снабдить обе стороны сериализатором и десериализатором - вот вам и общение (ну плюс управление процессом, конечно).
Это по сути простейшие зачатки удалённого отладчика. То есть планируйте именно отладчик, а не утилиту, в которой намешано всего помаленьку. У отладчика тоже должна быть внятная архитектура. Общение с внешним миром в эту архитектуру входить не должно, это задача модуля связи и сериализаторов. Так же отладчик должен понимать структуру отлаживаемой программы, а это уже полностью ваша ответственность, раз вы взялись делать ОС. То есть сначала нужно определиться со структурой классов (данных) и способом вызова методов (функций), а так же с тем, как это всё будет уложено в памяти (адреса, смещения и т.д.). Ну и далее станет очевидным, как и зачем отладчик сможет залезть в нужный регион памяти.
От аппаратной реализации не зависит только алгоритм. Вот его и выделяйте. В принципе можно не убиваться по этому поводу, но просто считать любой ваш код таким алгоритмом. Главное, что бы код соблюдал некий интерфейс при общении с остальной системой. Тогда система через стандартные функции/методы отдаст данные с датчиков, а код в ответ выдаст расчётное положение или команды на его изменение.
Здесь присутствующие могут поспорить с вами о понимании счастья Хотя отдалённая перспектива вашего начинания может многих заинтересовать. Но первые робкие строчки кода - вряд ли.

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


Плюс в том, что с потоком может работать любой эмулятор терминала, а влезть в него можно хоть на середине линии. Сериализатор и десериализатор - это хорошо, но излишне.


Как и большинство предлагаемых решений, эта штука весьма универсальна. Доступ к данным позволяет удалённую отладку. Но также позволяет и удалённое управление.
Пример: Смартфон управляет машинкой, изменением уровня наклона (считываем показания акселерометра). И на той и на другой стороне есть несколько интересующих нас переменных, на стороне смартфона есть переменная, отвечающая за коэффициент усиления управляющего сигнала. На стороне машинки есть переменная, отвечающая за текущую скважность ШИМ сигнала. Алгоритм забитый в смартфон, каждые 50 милисекунд генерирует команду, изменяющую значение переменной на стороне машинки. Прелесть в том, что ту же самую команду без необходимости писать какое-либо ПО может передать любой виртуальный терминал, подключившийся к соответствующему порту. И таким же способом можно поправить коэффициенты программы на смартфоне. То есть упрощается доступ даже с устройств, которые слыхать ничего про Genos не слышали.


Кекеке... Ну, нет так нет.

_________________
http://osdev.ru/viewtopic.php?f=4&t=893 - GenOS

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