Путь развития программы. ч2.

[findeler]

В последнюю неделю плотно занялся написанием программы.

А последних три дня провозился с глюком в работе блока 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. Но я вынужден городить монстра.

Вообще я к чему это. Блоки пользователя (что есть) и код программы очень сильно отличаются по структуре и принципу написания. В итоге это глюк на глюке. Научить писать согласно принципам языка, это сложно. Но можно серьёзно подтолкнуть к этому, введя ограничения на "неправильный" код.

С уважением Павел.

[Слимпер]

1
а) не вижу особого смысла, и так нормально можно пользоватся.
б) это да было бы полезно
в) согласен 
От себя добавлю. Добавить папки для деления переменных по логике программы.   

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

3. Согласен.

4. В общем согласен, подобное описывал в прошлой теме. 

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

6. Тут и правда нужно наводить порядок, но думаю лучше пока ограничится порядком на форуме, нагружать еще и авто обновление блоков программу не стоит.  
К тому же многие блоки сейчас выкладываются вез нормального описания и за чистую далеки до оптимальности.  

8. Тут лучше тогда уже реализовать вложенность. Т.е. при создании пользовательского блока можно использовать другие пользовательские блоки, притом на любом языке.

Есть пользовательский блок модем M590 но написан он жутко, тормозит всё и вся.

Так к слову я недавно писал пользовательский блок на си для этого модуля. Там уже задержек нету.  

[findeler]

не вижу особого смысла, и так нормально можно пользоватся.

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

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

я имел виду параметры таких блоков как nextion, и пр. работающих с периферией, которые имеют скрытые связи . К блокам базовой логики вопросов нет. Если только добавить для тех же таймеров и генераторов отображение времени на схеме , и типа генератора.

Такой вариант можно будет обдумать только после коренной переделки редактора пользовательских блоков.

Именно так, я именно это и считаю перспективой, тянуть самому не реально.

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

Конечно единицы, проще просить что бы Сергей сделал, (о чём я и писал). Но вот опять же пример который я привёл в поиске глюка в блоке nextion. Смог бы поймать его Сергей ? Если у него нет той же модели дисплея как у меня, вполне возможно, что он бы его не увидел.

Добавлено (22.08.2016, 15:45)
---------------------------------------------
Путь один, расширять круг людей которые смогут делать прилично.

6. Тут и правда нужно наводить порядок, но думаю лучше пока ограничится порядком на форуме,

Ну я написал к чему стремиться. А пока достаточно ветки форума, с единым стандартом описания чего и как может блок. Но начинать надо. Вот к примеру вы сами сказали что модем сделали. А где он ? Я получается занимаюсь бестолковой работой. Кстати дайте пожалуйста блок.

8. Тут лучше тогда уже реализовать вложенность.Т.е. при создании пользовательского блока можно использовать другие пользовательские блоки, притом на любом языке.

Ни в коем случае, это же принцип библиотек. Требует высочайшего уровня их "вылизанности" . Иначе здравствуй ошибки которые хрен найдёшь.
С любым языком думаю тоже не получится. Работа идёт через ардуино IDE, поэтому только СИ.

[Слимпер]

Вот к примеру вы сами сказали что модем сделали. А где он ?

Ну он пока на тестировании, и возможной доработки, вот и не выкладывал. 
А тема Блок пользователя для работы с GSM.
На последних страницах есть рабочий и проверенный вариант. Например последний вариант есть в сообщении 261.
Я его две недели переделывал, версий было несколько десятков. Вот и не выкладываю, жду когда все глюки выловят.

Добавлено (22.08.2016, 16:03)
---------------------------------------------

С любым языком думаю тоже не получится.

Ну я имел виду блоки на FBD, LAD, Си. В промышленных средах довольно часто можно стандартные и самописные блоки размещать внутри других.
И там часто можно посмотреть как устроены блоки и даже создав копию редактировать ее.
 
А в некоторых вообще можно свернуть выбранный участок программы и получить из него ка бы макрос.

[findeler]

Ну он пока на тестировании, и возможной доработки, вот и не выкладывал.
А тема Блок пользователя для работы с GSM.
На последних страницах есть рабочий и проверенный вариант. Например последний вариант есть в сообщении 261.
Я его две недели переделывал, версий было несколько десятков. Вот и не выкладываю, жду когда все глюки выловят.

Спасибо.

Кстати хорошая иллюстрация почему блоки долен делать не автор. 3 недели, десятки версий, откуда ему взять лишнее время даже на один блок.
Раз уж работает один то надо пилить основной функционал и саму работу программы. Дай бог на них хватило бы времени.

Добавлено (22.08.2016, 16:11)
---------------------------------------------

у я имел виду блоки на FBD, LAD, Си. В промышленных средах довольно часто можно стандартные и самописные блоки размещать внутри других.

там да, но у того же сименса они "отлизанны" до зеркального блеска.
В этом языке такими блоками условно считается базовый функционал, включать сюда пользовательские блоки на их текущем уровне, прямой путь к глюк на глюке. Поэтому я и предлагаю FBD+Cи. (Беспроблемные блоки + локальное своё)

[rw6cm]

Будь код открытым (пользовательский блок) я бы исправил ошибку, дописал функционал, и выложил для дальнейшего пользования. А так ?

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

[findeler]

Врятли Автор сможет сделать всю периферию в виде пользовательских блоков на Си ли другом языке отличным от Смолтока.

А ему и не надо если сложно, сейчас весь код можно взять из скетча.
К примеру я уже сейчас могу переложить его код для nextion, scanonware db18x2x на обычный СИ. Там же по сути всё примитивно.

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

Вот именно поэтому это надо отдавать на откуп. Постепенно новые пользовательские блоки заменят его эксклюзивные, а со временем их можно будет удалить из базовых.

[rw6cm]

К примеру я уже сейчас могу переложить его код для nextion, scanonware db18x2x на обычный СИ. Там же по сути всё примитивно.

А что мешает? Делайте выкладывайте. Знатоков Си здесь нет. Все вам только спасибо скажут.
Многие на ваших примерах будут учится делать свои. Автор и дал нам для этого удочки,
еще бы кто нибудь научил на них рыбу ловить

[findeler]

А что мешает? Делайте выкладывайте. Знатоков Си здесь нет. Все вам только спасибо скажут.
Многие на ваших примерах будут учится делать свои. Автор и дал нам для этого удочки,
еще бы кто нибудь научил на них рыбу ловить smile

Ничего не мешает, что я сейчас и делаю. Я же не могу ждать неизвестное количество времени пока автор исправит ошибку, и исправит ли.

Не хватает нормальных инструментов, я почему написал, про переменные, и что нужен FBD+СИ что бы блоки соответствовали принципам программы. Для примера я сейчас разбираюсь в коде таймера Сергея , для того что бы интегрировать его в блок, и убрать delay. То есть привести блок к принципам программ для автоматики. Но ещё и с переменными беда.

Или вон Слимпер сделал блок для модема.

В целом я про то и пишу, не надо терять время не периферию, да и функционала в общем уже более чем.

[dekorator]

нужен FBD+СИ

Нет, невозмётся он за это. Это ему весь проект заново переделывать придётся. Блоков действительно почти достаточно, надо только довести до ума те которые уже есть, чтобы чётко всё работало.
Не тратить много времени на пиар. Качество продукта сделает себе достойное имя.
Перемнные, входы, выходы в боковую панель - отличная мысль.
Пользовательский блок на чистом С, убирать не надо. Его надо доработать немного, чтобы при желании переменные и массивы созданные в нём, были доступны ( при желании ) в основном проекте.
Поднимался вопрос по поводу поседовательности выполнения блоков ( не плат). Может имеет смысл добавить порядковый номер очереди исполнения блоков? Это придаст определённую логическую упорядоченность результирующему коду. И с прерываниями разобраться уже.

[findeler]

Нет, невозмётся он за это. Это ему весь проект заново переделывать придётся.

Странно. Я почитал немного об этом языке, он полностью объектный. Мне кажется это там как раз элементарно сделать.

Не соглашусь, про пеар. Сейчас он реально крайне необходим, иначе можно упустить время. Нужно выходить на широкий круг, пользователей.

Поднимался вопрос по поводу поседовательности выполнения блоков ( не плат). Может имеет смысл добавить порядковый номер очереди исполнения блоков?

Как я понял это не возможно, в силу что код строит интерпретатор, и где в результате оптимизации окажется блок не ясно. Да и по большому счёту я бы вообще запретил использование в одной плате переменные несколько раз. Здесь скорее подход FBD языков для промконтроллеров нужен. слева входы/переменные источники справа выходы/переменные записи. Очень структуирует написание программы. Да и от всяких косяков в виде неправильной последовательности спасает.

[dekorator]

Сейчас он реально крайне необходим, иначе можно упустить время. Нужно выходить на широкий круг, пользователей.

Это для чего крайне нобходим? Какое время упустиь? Конец близко уже?
Вам известно что-то? Только желтая пресса не всчёт.

[findeler]

Это для чего крайне нобходим? Какое время упустиь? Конец близко уже?
Вам известно что-то? Только желтая пресса не всчёт.

Упустит время, не сможет нормально развиться, и почит в бозе, как многие другие. Не первый не последний.