Мегу тоже надо исключать , там идут кракозябры не понятно откуда ,так что только для разбери стм .ecoins писал(а): 26 июл 2025, 16:321.Сразу о недостатках нового дисплея - пока он занимает много памяти, для AVR328 ощутимо, на MEGA2560 отлично.
Общие размышления о FLProg
-
- Подполковник
- Сообщения: 1208
- Зарегистрирован: 14 фев 2016, 14:16
- Откуда: kazahstan
- Благодарил (а): 46 раз
- Поблагодарили: 7 раз
Re: Общие размышления о FLProg
- Dryundel
- Полковник
- Сообщения: 2614
- Зарегистрирован: 22 май 2017, 23:15
- Откуда: Ярославль
- Имя: Андрей
- Благодарил (а): 25 раз
- Поблагодарили: 230 раз
Re: Общие размышления о FLProg
Общие размышления о новой мнемонике.ecoins писал(а): 25 июл 2025, 11:51 Постепенно внедряется мнемоника более близкая к C++.
v1 - bool;
v8 - байт, int8_t, uint8_t;
v16 - integer, int16_t, uint16_t;
v32 - long, unsignedLong, int32_t, uint32_t;
С уважением, ecoins.
Я всегда ЗА стандартизацию. И это здорово, что идут подвижки в этом направлении.
Поразмыслив на эту тему, для себя пришёл к неоднозначному выводу.
С одной стороны идея применять v1, v8, v16... наверное правильная. И на входе и на выходе оно приемлемо. Понятно что на входе всегда value а на выходе всегда variable. Однако у int32_t и uint32_t есть существенная разница. Наверное в последнем случае можно применять u1, u8, u16... В этом случае визуально понятно, что на вход u16 не стоит подавать v16 и наоборот, хотя возможно. С float и String можно поступить подобным образом. И было бы не плохо опубликовать тогда принятые стандарты.
Но тахой подход хорош когда у блока есть один вход и один выход. В случае когда входов хотя-бы два, становится совсем не понятно который за что отвечает. В этом случае без авторской мнемоники не обойтись. В любом случае, наверное лучше если вход будет обозначен к примеру (x) а выход sin. При таком варианте вообще не требуется пояснения что блок делает, что куда подавать и откуда брать.
А как быть когда у блока много входов? Ну к примеру 16. На входе value, пишем - v1, v2, v3, v4, v5, v6, v7, v8, v9, v10, v11, v12, v13, v14, v15, v16. Возникает некоторый диссонанс.
Короче говоря, не просматривается пока однозначность прихода к общему стандарту мнемоники. По моему мнению он скорее она навредит, чем поможет.
-
- Полковник
- Сообщения: 4091
- Зарегистрирован: 12 фев 2016, 11:40
- Откуда: Шатура
- Имя: Энвер
- Благодарил (а): 150 раз
- Поблагодарили: 182 раза
Re: Общие размышления о FLProg
Иногда кажется, что Вы всегда говорите "нет" всему, с чем Вы впервые соприкасаетесь в FLProg.Dryundel писал(а): 28 июл 2025, 14:41Общие размышления о новой мнемонике.ecoins писал(а): 25 июл 2025, 11:51 Постепенно внедряется мнемоника более близкая к C++.
v1 - bool;
v8 - байт, int8_t, uint8_t;
v16 - integer, int16_t, uint16_t;
v32 - long, unsignedLong, int32_t, uint32_t;
С уважением, ecoins.
Я всегда ЗА стандартизацию. И это здорово, что идут подвижки в этом направлении.
Поразмыслив на эту тему, для себя пришёл к неоднозначному выводу.
С одной стороны идея применять v1, v8, v16... наверное правильная. И на входе и на выходе оно приемлемо. Понятно что на входе всегда value а на выходе всегда variable. Однако у int32_t и uint32_t есть существенная разница. Наверное в последнем случае можно применять u1, u8, u16... В этом случае визуально понятно, что на вход u16 не стоит подавать v16 и наоборот, хотя возможно. С float и String можно поступить подобным образом. И было бы не плохо опубликовать тогда принятые стандарты.
Но тахой подход хорош когда у блока есть один вход и один выход. В случае когда входов хотя-бы два, становится совсем не понятно который за что отвечает. В этом случае без авторской мнемоники не обойтись. В любом случае, наверное лучше если вход будет обозначен к примеру (x) а выход sin. При таком варианте вообще не требуется пояснения что блок делает, что куда подавать и откуда брать.
А как быть когда у блока много входов? Ну к примеру 16. На входе value, пишем - v1, v2, v3, v4, v5, v6, v7, v8, v9, v10, v11, v12, v13, v14, v15, v16. Возникает некоторый диссонанс.
Короче говоря, не просматривается пока однозначность прихода к общему стандарту мнемоники. По моему мнению он скорее она навредит, чем поможет.
1.Затронутая тема исследовалась несколько лет.
2.Перепробованы были несколько вариантов. Когда задумываешь одно представляется, когда делаешь и потом испытываешь, эксплуатируешь - начальные представления меняются, порой значительно. FLProg предоставляет много возможностей, но он же накладывает и ограничения. В случае с пользовательскими блоками - они свои.
3.Если несколько входов. Посмотрите как в "Кандидатах" реализованы блоки из раздела "КОНВЕРТАЦИЯ переменных" - и часть вопрос отпадет.
--------------------------
Не пробуйте втянуть меня в дальнейшее обсуждение этой темы.
------------------------
"Те кто говорит, должны действовать,
и только те, кто действуют,
должны говорить."
Нассим Николас Талеб.
- Dryundel
- Полковник
- Сообщения: 2614
- Зарегистрирован: 22 май 2017, 23:15
- Откуда: Ярославль
- Имя: Андрей
- Благодарил (а): 25 раз
- Поблагодарили: 230 раз
Re: Общие размышления о FLProg
Посмотрел. И что я вижу? А вижу я то, что Вы поступили именно так, как я и писал выше.ecoins писал(а): 28 июл 2025, 15:13 3.Если несколько входов. Посмотрите как в "Кандидатах" реализованы блоки из раздела "КОНВЕРТАЦИЯ переменных" - и часть вопрос отпадет.
Где ваша мнемоника v1 - bool; ? Оказывается я был прав. Оказывается не везде прокатывает Вами же обозначенный стандарт v1 - bool;

Или это "другое" ?
==============================
«Жизнь есть не что иное,
как постоянно побеждаемое противоречие»
(Иван Сергеевич Тургенев)
У вас нет необходимых прав для просмотра вложений в этом сообщении.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя