support писал(а): ↑04.01.2021{, 22:12}
3. Возможно я и займусь этим когда будет возможность.
Приложенный блок (sheduler) автономный. компактный, быстрый и очень простой.
support писал(а): ↑04.01.2021{, 22:12}
4,5. Этим я по возможности занимаюсь, постепенно оптимизирую компилятор.
Вообще это вопрос только библиотек.
По библиотекам Arduino IDE, которые Вы используете в блоках - уверен, что эта плохая идея, они пишутся больше как демонстрационные и потому проект один блок->один проект работают, а чуть сложнее...
Теперь мы внимательно изучаем библиотеки до их использования - неплохие примеры есть, но в массе всё очень плохо.
Пишем свои библиотеки, стараемся предельно аккуратно и документировано - результаты таковы, что даже очень громоздкие проекты "летают". Все библиотеки и проекты исследуются и использованием хороших логических анализаторов.
support писал(а): ↑04.01.2021{, 22:12}
Насчёт команды - все сложнее. Я изучаю наработки пользователей, стараюсь их использовать по мере возможности. Но вот программист я один, и никакой команды именно программистов у меня нет. И вряд ли появится. Я не думаю что среди пользователей программы найдутся программисты на SmallTalk, да ещё и согласные бесплатно поработать. Я честно говоря и сам не хочу исходники публиковать....... Есть опыт во что это выливается. Люди разные бывают..... а потом кашу разгребать не хочется.
Про печальный опыт понятно... На это можно по разному смотреть... С большего временного кол-ва подобного и другого опыта смотрю на это сильно иначе.
Насчет команды программистов.
Представляется, что влазить в SmallTalk на данном этапе и ни к чему. Любопытно, но Вы это делаете и лучше, и с удовольствием, креативно и результативно.
А вот дополнить проекты "правильными" библиотеками прозрачными для пользователей - мне представляется хорошей идеей.
Основная идея разрабатываемых нами библиотек - это программные прерывания (нужна задержка по времени-вышли из функции->через некоторое время(когда планировщик распорядился) сново проверили условия продолжения по времени или по тай-ауту и т.д.).
Аппаратные прерывания почти не используем, чтобы обеспечить совместимость с младшей моделью контроллеров AVR328. Один раз только в библиотеке HC-SR04, чтобы не ждать по времени обратного импульса.
--------------
И еще.
Мне кажется это пережившая время идея поддерживать по большинству функциям контроллер AV328(32k/2k).
Это уже устойчивое "вчера" - и разработчик ATMEL уже пятый год как не существует.
Мы сами много усилий прикладываем к оптимизации использованию переменных - реально удается использовать только 1.5к ОЗУ.
Но наши (именно наши) достаточно большие исследования показали, что в условиях применения С++ приводит и к росту программного кода (уже недостаточно 32к бывает часто), и к ощутимому снижению быстродействия - битовые операции когда их много - понемногу, понемногу накапливают задержки по времени. К слову этого нет на STM32, где битовые операции реализуются на аппаратном уровне.
Именно для экономии памяти операции с пинами на AVR328 дрстаточно медленные (в каждом цикле работы создается несколько временных переменных).
Еще с AVR328 медленны операции со временем (millis() и обработка результатов) - 8-ми битный контроллер медленно работает с 32-разрядными переменными.
И совсем медленно и громоздко работа со строками.
-----------
Представляется, что в настоящее время наиболее перспективными и быстро развивающими являются две ветки - ESP32 и STM32 - там бы и сосредоточить усилия. Порог вхождения немного выше - но и возможности большие.
А на проекты с AVR328 сразу накладывать "оговорки" по ограничениям.
Неплохим контроллером остается Mega2560 - но ограничения по быстродействию заложены в его природе.
=====================
Спасибо за развернутый ответ.
Это пожалуй почти первый случай, когда Вы конкретно отреагировали на наши предложения.
Возможно они Вами обычно воспринимаются как несвоевременными и несколько "туманными" (как и многими участниками форума).
Как результат - мы тратим усилия на обходные пути, достигаем поставленных целей. Но эти же усилия могли быть потрачены более рационально и более способствовать развитию FLProg. Продукт (и еще KaScada) который остается уникальным и по целому ряду свойств существенно лучше традиционных софта для ПЛК (те идеи заложены и почти и неизменны более 3-х десятилетий).
==========================
Спасибо.
