Перейти к блогу GetChip.net - блог        JilTE[1] - в разработке     Модификации устройств - модификации

 
Текущее время: 23 сен 2019, 08:49

Часовой пояс: UTC + 3 часа [ Летнее время ]



Начать новую тему Ответить на тему  [ Сообщений: 17 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Предложения по улучшению Тюнера
СообщениеДобавлено: 27 сен 2013, 19:38 
Не в сети
Администратор
Аватара пользователя

Зарегистрирован: 15 май 2011, 23:00
Сообщения: 1929
Любые пожелания


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Предложения по улучшению Тюнера
СообщениеДобавлено: 29 сен 2013, 00:57 
Не в сети

Зарегистрирован: 20 май 2011, 23:58
Сообщения: 1
Предлагаю окно сценария сделать в виде древовидного списка, как, например, в программе EventGhost. Т.е. элемент первого уровня - это событие, а элементы второго уровня - действия на это событие. Тогда отпадет необходимость в пунктах "конец микропрограммы/сценария".


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Предложения по улучшению Тюнера
СообщениеДобавлено: 29 сен 2013, 05:36 
Не в сети
Аватара пользователя

Зарегистрирован: 03 июл 2011, 13:55
Сообщения: 108
Откуда: Томск
В этом направлении работа уже идет. Спасибо за отзыв!


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Предложения по улучшению Тюнера
СообщениеДобавлено: 29 сен 2013, 12:10 
Не в сети
Администратор
Аватара пользователя

Зарегистрирован: 15 май 2011, 23:00
Сообщения: 1929
Посмотрел EventGhost - действительно интересно реализовано.
Со списком EventGhost проще, там событие одно, а у нас событие может быть составное.

Например:

V Событие от клавиши
V Событие от таймера
^ Действие светодиод
Х Конец микропрограммы

Нажал клавишу и по прошествии времени загорелся светодиод.

А вот упаковать микропрограмму в один пункт списка и этот пункт раскрывать/закрывать - это уже другое дело и над этим стоит подумать.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Предложения по улучшению Тюнера
СообщениеДобавлено: 30 сен 2013, 21:08 
Не в сети
Аватара пользователя

Зарегистрирован: 12 фев 2012, 22:25
Сообщения: 74
Давно не заглядывал а тут ТАКОЕ!!! Молодцы. Но это из лирики. Из того, что первое приходит в голову - это НЕ всегда линейный алгоритм Событие-Действие. На практике почти ВСЕГДА между этими понятиями живет УСЛОВИЕ.

Например.
Хотим закрыть шторы на окнах. Как будто все очевидно. Нажали кнопку (событие1), устройство начало закрывать штору(действие1) и опрашивать концевик (событие2) чтобы остановиться (действие2). А если само окно в этот момент открыто (условие1)и мы хотим получить от устройства не закрывания шторы в этом случае, а сигнал об открытом окне(действие3)? В этом случае уже на событие 1 нам нужна реакция не как действие 1, а как действие 3, потому, что есть условие 1.

Автомобильная сигнализация ярчайший пример каскадируемых ЕСЛИ. Если в момент нажатия на кнопку постановки под охрану дверь авто была открыта, то эта линия не берется под охрану, если датчик движения срабатывал, то охрана включается с задержкой, если включен бесшумный режим, то она отвечает только световой сигнализацией и т.д. И набор вариантов ДЕЙСВИЕ многообразен в зависимости от условий и к каждому из них можно "прибежать" всего от одного события но в зависимости от разных условий.

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

Мне кажется нужно"на берегу" осознавать что проект Zichip это по сути микропроцессорный компилятор примитивного языка программирования. Создав минимальный набор команд языка и написав для них программу обработчик на МК мы по сути и получим то, что хотим.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Предложения по улучшению Тюнера
СообщениеДобавлено: 30 сен 2013, 22:28 
Не в сети
Администратор
Аватара пользователя

Зарегистрирован: 15 май 2011, 23:00
Сообщения: 1929
Kolini писал(а):
Хотим закрыть шторы на окнах. Как будто все очевидно. Нажали кнопку (событие1), устройство начало закрывать штору(действие1) и опрашивать концевик (событие2) чтобы остановиться (действие2). А если само окно в этот момент открыто (условие1)и мы хотим получить от устройства не закрывания шторы в этом случае а сигнал об открытом окне(действие3)? В этом случае уже на событие 1 нам нужна реакция не как действие 1, а как действие 3, потому что есть условие 1.

Ух, задача завернута :crazy: !

Самая главная идея ZiChip - это дать конечному пользователю возможность сделать все что он сам захочет!
ZiChip позволяет для каждого отдельного устройства в сети иметь свой отдельный "язык программирования"!
Поэтому мы сможем сделать все.
В ветвлении есть свои плюсы, но главный и большой минус - это повышенный расход EEPROM. Но в общем это просто реализовать.

Ну а по поводу окошка, я так вижу решение без ветвления:
Цитата:
V Событие: кнопка (закрытие шторы)
V Событие: концевик шторы (пока не нажат (шторы открыты) - разрешать действие)
V Событие: концевик окна (пока нажат (окно закрыто) - разрешать действие)
^ Действие: привод шторы (закрытие штор)
Х Конец микропрограммы

V Событие: кнопка (закрытие шторы)
V Событие: концевик окна (не нажат (открытое окно) - разрешить действие)
^ Действие: сигнал ("окно открыто")
Х Конец микропрограммы

* события складываются (умножаются?) по принципу логического "И" (что и создает те самые "УСЛОВИЯ")
Выглядит вполне логично - разделены действия привода и сигнала в отдельные микрпрограммы. Пока Вы меня не убедили в критичности ветвлений. И, к стати - это хороший пример для демонстрации работы зичип.

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

Вы правы по поводу того, "что проект Zichip это по сути микропроцессорный компилятор примитивного языка программирования" - это действительно так. Но этот "язык" может быть для каждого устройства свой, поэтому совсем не критично если, например, на начальном этапе разработки мы не предусмотрим какой либо элемент - все в процессе можно добавлять.

И Вы опять правы :) - все таки желательно иметь изначально минимальный набор команд и принцип строения алгоритма, хотя-бы для того чтобы было проще понять друг друга при обсуждении реализации чего-то


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Предложения по улучшению Тюнера
СообщениеДобавлено: 02 окт 2013, 09:17 
Не в сети
Аватара пользователя

Зарегистрирован: 03 июл 2011, 13:55
Сообщения: 108
Откуда: Томск
Меня не отпускает мысль реализовать сценарий в графическом виде, как обычную схему.
Для вашего варианта:
Kolini писал(а):
Хотим закрыть шторы на окнах. Как будто все очевидно. Нажали кнопку (событие1), устройство начало закрывать штору(действие1) и опрашивать концевик (событие2) чтобы остановиться (действие2). А если само окно в этот момент открыто (условие1)и мы хотим получить от устройства не закрывания шторы в этом случае, а сигнал об открытом окне(действие3)? В этом случае уже на событие 1 нам нужна реакция не как действие 1, а как действие 3, потому, что есть условие 1.


я попытался изобразить свою мысль:
Вложение:
1.PNG
1.PNG [ 29.69 КБ | Просмотров: 4035 ]


Сложность в самом редакторе у меня не достаточно знаний для реализации такой сложной штуки :(

P/S Оценочно, потребление памяти для данной схемы 39 байт EEPROMа, т.е. в среднем 4 байта на элемент.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Предложения по улучшению Тюнера
СообщениеДобавлено: 07 янв 2014, 18:49 
Не в сети
Аватара пользователя

Зарегистрирован: 03 июл 2011, 13:55
Сообщения: 108
Откуда: Томск
Предложения по улучшению тюнера (для версий позже 0.23) (о чем мы говорили по скайпу)

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

П.С. Нужно как-то баг трекер поднимать что ли. Я помню смотрел мне больше redmine ни чего не понравилось. Есть предложения ?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Предложения по улучшению Тюнера
СообщениеДобавлено: 15 апр 2014, 18:38 
Не в сети

Зарегистрирован: 11 апр 2014, 10:51
Сообщения: 6
есть маленькое пожелание:
кнопку приделать в программе,чтобы она (прога) разворачивалась на весь экран сама .
как у всех браузеров (свернуть,развернуть на весь экран и закрыть)
а то на мелких нетбуках как то масштабируется коряво,всегда пол программы уезжает за пределы экрана.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Предложения по улучшению Тюнера
СообщениеДобавлено: 16 апр 2014, 12:27 
Не в сети
Администратор
Аватара пользователя

Зарегистрирован: 15 май 2011, 23:00
Сообщения: 1929
Пока функция "развернуть на весь экран" не предвидится по причине того, что контент окон жестко закреплен на своих местах и будет распадаться при попытке менять размер окон.
Но уже версия Тюнера над которой я сейчас работаю, запоминает положения своих окон и при последующих запусках будет их открывать в удобных для Вас местах.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 17 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB