Evgeny_CD, Архитектор (17.01.2017 03:49, просмотров: 95) ответил SciFi на А смысл? Осек и так хватает. Чисто коммерческих и не очень. Что изменит ещё одна? К тому же они не выпрыгивают неожиданно из-за угла. Хорошая оська, как и коньяк, имеет солидный срок выдержки.
Я пока скорее мутно ощущаю, чем понял, следующее. http://caxapa.ru/315937.html
1. эффективное использование С стало массовым знанием через 10 лет и более после создания самого С.
2. Глубинное понимание, что такое RTOS, стало массовым вообще лет 10 назад.
3. Понимание как эффективно использовать C++, для embedded, в частности, только-только сейчас выходит в широкие массы.
4. C++ only RTOS является ересью или экспериментельной экзотикой для большинства читателей этого сайта.
5. Если даже драйвера сделать C++, то эмуляторы этих драйверов можно будет сделать на любой системе, на которой мы разрабатываем проект.
6. Если код ОСи C++ не содержит внешних либ, и имеет свой собственный namespace, это значит, его можно запустить в любом окружении С++ компилера (соотвествующей версии С++хх)
7. Следовательно, дрова можно отлаживать на реальном железе, а все остальное - на любой платформе разработчика. Можно наплодть кучу тестов, и готовыми фреймфорками (коих под С++ немало) добиться, как минимум, 100% code coverage для Оси и базовых либ. Кода юзера тоже, разумеется.
8. Эмуляторы дров можно писать на SystemC, под управлением которого можно запустить и нашу С++ RTOS тоже, и там можно наэмулировать море различных ошибок, которые замаешья отрабатывать в реальном железе. Тесты будут весьма качественными.
SoCLib ->
9. Система тестирования кода в том же Visual C++ гораздо удобнее, чем отладка "JTAG". И горазо качественее, если использовать мозги.
10. Одна из главных задач тестирования - определить, что код умеет вовремя детектить ошибки, и информировать об этом. Когда источник ошибки более-менее понятен, дожать ее - дело техники.
11. Есть много тонкостей при переносе кода с платформы на платформу. Это еще надо изучать. Но! на уровне С++ можно считать, что компилер сущности языка отрабатывает правильно. Это не исключает ошибок компилера, но они не очень вероятны, и если отлажена система самодиагностики - то их их найти можно.
12. RTOS в месте с core lib доступна не только в виде исходников, но, что еще важнее, в виде некой базы кода и кодогенератора с открытым исходником.
Кодогенератор имеет данные о зависимости модулей, и имеет входной конфиг - что и как хочет пользователь от ядра системы. И на основе этого кодогенератор генерит исходники и тесты для выбранной конфигурации.
Это гарантирует тонкую настройку проекта и отсутствие неиспользованного кода.
Кодогенерация простая. Синтезом сущностей С++ кода кодогенератор не страдает. Они либо постит строку на выход, либо нет. Максимум - расставляет ключевые слова по меткам.
13. Коммерция.
Вот есть производитель GPU, который с перепоя решил сделать дрова для своего чуда под !Linux платформу.
Он пишет дрова и пишет конфиг для некоторой версии нашей ОСьки. Конфиг класса mandatory - юзер не может отменить "галки", он может только добавить свои.
Потом он компилит свой драйвер, и выкладывает объектник вместе с mandatory конфигом. И все юзают это чудо-юдо.
Подобных примеров можно привести очень много - WiFi, какие-то фирменные протоколы.
14. Важно, что будет публично доступное системное ядро, которое может пойти почти на чем угодно (с ограничениями в рамках выбранной коняигурации), которое станет основой интеграции в рамках целой индустрии.
И 512М ОЗУ, и даже 256 М для всего этого точно хватит :)