toksoft

64к EEPROM, меня больше волнует оперативка. Мне не разу не удалось заполнить кодом более чем 58к. Что касается ног, у ESP32 их больше. У 8266 конечно меньше. TCA или MCP в общем никто не отменял. Я после AJAX, находясь в состоянии "вечной нехватки реле", всандалил в свою сигнализацию аж 24 шт. Сейчас уже понимаю, что это наверное перебор. На atmega я такие задачи и не думал реализовывать, присматривался с старшим моделям STM. Остановило то, что нужно "доклеивать" много внешней обвески, т.е. схемотехника значительно усложняется. Если CORTEX таки созреет на кристалл, в котором интегрирован хотя-бы ethernet контроллер, я подумаю о том, чтобы вернуться. "Тормоза- выделил 8 бит вместо 16ти на шину экрана" - вы экран путем SPI подключали ? Имеется в виду внутренняя реализация шины дисплея ?

Для float point у меня уже лет 20 как есть свой набор библиотек. Зачем вам float point ? int32_t и int64_t ... Логарифм что-ли лениво в ряд разложить ? Или, в случае например датчиков, хранить уже готовые, предварительно рассчитанные таблицы. На контроллере осмоса например, tds распрекраснейшим образом считается. Что такое "начинаются тормоза" ? Где узкое место ? По стоимости esp32 - 2.5$ за штуку. Я так понимаю, свое время вы в денежном выражении не пересчитываете ? Добавлено через 52 минуты Давайте усложним задачу. Предположим что вам нужно не просто включить светодиод, а изобразить "мигание". Скажем раз в секунду. Учитівая то, что у вас есть другой, не менее приоритетній код который например включает/выключает бойлер. Какие у нас есть варианты? Я вижу слкдующие: 1. RTOS. Потребляет немеряно памяти, но есть практически весь необходимый функционал, включая например mutexes. Оные можно изобразить и без RTOS, но тогда нужно "с головой нырять" в архитектуру. 2. Interrupts. Тоже вариант, но для данного usecase "выбрасывать на ветер" целый interrupt - непозволительная роскошь. 3. Preemptive multitasker. "скармливаем" оному хєндлеры процедур с параметрами, и он их выполняет согласно расписания. Минус - отсутствие блокировок, и относительно быстрое выполнение каждой атомарной процедуры schedulerом. 4. Свой диспетчер задач (concurrent multitasking). В принципе понятно как, но именно этот вариант на STM я не реализовывал

Да, все так и есть. Кроме конечно "сдохнуть". Разобраться в общем можно, но это занимает время. Почему кстати возник вопрос с SPI ? Зачем он вам ? Наверное потому, что дисплеи обычно идут с интерфейсом i2c или spi ? А зачем вам вообще touch screen или несколько больших дисплеев, которые подключены именно к STM (который M3) ? Я подключал маленькие OLED, так, чтобы "поместиться" в 1 иди 2 юнита на DIN рейке. Да, spi это реально быстрее. burst - вообще летает,- единицы миллисекунд успевает отображать. Погодите, а откуда собсно отображать ? Из RAM конечно. Вот так вот целиком брать, и дампить bitmap в дисплей. Быстро ? Летает. Только вот буферизировать нужно. И это на 20к доступного RAM. Как-то не очень ... А зачем собсно использовать младшую модель, когда есть "покруче", скажем с 256к ? Ответ тоже достаточно простой и тривиальный: доступность на локальном рынке, и еще более "утяжеленная" архитектура старших моделей. Плюс энергопотребление. А она ох какая непростая. Как по мне, эту самую младшую модель, целесообразно использовать под цели управления, а отнюдь не в качестве "совмещенного" контроллера интерфейса, тем более графического. В младших моделях доступна память 64 или 128к, часть из которой можно использовать для кода, часть для данных. Никакие внешние приблуды для этого не нужны. По финалу, я использую STM в брелках, как "управляющий кристалл". Там кстати со sleep и прочими технологиями энергосбережения тоже вопросы остались. Ну Ок, частично решаются внешней обвеской. Другого применения именно для этого кристалла я лично не вижу. Если мне "вдруг" понадобиться подключить 2,3 или даже 5 дисплеев, я скорее всего выберу ESP32. 512k RAM (не совсем конечно так, runtime забирает определенную часть, в зависимости от используемых библиотек), переферии на борту даже побольше. ATMEL подходит для менее масштабных задач. У меня кажется осталось пару решений именно на atmel - контроллер осмоса, и контроллер шагового двигателя. Пару кнопок, 2х строчный экран, и как бы достаточно. У меня как бы даже мысли не возникало подключать экран именно к atmel.

IP -> RS-485

unreal1975,- перенес наш спор в отдельную тему. Давайте спорить Жду Ваших аргументов в пользу STM. Желательно подкрепленную фрагментами исходников. Со своей стороны обязуюсь честно рассказать все что я знаю, и поделиться идеями, и готовыми code snippets.

InSAn - если вам не сложно,- можете кинуть ссылку на IP GW имени modbus ? На любой,- хочу чуть поглубже вникнуть.

Таки да. Это уже продукт. Продуктовую линейку планируете расширять ?

Вот именно вопрос про кнопку на одном устройстве, и исполнителя на другом (одном или более) нужно решать перед проектированием. Поскольку система спроектирована именно так, на промышленном протоколе, у которого есть свои ограничения, то с этим придется "жить как есть". Ну или разрабатывать свой "подпротокол". Или выбирать другой. Может конечно подход уже изменился, но в мою бытность, новый продукт "выростал" из use cases. Потом строилась архитектура решения, с выбором протокола и инструментария, а потом уже реализация. Вы выбрали свое решение, исходя из ваших use cases. Мне кажется что это решение вполне самодостаточное. Его (решение) можно наращивать в "горизонтальной плоскости", учитывая специфику выбранного протокола и инструментария. Мое предложение касательно IP GW относилось именно к этому. Не меняя логику работы решения "приростить" некий инструментарий (без которого система по прежнему будет работать), который позволил бы "удлинить" проводное решение, и, возможно, позволит выполнять дистанционное администрирование системы (без необходимости захода на локальный компьютер путем ssh или RDP). В тех сценариях, которые были у меня, я могу например, включить лампочку (или конвектор) в Харькове, находясь при этом в Киеве. Все что для этого нужно - IP сеть. Можно даже без VPN, и "честный адрес" хотя бы на одном конце. Управляющей программе, которая "внутри кубика", совершенно "пофиг" какой транспортный протокол будет "по дороге". Хоть голубиная почта.

Какие годы ? Тут задача приблизительно на 5 m/d. Могу помочь. absolutely free. Из проблем - постановку задачи желательно сделать максимально детальную.

Ясно. Насколько я понимаю, все эти "танцы с бубном" связаны с тем, что slaves пуллапят или пулдаунят шину по какому-то хитрому алгоритму ? Надеюсь что тактируется эта самая шина частотой не менее 100kHz ? Если меньше,- то резонный вопрос "зачем все это" ? Нда, sorry. Только что попробовал "вспомнить" путем google что и как: serial interface. Может его того, в IP инкапсулировать ? Нашел рекомендации: www.honeywellprocess.com/library/support/Public/Documents/51-52-25-121.pdf в общем ничего особо сложного я не вижу.

dip - побойтесь Бога,- какие нафик 200ms ? У меня по воздуху столько не бывает, у тут по проводам ...

Приехали мои корпуса для сенсоров, наконец-то собрал все как и планировал вначале: www.stroimdom.com.ua/forum/attachment.php?attachmentid=636581&stc=1&d=1540148997 www.stroimdom.com.ua/forum/attachment.php?attachmentid=636582&stc=1&d=1540149007 Теперь нужно подбирать корпус для беспроводного температурного сенсора. Еще та задача ... Заказал у китайцев корпуса для подрозетников. Где-то через месяц будут. 2 реле в корпус для подрозетника помещаются, но только на 5А. Блок питания таки пришлось ваять свой, по образу и подобию того, который у меня стоит в 2х юнитовых корпусах. Пытался найти корпуса в подрозетники в Украине - бесполезно. Что на заказ, что в рознице. Морочат голову. Нашел у белорусов, но у них условия не очень гуманные. Такая простая деталь,- и на тебе - дефицит на ровном месте ...

Ну и "вишенка на торте" для понимания того, почему перед использованием STM, нужно очень хорошо подумать "а оно мне нужно ?" Пример инициализации таймера: Это вам не заботливо подготовленными и достаточно простыми wrappers имени arduino team пользоваться. Тут придется разбираться и кодить по взрослому. Да, кристалл продолжает хранить некоторые данные, и считать время, пока он на батарейке, но посмотрите пожалуйста на фрагмент кода, при помощи которого "это" реализуется (в качестве примера): Правда все понятно ? "оно" вам нужно такой ценой ? Разработка какого-либо устройства может потребовать немеряно времени и сил. Как результат, стоимость итоговой разработки, станет сравнимой со стоимостью решений, который продают большие компании. Это на счет советов "atmega плохо, STM лучше". Из того, что я видел на "просторах интернета", большинство копипастит функции, которые кто-то писал для себя, для своих сценариев использования. Скопировали, "засунули" в свой код (иногда даже "не оборачивая"), и радуются пока "оно работает". Как только перестает - фсе ...

Да, извиняюсь за неправильную формулировку. Конечно же контактам катушки. Это аксиома, не подлежащая обсуждению. Можно еще добавить варистор нужного номинала именно на контакты реле, которые на замыкание. Я обычно не добавляю. Рисовать лениво, нашел схему в google, публикую, чтобы было понятнее: https://www.stroimdom.com.ua/forum/attachment.php?attachmentid=636440&stc=1&d=1540064764 Внимание !!! Данная схема приведена только для того, чтобы было понятно как включать диод. Остальные компоненты схемы могут (и будут) меняться в зависимости от того, какое аппаратное решение вы выберите.

InSAn, наверное мои знания безнадежно устарели, но насколько я знаю, такие помехи фильтруются путем диода, включенного в "обратку", параллельно контактам реле. flyback diode. Добавлено через 7 минут unreal1975, не поленитесь изучить документацию под кристалл. Он более чем самодостаточный. Если бы у него был WiFi, то у меня бы и мыслей не возникло использовать что-либо иное. У кристалла есть еще RTC memory (SRAM), которая, при наличии батарейки, сохраняет свое состояние даже при пропадании питания. Я понимаю, что даже без понимания концепта, программу написать можно, но она будет крайне "горбатая". Вас пока спасает то, что никто не делал валидацию кода. На всякий случай, если вы не сможете разобраться самостоятельно (пример): Перед и после, нужно не забыть unlock/lock.

А чем встроенная flash на STM для хранения данных не устраивает ? С 61 по 63 страницу например. Если конечно ваша прошивка все страницы не занимает.

Ага, проходили на STM. Только там можно поставить СR2032. Пробовал сохранять без батарейки. Проблемы следующие: 1. Времянка. Можно успеть, а можно и не успеть, в зависимости скажем от того, замкнуты ли контакты реле или нет (они тоже "тянут" некоторый ток). При худших сценариях - мусор в EEPROM. Я сейчас уже не помню как у atmega, но обычно данные пишутся банками (кусочками). Если "сорвались в штопор" при записи банка - то только перепрошивка 2. Нужно не только свопиться в eeprom, но и предусматривать логику работы всей системы (и, кстати, связанных устройств) типа "по настоящему пропало/восстановилось питание", или "не по настоящему". Запрещать например приемку и обработку внешних events 3. Собьются часы на устройстве. Если устройство представляет из себя "автономный кубик", который работает в том числе по расписанию, то это может оказаться неприятным сюрпризом. При разработке, моделирование этих самых пограничных условий - самая трудоемкая и сложная часть, особенно если устройство не автономно, а часть пусть даже микросети.

Изначально весь проект "пророс" из решений имени Elko, к которым по большому счету претензий нет. Основные модули которые я использовал, были CRM-93H, CRM-2H. Были и радиорешения, такие как RFSG-1M, который устанавливается на DIN рейку, и может командовать другими (совместимыми !) устройствами. Были еще термостаты TER-3xx. Сенсоры которые можно было к ним подключить, были только аналоговые. Еще пару лет назад, такого обилия RF компонент еще не было, сейчас чуть побольше. Есть даже IP Gateway (ссылки ниже). Ссылки: www.elkoep.com/multifunction-time-relay-crm-93h www.elkoep.com/wireless-contact-converter-230v---rfsg-1m www.elkoep.com/wifi-bridge В общем автоматы неплохие, 1 юнит на DIN рейке. Управление - только крутилки. Есть 2х юнитовые типа "программируемые" реле SHT, настенные термостаты для теплого пола DTC, и еще много чего. RF компоненты, еще года 3 назад стоили немалых денег, сейчас например, только один RFSG-1M (а это самый простой из всех), стоит около 3000 грн за штуку. Исполнители - гривень на 500 - 700 дешевле. IP шлюза в Киеве не нашел (может плохо искал ?), но стоит он тоже немало. OASIS - вообще космос по нынешним временам. А чего собственно не хватало, в простых аналоговых (ну или почти аналоговых) девайсах, которые работали бы и по сегодняшний день ? Не хватало следующего: 1. Конфигурировать не крутилкой (отверткой), а через какой-либо интерфейс, при этом не выбрасывая уже имеющиеся устройства, и не покупая всю (или почти всю) новую RF линейку Elko. 2. Мониторинг. Видеть что где включено, какая сейчас активная программа. Тоже в интерфейсе. 3. Управление. Выключить/включить через интерфейс, не подходя при этом к устройству 4. Астрономический календарь (из перечисленных - только у SHT и DTC). остальные (из перечисленных), имеют "относительный" таймер, который начинает отсчет при подачи питания на устройства, и сбрасывается при исчезновении питания. 5. Программы (ежедневная/недельная/месячная). Понятно что в таком form-factorе с управлением и программами сильно не разгонишься, и нужно "выходить на следующий уровень", меняя практически всю уже установленную (и, кстати, не самую дешевую) автоматику на RF. 6. Имеющийся в наличии (CRM-93H) набор программ. Реально, нужно было больше. В некоторых случаях, приходилось устанавливать по 2шт, чтобы получить одну нужную функцию. Вначале (~2 года назад), решил перейти на собственную разработку: STM + LCD, 1 или 2 юнита. В общем получилось неплохо, и продержались мои 10+ устройств почти год. Радиоканала все равно не хватало, ethernet адаптер я попробовал встроить в 2х юнитовый корпус (и так 4 раза), но потом понял что пачка силовых, а с другой стороны пару веток витой пары заходящие в щиток, в общем не очень удобно (еще и хотя-бы какой-то hub нужно запихнуть в щиток). Решил попробовать "а что же будет" если все тоже самое, но только на 8266 ? Кристалл дешевый, надежный, а главное есть встоенный WiFi. Требования у меня были следующие: 1. Конфигурирование через IP (browser, никаких "толстых" клиентов). 2. Управление (оперативное) через IP, без использования чего либо, кроме как обычного планшета/компьютера, с самым что ни на есть обычным browser. 3. Взаимодействие между всеми устройствами "по воздуху", при децентрализованной схеме включения, т.е. без WiFi маррутизатора, к которому подключены все устройства. Можно без IP, в конце концов, это внутренние проблемы устройств, как они между собой общаются. 4. Отсутствие необходимости "обязательно" стучаться в Cloud (как правило vendor specific) Присматривался пару недель,- таки да, на этом кристалле все мои требования реализуемы. Ну значит це макетируем и программим. За 3 месяца была готова 1я версия (таймер,- то что больше всего "болело"). Выбрал я e/f/s модели, с 4mb на борту. Часть под EEPROM, часть под код, часть под файловую систему. Вначале у меня была наивная мысль использовать "готовые" или "почти готовые" библиотеки. Тогда задача действвительно была бы решена меньше чем за месяц. Но ... не сложилось. Пришлось практически с нуля писать свои, благо уже были рабочие библиотеки, "откатанные" на STM. Очень обрадовался тому, что не пришлось "допиливать" LWIP (2.хх) - допилена более чем,- спасибо разработчикам из expressif. Если уже делать,- то "по взрослому". Многопользовательскиий доступ (http), firewall, syslog, схожую с crontab (визуальную правда) систему расписания. разграничение прав, "почти SFT" файловая система, которую я изрядно "подправил", используя открытый код SPIFFS. ext3 конечно не получилось, но я уже и не помню случая, когда бы "лягла" файловая система. Записи, которые были буферизированы в памяти на момент пропадания питания, конечно пропадут, но сама файловая система остается целой и невредимой. У кристалла регулируется программно TX level, причем без перезагрузки. Вообще - при правильном подходе, кристалл перегружать не нужно практически никогда. Все параметры меняются "на лету". WiFi точка доступа тут по большому счету нужно только для удобства конфигурирования (WEB). Сами кристаллы умеют форвардить "чужие" пакеты (ессно не "сами по себе"), поэтому достаточно того, что один кристал "видит" хотя-бы одного соседа. Обмениваются друг с другом информацией о событиях, таких как изменение состояния управляющих входов, состояния контактов реле, ... А как принимать иобрабатывать команды разного типа ? Тут я как бы велосипед не изобретал, и воспользовался логикой, сходной с MQQT: просто номер канала, от 0 до 255. Один кристалл генерирует (в зависимости от того, что с ним происходит) сообщение с номерами каналов (до 3х штук), остальные обрабатывают, согласно заданной программе, если номера каналов совпадают с теми, которые прописаны в локальном конфиге кристалла. Ну и форвардят (тоже конфигурируемо) выбранным соседям - до 75 устройств в одной группе. В принципе можно и больше, но я и до это предела дойти не смог. Что 4касается управляющих входов, в моем случае есть проводка на 220В к выключателям и розеткам, посему управляющие входы "заточены" под 110 - 220В, т.е. не на замыкание контактов. Управляет каждый управляющий вход (в зависимости от программы) своим реле, правда я оставил возможность управления путем каналов и вторым реле, т.е. можно "щелкнуть" обеими, если в этом есть необходимость. С термостатом/метеостанцией в общем логика аналогичная, совместная работа с таймером, проверка всего чего только возможно во всех комбинациях. Ограничение - только циифровые датчики, их сейчас на рынке великое множество. В принципе можно конечно доделать подключение аналоговых NTC датчиков, благо свободный порт АЦП есть но учитывая разброс параметров по сопротивлению (при 25С), придется в зависимости от подключаемого NTC сенсора подбирать достаточно точное сопротивление, посему пока не делал. Все устройства "равноценны", т.е. нет ни masterов, ни slavов. Для сценария, когда один автомат (не важно какой) должен централизованно дать команду "выключиться всем", предусмотрена отдельная программа.

У atmega есть одна замечательная штука, которой нет у Cortex: fuses. Выжег по финалу - и все. Уже вычитать программу практически нереально. Я так и не сумел на Cortex сделать так, чтобы нельзя было вычитать именно firmware.

Может тогда master должен "собирать урожай" последовательно, со всех slaves ? Заодно и "ifalive" получится. circular buffer или можно даже fifo (с фиксированным размером), это такой механизм, который держит последние N сообщений, которые может забрать клиент, и по мере появления тех, которые клиент "забрать не успел", выбрасывает по одному старые, и добавляет новые, сохраняя порядок поступления.

Процесс построен так: 1. Напаиваем 4 ноги на стабилизатор. И так раз 50, а то и все 100. Секунд 30 на плату. 2. Прямо на bread board, собрана "наколенчатая" схема с ЖК индикатором. "втыкаем" туда ноги от стабилизатора, 2-3 поворота пластмассовой отверткой - готово. Секунд 15, если руки не дрожат 3. Достаем из BB и в коробку - потом понадобится при сборке. Даже если ставить smd fixed резистор - проверять все-равно нужно. Были прецеденты ...

Ага, знакомо. circular buffer на последние, скажем 20 событий ? Периодический polling (ну или broadcast) от master ?

master назначается крутилкой, или программно ? На счет статики,- таки да. Но задачу при разработки addons вы себе несколько усложнили. Удалось протестировать, хотя бы на 3х контроллерах ? Коллизии на шине разные, производительность ... Я понимаю, что для управления с дискретностью в секунду наверное не сильно актуально, но все-таки. С тестированием, я например поступил так: У соседей вечная проблема - то включили тэн на летнем душе и забыли, то свет забыли выключить,или "козла" нужно было включать раз в сутки на час (+/-) зимой, то еще что-то. Самолично установил им (совершенно забезплатно) контроллеры, упрограмил вусмерть, и собсно стал ждать отзывов и предложений. Так "родились" еще штук 5 разных программ, и ессно повылазили баги. На это время, я оставил возможность OTA (flash firmware over the air), и оперативненько так фиксил. Через приблизительно месяц активного использования, закрыл OTA, отдал все админство устройствами соседям (и их молодым родственникам), провел курс "молодого бойца", и изрядно поменял manual, который, как оказалось я писал для железячников-програмистов, а не для простых людей. Аппараты оставил соседям. Заодно (уже для себя) посмотрел что будет когда всего 21 устройства "разговаривают" друг с другом. Как-то так ...

Увидел. По модному у вас Имеется в виду до 16 контроллеров в одной группе ? Мастер как-то выбирается, или реализовано программно ?

Ага, понятно. А что это за крутилка такая на плате ? И кварца не видно one/two wire по идее можно прямо на io организовать, с участием 1-2х резисторов. Нет ?