[Drozd2 0]

называются "кооперативные" ?

Чтоб запустить на MK достаточно откомпилировать, портирование не требуется ?

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

[haker_fox 61]

Cortex-M3 давно уже не использую.

Не понял связи ошибки памяти с фреймворками.

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

 

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

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

[Буратино 0]

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

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

 

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

[jcxz 242]

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

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

Только предохранить какую-то конкретную переменную с помощью него конечно затруднительно. Зато при отладке MPU очень часто помогает.

[iosifk 3]

Буратино, я думаю, что ваша проблема в том,...

Вот это все было бы хорошо оформить в виде статьи!

Пусть она будет небольшая, но тем не менее...

Прямо так и начать: "В конференции шло обсуждение... И мое мнение таково..."

И к нам, в КиТ...

Что скажете?

 

[syoma 1]

Чего мне не хватает так это инструментов для реализации бизнес логики и меня не устраивает не только сложность с написанием ПО, но и самое главное сложности с его модификацией.

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

 

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

[AlexandrY 3]

Вот это все было бы хорошо оформить в виде статьи!

...

И к нам, в КиТ...

Не статью писать надо, а в github.com постить.

Нынче так - или вы показываете свои сорсы на github-е или ваши слова про программирование малого стоят.

Когда говорят о такой запредельной абстракции как некий "I/O менеджер" исходники надо показывать в обязаловку.

Я не первый год в программировании, но у меня даже не идей что такое "I/O менеджер"

[ViKo 1]

Писать надо туда, где больше заработаешь.

А I/O менеджер и менеджер коммуникаций звучат слишком похоже.

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

А как разобьешь на файлы-папки, как назовешь, так и поплывешь-попрограммируешь.

[iosifk 3]

Не статью писать надо, а в github.com постить.

Да нет, у каждого издания свои читатели.

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

А для чего нужны статьи я написал в КиТ №11 за 14 год. Они нужны не для того, чтобы все знали о том как писать программы для... А для того, чтобы получать приличную зарплату.

[zltigo 2]

Нынче так - или вы показываете свои сорсы на github-е или ваши слова про программирование малого стоят.

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

Когда говорят о такой запредельной абстракции как некий "I/O менеджер" исходники надо показывать в обязаловку.

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

[iosifk 3]

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

Вы не правы.

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

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

[Укушенный воблой 0]

и многочисленные switch/case, if/else как виноградные гроздья начали обрывать ствол программы под своей тяжестью.

На самом деле "многочисленные IF/ELSE (SWITCH/CASE)" - это фундаментальная проблема программирования которая пока никак не решена. Даже в том же пресловутом ООП.

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

 

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

Хотя отдельные попытки предпринимаются.

[ViKo 1]

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

Хотя отдельные попытки предпринимаются.

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

[Укушенный воблой 0]

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

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

Рецепт из серии - если у Вас болит зуб - прищемите палец дверью...

 

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

Это по Вашему хорошее решение?

Типа "болит голова - ампутируем голову"?

Изменено 6 января, 2017 пользователем Укушенный воблой

[syoma 1]

А I/O менеджер и менеджер коммуникаций звучат слишком похоже.

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

 

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

 

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