Точно. Стек протопотоков общий. Переполнение одно на всех. Отработка протопотоков асинхронная. Для 8-битников, на мой субъективный взгляд, очень удобно.

Связи нет никакой, скорее всего я озадачился размерами ваших программ))) Ну, а всё-таки, есть в том же kinetis что-то аппаратное, что позволяет вам как-то предохранять память от несанкционированного доступа? В "больших" камнях это решается MMU с вызываемыми исключениями...


Мне нравится ваш подход. Наверно потому, что и я думаю в этом же направлении Уже давно нахожусь на пути создания минимального базиса (фреймворка), включающего в себя ОС (пока FreeRTOS), стек драйверов (high и low-уровни), отладочная текстовая консоль (использую обточенную CLI из FreeRTOS), адекватный менеджер памяти, позволяющую понять куда она ушла (спасибо уважаемому zltigo!). Логгер пока ещё не присобачивал.

Я с вариантами разберусь, а вы пож. не постите ерунду больше.

syoma, спасибо за текст. Не мое точно. Точнее все то что вы пишите в том или ином виде есть по умолчанию в любом проекте. И абстракция и манагер процессов и логер если нужно. Только все это в примитивной форме в достаточной для решения моих задач. Чего мне не хватает так это инструментов для реализации бизнес логики и меня не устраивает не только сложность с написанием ПО, но и самое главное сложности с его модификацией.

"Что-то аппаратное" есть во всех Cortex-M - MPU. Использую MPU в всех своих проектах на Cortex-M обязательно. А почему собственно его не использовать?
Только предохранить какую-то конкретную переменную с помощью него конечно затруднительно. Зато при отладке MPU очень часто помогает.

Вот это все было бы хорошо оформить в виде статьи!
Пусть она будет небольшая, но тем не менее...
Прямо так и начать: "В конференции шло обсуждение... И мое мнение таково..."
И к нам, в КиТ...
Что скажете?

Что такое бизнес-логика?

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

Не статью писать надо, а в github.com постить.
Нынче так - или вы показываете свои сорсы на github-е или ваши слова про программирование малого стоят.
Когда говорят о такой запредельной абстракции как некий "I/O менеджер" исходники надо показывать в обязаловку.
Я не первый год в программировании, но у меня даже не идей что такое "I/O менеджер"

Писать надо туда, где больше заработаешь.
А I/O менеджер и менеджер коммуникаций звучат слишком похоже.
У меня все время висит вопрос, как назвать, к примеру, файл низкоуровневых функций. Типа HAL. HAL называть не хочу. Драйвер пока зову.
А как разобьешь на файлы-папки, как назовешь, так и поплывешь-попрограммируешь.

Да нет, у каждого издания свои читатели.
КиТ имеет тираж 6,5 тыс экз. И никто не мешает сначала напечатать статью, а потом размещать материалы еще где-то. Тем более, исходники можно выложить в сети и в статье на них ссылаться. потому как статьи - это пожизненно, а тексты из сети лет через 10 могут и удалить.
А для чего нужны статьи я написал в КиТ №11 за 14 год. Они нужны не для того, чтобы все знали о том как писать программы для... А для того, чтобы получать приличную зарплату.

Слова, слова по любому малого стоят, хоть напечатанные на "github-е" хоть нет. Стоит результат программирования.

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

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

На самом деле "многочисленные IF/ELSE (SWITCH/CASE)" - это фундаментальная проблема программирования которая пока никак не решена. Даже в том же пресловутом ООП.
А ведь эти "IF/ELSE (SWITCH/CASE)" - есть ГЛАВНАЯ причина трудно модифицируемости программы и появления трудно отслеживаемых ошибок, возникающих при внесении изменений в программу.

Но пока что универсальной пилюли (программирование без if..then..else) не изобрели.
Хотя отдельные попытки предпринимаются.

Массив указателей на функции, например.

Коллега уже хорошо сказал про такие "рецепты":


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

Сообщение отредактировал Укушенный воблой - Jan 6 2017, 09:40

Фундаментальное отличие между ними в том, что I/O менеджер работает в реальном времени и взаимодействует с физическим железом. Причем делать он это может как напрямую - через драйверы HAL, так и через последовательные интерфейсы - CAN, SPI,RSXXX и пр. В одном проекте у нас вообще используется EtherCAT мастер с временем опроса в 100мкс.

Контроллер коммуникаций наоборот, работает не в реальном времени. Например он может работать под обычной операционкой. Его задачей является связь со всеми остальными интерфейсами, которым не нужно реальное время. Например все Ethernet коммуникации типа веб-серверов, ФТП и пр. Обработка клавиатуры, дисплея.

Контроллер коммуникаций является клиентом I/O менеджера - он должен иметь доступ к нужным сигналам, но этот доступ должен быть четко регламентирован, так как он будет проходить через границу между реальным и нереальным временем. Т.е. тут нужно предусматривать буферизацию, очереди сообщений и пр, чтобы не потерять информацию. Хорошо, что это надо сделать только один раз.