Страница 1 из 1

Дополнения к блоку CODE

Добавлено: 26.08.2016{, 18:09}
rw6cm
Создавая блоки CODE , сталкиваюсь с большим на мой взгляд не удобством.
Заключается оно в том, что к блоку нельзя подключать  другие блоки увеличивающие его функциональные возможности.
В результате приходится, или делать монстров многоножек ( на все случаи в жизни), которые без полезно съедают место,
или под каждую задачу писать отдельный блок, что в свою очередь лишает  его универсальности.
Предлагаю вариант как это можно исправить. Чтобы много не писать, начну с примера.
Создаю блок  работающий на прерываниях одного из внутренних таймеров ардуины.
В данном случае блок можно использовать в проекте только раз.
Но сколько нужно будет  задач с индивидуальным таймером в этом блоке,  пока не известно (может одна, может десять).
Что бы выйти из этой ситуации нужно всего лишь  разрешить  другому блоку использовать его функцию.
Как я себе это представляю:
В блоке ниже опции «разрешить использовать только один раз» Поставить еще пару чек боксов, Master и Slave.
В блоке мастера создаем все необходимое для полноценной работы блока, но с минимумом требуемых задач.
И допустим рядом с «FunctionSection» будет окошко«MasterSection»
в котором ПКМ можно вставить объявленные переменные или функции, для общего использования с блоками Slave.
В блоке Slave  пишется только задача, расширяющая, или дополняющая функции Mastera, использующая его переменные, или функции.
Чтобы заработал пример ниже,
СпойлерПоказать
нужно всего то удалить созданный блоком Slave дублера функции.

СпойлерПоказать
По сути, он должен дописывать код в уже созданную мастером функцию.
Если это возможно как то реализовать, откроются большие возможности для творчества.

п\с Может кто то еще предложит идеи.
Если кто то захочет повторить данный пример, надо дописать в скетч два номера описанные здесь

Дополнения к блоку CODE

Добавлено: 27.08.2016{, 19:03}
Слимпер
Я как раз сейчас тоже обдумывал подобное предложение.
Связанные блоки.
Блоки функции и переменные которых могут быть использованы друг другом.

В редакторе блока добавить галочку "Блок Связан" и поле "Идентификатор Связи".
Если два блока связаны, то в обоих должны стоять эти галочки и выставлен одинаковый идентификатор.
Тогда у всех  переменных и функций суффикс (окончание добавляемое при генерации кода) будут одинаковый, а значит можно будет оперировать функциями из другого блока.

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

Дополнения к блоку CODE

Добавлено: 28.08.2016{, 08:15}
rw6cm
Слимпер писал(а):Не совсем удобно, так как не будет корректно работать подстановка вызова функций через правую кнопку мыши.
Здесь вроде проблем не должно быть. В разделе функций должна быть кнопка, рядом с "создать новую",
кнопка "вставить из ...", и тогда по ПКМ будет видна.
Слимпер писал(а):Если два блока связаны, то в обоих должны стоять эти галочки и выставлен одинаковый идентификатор.
Не совсем понимаю зачем, даже если они будут разные проблем не вижу,

Дождемся Автора, что он скажет, возможно ли это вообще, и в каком направлении рассматривать возможные варианты.

Дополнения к блоку CODE

Добавлено: 29.08.2016{, 05:48}
Слимпер
Еще добавлю, нужен какой то механизм, чтобы была возможность прописать в настройках блока, что блок занял такие то пины. Т.е. указали, что пин занят, он должен стать недоступен в остальных частях проекта FLProg.
А то уже не раз были накладки из-за этого.

Как это лучше реализовать, сложно сказать. Но так как выбор используемого пина может быть задан через параметры, то тут должна быть связь.
Должно быть два вида объявления занятости пина:
1. Пин занять статично, т.е. не может быть заменен. Устанавливается автором блока. В Параметрах блока отображается, но  не редактируется.
2. Пин задается пользователем при настройки блока через параметры. Возможно надо сделать новый тип параметра "Используемый пин". Для кода внутри блока, обычно число (которое напрямую подставляется в код).
А FLProg должно интерпретировать его как занятый пин.

Возможно, можно объединить пункты 1 и 2, добавив типу параметра  "Используемый пин", галочку статически (недоступен для выбора пользователем).

Есть еще проблема с тем, что при объявлении некоторых функций и тем более использовании библиотек, пины объявляются неявно, как бы по умолчанию. Или в зависимости от какого то текстового параметра. Например использование компорта объявляется Serial2, что значит будут заняты пины 16,17. Или еще недавно пробовал использовать компаратор, оказалось, он занимает пиры D6,D7.

Я пока не вижу варианта реализации таких настроек, кроме отдельного поля (области, закладки) где, на каком то упрощенном языке можно указать эти закономерности. Но этот код должен влиять только на то как FLProg  будет компилировать исходный код.
Например смысл такой: Если параметр "Порт1"=2 то в заняты пины D16, D17, если "Порт1"=3, то заняты пины D14, D15.

А вообще сейчас подумал, что таким скриптовым языком ( развив идею) можно очень сильно расширить возможности при написании блока. Вплоть до включения/исключения участков кода и/или входов/выходов блока. Но это в перспективе, если это реализуем.

П.С. Пока писал, много новых идей возникло. Полезно, однако, переносить мысли на бумагу (в печатный вид).

Дополнения к блоку CODE

Добавлено: 29.08.2016{, 09:05}
rw6cm
Слимпер писал(а):что блок занял такие то пины. Т.е. указали, что пин занят, он должен стать недоступен в остальных частях проекта FLProg.
Нужная опция, и здесь может даже не недоступность пина, а его выделения, допустим цветом.
Допустим есть варианты когда установка на одном пине, меняет работу на других пинах(недоступный ШИМ, другие режимы и т д)
Если бы эти взаимосвязи хоть как то намекались, было бы замечательно.
Слимпер писал(а):Пока писал, много новых идей возникло.
У самого их "пруд пруди" ))
Есть вариант когда много блоков можно объединить одним.
Допустим: компас, акселерометр, гироскоп, барометр, и т д, нужные для определения, что происходит с точкой в пространстве.
Можно было бы объединить одним блоком коде, который связал бы их внутренние функции алгоритмом, и выдал результат.
Если это делать внешними элементами, получится много плат, следовательно куча дополнительных переменных, и связанных с этим не нужных элементов.
А в некоторых случаях вообще не выполнимо, средствами FLProg.

Дополнения к блоку CODE

Добавлено: 20.09.2016{, 10:47}
Слимпер
Обдумывал идею, описанную мню в сообщении номер 2.

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

Сразу оговорюсь, у меня цель отличается от rw6cm.
rw6cm, хочет сделать возможны слияние кода одноименных функций из блоков Мастер и Слейв. При работе с прерываниями идея очень интересная.

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

Необходимые дополнения для ее реализации:
СпойлерПоказать
- В  закладки параметров :
* На вкладке Основные параметры добавить  «Глобальный идентификатор»;
* Добавить вкладку «Глобальные параметры».
-В закладках секций кода добавить:
*Добавить  GlobalDeclare ;
*Добавить GlobalFunction.
Сейчас при генерации кода всем переменным и функциям добавляется уникальный идентификатор (уникальный для блока).
После дополнений, описанных выше, в существующих областях  весть текущий функционал сохраняется.

В поле «Глобальный идентификатор» задаем уникальный идентификатор. При генерации кода, он будет добавляться вместо того, что
добавляется сейчас к :
- Переменным, генерируемым из вкладки «Глобальные параметры»;
- Переменным,  объявленным в GlobalDeclare;
- Функциям, объявленным в GlobalFunction;
Как это может выглядеть

СпойлерПоказать
В Связанных блоках  в полях «Глобальный идентификатор» прописываем один и тот же идентификаторы.

Добавлено (02.09.2016, 09:18)
---------------------------------------------
Тут возможна два варианта реализации механизма определения куда надо подставлять глобальный идентификатор :

-Первый вариант, самый простой.
СпойлерПоказать
Тут будет важнапоследовательность добавления блоков в проект, т.е. Первый блок должен размещаться в проект раньше Второго, второй раньше третьего и т.д.
В Первом объявляем все нужные глобальные параметры, переменные и функции.
Во Втором и последующих блоках повторно объявляем с тем же именами глобальные параметры, переменные и функции (можно пустыми), которые там понадобятся. Можно
так же объявлять и новые глобальные параметры, переменные и функции.
При генерации кода из Первого блока в код переносятся все глобальные параметры,переменные и функции. Из последующих блоков, с идентичными Первому «Глобальным идентификатором», добавляются только новые уникальные (если токовые есть), а  все повторяющиеся  глобальные параметры, переменные и функции отбрасываются.
- Второй, менее удобный при написании кода, так как не будет работать подстановка имен по ПКМ. И как не кажется более сложный к реализации.
СпойлерПоказать
В тех блоках, где надо использовать объявленные в другом блоке  глобальные параметры, переменные и функции, в коде используется  их названия без объявления.

При генерации кода  «Глобальный идентификатор» добавляется ко всем объявленным глобальным параметрам, переменным и функциям, во всех блока.
В других блоках (с указанным идентификатором) всем переменным и функциям, которые не объявлены в этом блоке, также добавляется «Глобальный идентификатор»
При любом из вариантов в одном блоке будет использоваться два вида разных идентификаторов, существующий сейчас, уникальный для каждого блока и второй «Глобальный идентификатор», уникальный для нескольких блоков, объединенных одним функционалом, задаваемый автором блока.

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

Добавлено (20.09.2016, 10:47)
---------------------------------------------
Слимпер писал(а):А вообще сейчас подумал, что таким скриптовым языком ( развив идею) можно очень сильно расширить возможности при написании блока. Вплоть до включения/исключения участков кода и/или входов/выходов блока. Но это в перспективе, если это реализуем.
А вообще оказывается есть Директивы условной компиляции

Вида

#define MAX 10

#if MAX>99
printf("Компилирует для массива, размер которого больше 99.\n");
#else
printf("Компилирует для небольшого массива.\n");
#endif

Использую его можно сделать много интересного например, аппаратно зависимый код.

#if defined (__AVR_ATmega1280__) || defined (__AVR_ATmega2560__)
код только для меги
#endif

#if defined (__AVR_ATmega328P__)
Код только для уны
#endif

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

Что то  в это роде еще бы добавить для настройки входов выходов блока, и вообще будет сказка.

Дополнения к блоку CODE

Добавлено: 20.09.2016{, 14:17}
rw6cm
Слимпер писал(а):Использую его можно сделать много интересного например, аппаратно зависимый код.
Но к сожалению, пока после каждой строчки добавляется уникальный идентификатор.
Этот код можно использовать в библиотеке.
Если посмотреть библиотеку из примера первого топика, она вся сделана на этих директивах.

Дополнения к блоку CODE

Добавлено: 20.09.2016{, 15:12}
Слимпер
rw6cm писал(а):Этот код можно использовать в библиотеке.Если посмотреть библиотеку из примера первого топика, она вся сделана на этих директивах.
Ну я тут колупаю статью Подключаем кучу устройств к Arduino по 5 проводам
Хотел сделать несколько блоков на на ее основе, вот как раз для оптимизации использования памяти, и более широкой возможности настройки блока я и хотел использовать эти директивы, но не получилось, FLProg при их использовании начинает регулярно падать.  

Пока получилось сделать блоки для работы LCD по SPI.

Дополнения к блоку CODE

Добавлено: 27.06.2017{, 06:45}
ecoins
Набрел по ссылке на эту тему.
Полностью, полностью поддерживаю тему.
Спасибо огромное за подробное изложение предложений - буду использовать при создании своих пользовательских блоках.