Средства и методы разработки

[Фундаментальная размышлизма.] Опенсорц, С++ и победа прогрессивного человечества. http://caxapa.ru/717646.html
http://caxapa.ru/720035.html
Пусть мы все вместе решили заработать на народном PLC контроллере. Контроллерах. Который будем делать на основе продвинутой идеи -> Каждый из нас знает, как лучше всего сделать схемотехнику входов, скомпоновать и развести плату, сделать блок питания и защиту от помех. Эта задача по плечу небольшой фирмешке с толковыми сотрудниками. Но "идеальную железяку" без ПО можно продать ровно за 0 рублей. Независимо от степени идеальности. А вот потянуть в одниночку разработку всего ПО, касающегося PLC (условно) - это задача для такой фирмешки лет на 10. Причем надо еще на что-то жить в процессе перехода по пустыне. Можно сходить в сторону открытых решений. Всякие там http://www.openplcproject.com и иже с ними. Но надо аккуратно смотреть на лицензию. Иначе нарваться можно. Мы пойдем другим путем. Пишем некую высокоуровневую библиотеку классов С++, не зависящую от сторонних библиотек. Т.е. при запуске на какой-то платформе к ней подключают платформенно-зависимые либы (чтобы тот же prinf заработал), но сама по себе "наша либа" должна идти на любом компилере, скажем, С++11. Мегалибу пишем на некотором подмножестве С++ в духе презы Effective C++ in an Embedded Environment --> Поясню на примере структуру либы. У нас распределенная система, значит, есть канал связи. Модель канала с точностью до бита - это уже реализация. Это лишнее. А вот модель на канальном уровне, которая оперирует понятиями "синхрослово принято", "кодовая посылка с ECC принята", причем с данными некоего "виртуального таймера", когда с точки зрения модели это случилось - самое то. Важно выписать эту систему классов, не скатиться в реализацию сразу. Вот какая именно ECC - сейчас не важно. Есть поля и методы класса, и мы работаем только с ними. Вот декодирована пачка бит, вот столько там было ошибок. Вот некорректируемая ошибка встретилась и т.д. Передача в канал - аналогично. Идем дальше. Код мы пишем не просто так, а сразу под управлением RTOS'ки типа RIOT http://caxapa.ru/717429.html От этой ОСьки нам важен ее синтетический порт - это когда она без смены прикладного API запускается под Linux. Причем, важно, что можно запустить несколько копий ОСьки, и заставить их работать совместно с однойм моделью канала. Полная симуляция сети устройств. Аналогично сделано в части IO. Т.е. на уровне высокоуровневой модели все IO - это набор событий и команд по управлению выходами. С привязкой к "таймеру симуляции". А вот модель обработки собственно PLC - это уже уровень нашей высокоуровневой модели. + еще "редактор PLC", чтобы можно было прогу этого PLC писать на одном из 5 стандартных языков (или на их смеси - если трава будет качественная). http://www.openplc …ect.com/plcopen-editor Крайне важным для успеха дела является документация на мегалибу. Очень подробная. Как учебник. Завершающим шрихом является правильная лицензия. Чтобы мегалибу можно было кобирать в исполняемый бинарник с закрытым кодом. Ну и какую-нибудь защиту от зловредности придумать - чтобы если исходник мегалибы правил, то обязан открыть, а так все твое. Вот, становится понятно, зачем С++ вообще нужен :) Почему это имеет шансы на успех? В чистом открытом виде мегалибу скомпилить в контроллер нельзя. Нужно написать реализацию классов для этого случая. Что совсем нетриальная задача. Следовательно, открытость никак не мешает зарабатывать бабло. Она даже помогает этому - потому что созданная усилиями кучи народа мегалиба является необходимым условием, чтобы все эти народные PLC начали продаваться. И при грамотном выборе набора уровней, на которые распространяется открытость, участвовать в разработке будет выгодно всем. Вот ради таких проектов и стоит нарщивать ресурсы контроллеров, чтобы С++ вполне нормально шел на них в железе. Вопрос в том, как такую либу написать "с нуля", чтобы она была и эффективна, и совместима со всеми средами.