В последнюю неделю плотно занялся написанием программы.
А последних три дня провозился с глюком в работе блока nextion. Удалось найти и локализовать проблему, а так же придумать решение её обхода.(6 тем в багтрекере)
Но речь о другом.
Эта ситуация хорошо показывает, тупиковость направления внутренней (закрытой) реализации датчиков, дисплеев, да и вообще любой внешней периферии. Ведь скорее всего ошибки то нет. И повтори Сергей мою ситуацию у него всё может работать. Всё потому что у него дисплей будет другой модели. И у него эта ошибка просто не проявится. http://forum.flprogwiki.ru/viewtopic.php?f=5&t=1268
И проще говоря, что дальше ? Исправит ли автор ошибку? если исправит то когда? а если найду ещё? а если надо доработать функционал? (В версии Nextion editor 0.37 появились новые элементы). Будь код открытым (пользовательский блок) я бы исправил ошибку, дописал функционал, и выложил для дальнейшего пользования. А так ?
Всё таки, Сергей вы в одиночку не потянете периферию. Я повторюсь конечно, но вся ветка путь развития программы забита "дай, дай, дай" и каждому своё. Мне сейчас нужно nextion, и Gprs, кому то вай-фай и can, кому то... имя жаждущим легион. Я всё таки абсолютно уверен, что периферию надо отдавать на откуп пользователям. Вы сделали образец, показали направление, а дальше уже сами.
Для примера. Сейчас я бы уже мог не только расширить функционал блоков nextion, но и сделать их более удобными (как мне кажется). А чьим блоком пользоваться, это бы каждый решал для себя сам.
А теперь общие предложения выводы из работы.
1. Переменные.
а.) Убрать разделение на входы выходы переменные. (Всё равно имена должны быть уникальными). Оставить только переменные, Но каждая переменная может быть как входом/выходом, так и eeprom. Естественно с ограничениями что пременная выхода выход не может быть не булевой, с выхода нельзя прочитать состояние, массив не может быть выходом... и.т.д.
б.) Добавить сортировку переменных по имени, типу (bool, int,...) назначению(вход/выход), флагу (eeprom)
в.) Добавить в переменные массивы.
2.) Убрать внутренние настройки блоков. Что я хочу этим сказать. Внутренние настройки убивают логичность представления программы и логику, то есть например.
a.) Блок "Nextion get attr" он имеет только 1 выход, и понять глядя на него что, как, и откуда он берёт нереально, надо заходить внутрь. Если бы этот блок имел те эе самые входы (port, page, id, ....) было бы и нагляднее и удобнее.
Так же можно было бы реализовать изменение входных параметров.
б) блок "scan_on_ware" имеет по идее 2 выхода, первый состояние, второй массив адреса. (Но массива не видно)
в.)блок ds18x2x имеет 4 входа (адрес,разрешение опроса,паразитное питание,время опроса) Но они скрыты, и не доступны динамическому изменению.
Что самое в этом плохое, скрытые настройки создают неявные связи, что негативно сказывается на логичности построения программы.
3. Интерфейс области переменных.
Убрать область переменных с верху на боковую панель. Аргументация простая,
а.)сейчас большинство мониторов широкоформатные, слева справа места более чем.
б.)переменные удобнее просматривать списком (вертикально).
4. Интерфейс основного окна.
Убрать раскрытие плат на основной странице, а все платы загнать в дерево проекта.
а.) Сейчас программа прилично тормозит при 40-50 блоках в плате.
б.) Платы "кушают" рабочую область.
5. Сделать все блоки периферии в виде пользовательских. Аргументация такая:
а.) У вас просто не хватит сил реализовать все функции, и УБРАТЬ ГЛЮКИ для элементов периферии, об этом я написал вначале.
б.) Автоматически решается п.2 (программа становится более логичной)
в.) становится очень легко модернизировать, и улучшать функционал. Старый пример часы 1307 и 3231, будь блок доступным, уже бы давно реализовали все возможности, а не забивали бы "хочу" форум.
в.) формально уже сейчас написано много пользовательских блоков которые успешно работают.
Добавлено (22.08.2016, 12:38)
---------------------------------------------
6. Сделать репозиторий пользовательских блоков.
Сейчас они в беспорядке, выложено их мало, да собственно и нет никакого механизма выкладки их. Доступ к репозиторию желательно сделать из программы. как и проверку апдейтов версий блоков.
7. Отказаться от использования delay и циклов с неявным условием выхода.
а.)delay. Хороший пример тот же некстион. Вернее та проблема что я описал. Если использовать delay, то просто опрос 100 кнопок в nextion будет занимать 10 секунд ! т
б.)цикл с условием выхода, собственно сам по себе он вполне допустим, но с обязательным дополнительным безусловным критерием выхода. Как показывает практика, такие циклы самый быстрый путь к зависанию программы.
Причём, на сколько я понял, в базовых блоках и так нет никаких задержек и циклов. Все они начинают вылазить в периферии.
8. Добавить в стандартные блоки блок кода на C. и убрать пользовательский блок на чистом С.
Это позволило бы создавать пользовательские блоки смешанной структуры FBD + C LAD + C. И они были бы той же структуры что и код генерируемый языком.
Блоки на С должны иметь ограничения на использование некоторых операторов и функций. (delay, циклы с условием, вызов функций, использование библиотек, и.т.д.)
Приведу пример. Есть пользовательский блок модем M590 но написан он жутко, тормозит всё и вся. Я пытаюсь переписать на языке FBD, как раз что бы избавится от мега-задержек и реализовать беспроблемную работу. Но кое какие мини операции много проще написать на С чем городить монстра в FBD. Но я вынужден городить монстра.
Вообще я к чему это. Блоки пользователя (что есть) и код программы очень сильно отличаются по структуре и принципу написания. В итоге это глюк на глюке. Научить писать согласно принципам языка, это сложно. Но можно серьёзно подтолкнуть к этому, введя ограничения на "неправильный" код.
С уважением Павел.
