Category: it

Category was added automatically. Read all entries about "it".

Мини реле на 10А (powered by core5277)

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

Итак, новые характеристики прототипа:
1) Управление по шине RS485(две витых пары), поддержка до 128 устройств, допустимое расстояние - сотни метров(зависит от свойств кабеля).
2) Компактный протокол, среднестатистический запрос-ответ выполняется за 15-20 миллисекунд.
3) Уникальная идентификация каждого устройства.
4) Обнаружение всех устройств на шине в течении нескольких секунд.
5) Ведение истории устройством (записывается изменения показаний, рестарт устройства и команды реле с учетом источника команды).
6) Информирование Java контроллера о событиях(изменено состояние реле или показание температуры и прочее) в течении 30 миллисекунд
7) Поддержка порта расширения для датчика температуры(DS18B20) или датчика температуры и влажности(AM2301) или кнопки без фиксации для управления реле или выключатель(кнопку с фиксацией) (также, в будущем, планирую добавить таблетку DS1990A)
8) Возможность обновления прошивки без дополнительных манипуляций, функционалом можно воспользоваться прямо в клиенте.
9) Съем потребляемой мощности нагрузкой на базе тока(напряжение не учитывается, используется константа) *(доступно только для реле с датчиком тока)
10) Поддержка таймера с минимальным интервалом в 10 миллисекунд
11) Защита от частого переключения реле (максимальная частота - 2Гц)
12) Поддержка триггеров, позволяют управлять реле на базе условий по показаниям температуры, влажности, потребляемой мощности нагрузкой.
13) Возможность блокировать каналы управления реле (ручной, шина, таймер, триггер)
14) Размеры, не более, 20х20х35мм
15) Потребление(при 5В) менее 20ма/80ма
16) Поддерживаемое напряжение 5-36В (постоянный ток)
17) Индикация: вкл/выкл реле(синий), опрос датчиков(зеленый), передача по шине(красный)
18) Опрос датчиков - каждые 5 сек, информирование Java контроллера при изменении состояния реле, dT>=1, dH>=3, dW>=200
19) Коммутируемый ток - характеристики реле: 10А(250V AC)
20) Трех контактная колодка: вход, НО, НЗ.

Фото прототипа (пайка не фабричная, паял сам!):





Ну и вот так она выглядит в клиенте:



В данный момент проводится мелкая доработка прошивки и функциональное тестирование.
После, закажу партию(со сборкой SMD), подготовлю документацию и определюсь с ценой.
Также рассматривается вариант сертификации.

P.S. Благодаря core5277 прошивка легко модифицируется(написана полностью на ассемблере), не сложнее чем с ардуино. Например на ввод поддержки AM2301 я потратил 15 минут с учетом модификаций библиотеки устройства для Java контроллера и модификации данных БД.

No C C++

Хотите немного шаблонов? Их есть у меня.

Ни строчки кода Си и Си++ на конечных устройствах и шлюзах.

Вся реализация на девственно чистом старом добром ассемблере.

Настоящая Realtime OS с вытесняющей многозадачностью для конечных устройств на чипах ATmega8/16/88/168/328,AT90CAN32(и не только) и даже некоторых ATtiny. Также на девственно чистом старом добром ассемблере.

Это по сути тематика пиктограм характеризующих проект, типа как "No PB".

Минимализм и искусство старого доброго кодинга в современных решениях.

Платформонезависимость от отцов Sun Microsystems в виде Java контроллера.


Максимализм, приведший разработчика к ОС на ассемблере и реализация на нем-же прошивок во времена подавляющего СИ и STM32 - явное свидетельство маниакальных трудозатрат ради надежности, стабильности и независимости.

Это моя затравка для будущей популяризации проекта.

Пршивка датчика двери на ATmega88 на базе core5277

Сегодня я закончил основной код прошивки датчика двери на базе своей ОС(https://github.com/w5277c/core5277)

Поддерживается следующий функционал:
1) Опрашиваются 2 порта для датчиков сухого контакта(опрос каждые 100мс, анализ портов можно отключить в настройках)
2) Светодиодная индикация режима опроса и индикация открытой двери
3) Поддержка кнопки без фиксации, можно настроить сценарии на разные комбинации нажатия(короткие, длинные нажатия, 4 комбинации максимум, +удерживание)
4) Ведение истории событий, данные не будут утеряны из-за временной остановки Java контроллера.
5) Шина bus5277, позволяет находить новые устройства, производить быстрые опросы устройств и практически мгновенно обнаруживать устройства с новыми данными

Как уже сказал, эта прошивка базируется на моих открытых исходниках ядра core5277.
Устройство работает под управлением операционной системы реального времени в режиме вытесняющей многозадачности.
Также используется дополнительная прослойка кода(5277 environment) разработанная для моих устройств - это закрытое ПО.
И вишенкой на торте - программа верхнего уровня, около 200 строк кода на ассемблере - это  и настройки и сама логика работы(именно эта часть будет отличаться в разных устройствах).

Все это заняло 98% 8КБ FLASH, т.е. умещается в ATmega88. Лично меня такой результат впечатлил.

Если взять чип ATMega168, то функционал будет расширен бутлоадером, т.е. появится возможность обновлять прошивки прямо через клиент.

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

P.S. Жека, я помню, уже скоро.


P.P.S Чипы стали золотые, особенно ATmega, особенно в россии у барыг. Там же, на гитхабе(https://github.com/w5277c/core5277_stm32) есть мои скромные попытки разработки нечто подобного для STM32, но пока только в рамках задачи работы с SD картой(поэтому ОС там появится уж точно не скоро). Было бы куча свободного времени я бы глянул в сторону STM8, думаю адаптировать core5277 будет не сложно.

Оффтоп, накипело.

В чем причина холивара между Си программистами и почти вымершими программистами на ассемблере?

На мой взгляд, причина очевидная.

На ассемблере среднестатистические веб страницы не пишутся.

Также как и не пишутся широко востребованные нативные приложения.
Широко востребованные нативные приложения пишутся чаще всего на Си а то и на СиШарп или даже на Джава.
Но для быстрой разработки приложения на Си, Си программист должен взять огромное количество чужих разработок (это ведь основной плюс? Наличие данных наработок).
Однако, очень часто качество этих сторонних разработок вызывает сомнения, например Си библиотеки Ардуино. Какого-же качества продукт получаем в итоге? А да, ведь количество перерастает в качество? Точно?

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

И наоборот, никто в здравом уме не будет писать еще один HTTP сервер на ассемблере? Зачем такой тяжелый труд? Или боже упаси написать 1С.

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

Но ваши труды основаны на трудах тех, кто создает технологии, процессоры и подобное. Тестирует это все в машинных кодах и на ассемблерах. А потом вы берете их труды и называете их недалекими, потому что думаете, что они не способны писать на Си.

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

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

P.S. Хотите большой и чистой автоматизации без Си и Веб извращений? Постараюсь помочь!

Гидропоника

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

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



И так, у меня есть модули для различных датчиков качества воды, типа такого:

Еще есть дозаторы типа (или даже проще, один двигатель, без логики):

Ну и нужен свет.




Казалось бы что проще? Берем ардуино, качаем с сайта производителя https://atlas-scientific.com документацию по протоколу, реализуем его на ардуино (либо даже берем готовую библиотеку, наверное она где-то есть)
И все делаем сами, т.е. сценарии, информирование, удаленный доступ, сбор статистики и прочее, прочее, прочее.

Но я же все эти вопросы уже решил в своем проекте.
Проект представляет из себя три ключевых узла - Java контроллер, сервер, клиент. Также есть различные собственные конечные устройства и различные шлюзы.

Для работы конкретно с вышеописанными устройствами я могу использовать мини компьютер с шиной I2C, либо любой другой компьютер с большим набором UART (например USB-UART устройства).
На этом компьютере будет работать Java контроллер, он будет выполнять все взаимодействие с устройствами, в том числе и выполнять различные сценарии. Данные контроллер будет передавать серверу, а тот их отдавать клиентам и агрегировать.

Мне незачем знать API/протокол EZO устройств, они уже реализованы в проекте (кроме дозатора, об этом позже).

Точно также обстоят дела и с другими устройствами, например управление светом, датчик открытия двери и прочее.
Теоретически я их всех могу подключить к мини компьютеру через GPIO. Но что делать с обычными компьютерами?
Можно прикупить китайских железяк и подключить их по USB к примеру.

Но я пойду другим путем. Жаль, сейчас нет железок под рукой, фото будут позже.
Я возьму решение от Dipex. Мы разработали множество различных модулей.
Среди них есть модули специально для EZO модулей, есть USB шлюз с шиной DipexBus, есть мини компьютер с платой расширения DipexBus, есть специальный модуль для диммирования светодиодных ламп со стабилизацией по току. У нас много железяк, и некоторые специально разрабатывались для данной задачи.

Да, DipexBus проприетарная, но и ее протокол мне не нужен, все в проекте. Мне не за чем работать с DIpex модулями напрямую, так же как и с EZO модулями напрямую.

В итоге, я подключаю USB-DipexBus шлюз в любой компьютер или использую мини компьютер с платой расширения I2C-DipexBus. К нему подключаю EZO Dipex модули (в любом количестве) вставляю в них EZO модули и подключаю датчики. Также на шину подключаю Dipex LED диммер, DIpex IO модули и прочее.

Вот в качестве примера (только здесь другие модули и без корпуса):
photo_2020-05-20_18-30-39.jpg

Таким образом я объединяю DipexBus'ом все свои датчики и исполнительные устройства. Шина реализована на RS485 с поддержкой до 128 устройств.

По поводу дозатора. Мы не стали использовать дозаторы от atlas-scientific, у нас обычные дозаторы (двигатель на 18 вольт) которые управляются отдельным многоканальным модулем Dipex. Библиотеки дозатора atlas-scientific в проекте нет, но его можно добавить при желании.

Теперь программная часть.

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

Клиент - отображение показаний, управление устройствами и настройка сценариев и проекта.
Он может работать через сервер или напрямую (если клиент и контроллер находятся в локальной сети)

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

TODO: позже добавлю здесь видео.


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

Либо можем работать через сервер, и здесь варианты:
В данном случае нам нужен итоговый результат. Т.е. показания устройств, статистика, возможность изменять налету проект и сценарии.
Все это можно сделать через аналогичный API (также использует клиент).
Сервер поддерживает несколько подключений, через которые можно использовать API:
- внутренний бинарный протокол (можно предоставить Java библиотеку с его реализацией)
- голый TCP с JSON
- HTTP с JSON
- WebSocket c JSON
Документация будет доступна после написания.

Кроме этого, управлять и собирать показания можно через так называемые точки входа - Telegram, Алиса, email, HTTP и прочее. Методы работы специфичны для каждой точки доступа. Документация также будет доступна после написания.



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

Пока все, буду обновлять по необходимости.

P.S. По поводу пожеланий, я постараюсь найти время и выполнить ваше пожелание (например написать документацию по API). Но при одном условии - Вам действительно нужна эта документация (чтобы я не писал ее в пустую сейчас)

Update 03.01.2021

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

Ранее я не раз говорил, что мое решение представляет из себя конструктор, т.е. мой конечный клиент либо интегратор, либо самоделкин (DIY любитель).

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

Конкретно для пользователя я сделал точки входа. Например точку входа Телеграмм или Алиса, где пользователь может управлять устройствами гораздо удобнее. Также были созданы виджеты под Android, которыми я сам пользуюсь очень часто (моя жена пользуется телеграмом и ее вполне это устраивает). Возможно в этом году я стану разработчиком под ios и у нас появится клиент и виджеты под iphone.

Но, в рамках данной задачи (гидропоники), для специалистов я бы создал специальный веб проект, где были бы выведены многочисленные графики, сгруппированы показания, выведены специальные элементы модификации проекта (параметров устройств и сценариев).
API открытое, этим проектом может заняться сторонняя компания, а можно обратиться в Dipex Group - они могут разработать дизайн, WEB портал и разместить его в своем ЦОД'е.

core5277, новая версия

Новая версия 0.2.5

1. Скорректирован драйвер DS1990A
2. Добавлена дополнительная проверка на присутствие датчика в драйвере 1WIRE
3. Восстанавливаем регистр Y в процедуре io/log_bytes.inc
4. Добавлены процедуры чтения и записи байта/блока в EEPROM
5. Добавлен проект для Atmel Studio 7 ./inc/examples/aqua_module/
6. Переименована процедура rom_to_ram_copy8.inc в rom_read_bytes.inc
7. Дополнены файлы микроконтроллеров ./inc/devices/
8. В процессе драйвер mlx90614

Главное - теперь проект можно открыть в Atmel Studio и он даже соберется.
Но все-же, я считаю, тру подход - linux+geany+avra+avrdude

Может быть на выходных запилю небольшую инструкцию для новичков.

http://5277.ru/distr/core5277/core5277.tar.gz

Сценарии на базе 'скриптов'

  Я не раз задумывался о том, как я буду реализовывать скрипты в своем проекте. Речь идет о скриптах для расширения возможностей сценариев, т.е. вместо заполнения параметров формы мы могли бы написать необходимый код. У этой задачи был довольно низкий приоритет, да и проект я позиционирую так, что знание программирования не обязательно.
  Было много разных мыслей, вплоть до написания своего интерпретатора типа Бейсик, разработки встроенного редактора и тому подобное.
Но вот сегодня меня наконец-то озарило, идея в следующем:
  Мне не нужен никакой редактор или интерпретатор, мне нужно сделать ровно тоже самое, что я проделал с кодом отвечающим за функционал устройств, шлюзов и сервисов.
А именно - описать Java интерфейс и на базе его создавать Java библиотеки реализующие необходимую логику.
Тогда, я просто ввожу в клиенте, в сценарии, в блоке условий новый элемент - Java библиотека. В котором задается вендор и сама библиотека и контроллер теперь знает какой код запускать.

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

Новый элемент (Java библиотека) будет также в блоках 'Информирование' и 'Управление', что даст практически полную свободу разработчику.

Оффтоп. Современный разработчик

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

И это проявляется во всем. Assert который был заброшен давным давно на Java, оказывается широко применим на C# среди разработчиков не отстающих от моды.
Стоит ли говорить, что это используется для примитивной валидации данных?

Майкрасовтовский WPF популярен, но его контейнер аналогичный hbox/vbox в JavaFX и андроиде реализован так, что остается куча вопросов, хотя все должно быть примитивно. Да и разрабы пошли дальше, они используют сторонюю платную библиотеку, компоненты которой не могут быть даже отображены в инструментарии Microsoft.

А синтаксис. Ради того, чтобы разраб писал одну строчку а не две, был усложнен заметно синтаксис. Зачем? Разве главный трудоемкий процесс у программиста это набивание строк? Я то, наивный, думал, что основное качество кода - его читаемость и однозначность, после конечно вопросов ресурсов.

А Spring - фреймворк для Java? Сейчас в требованиях у почти любой вакансии Java разработчика требуется его знание. Здесь у меня даже нет слов. Мне в крупном проекте не нужен фреймворк, который говорит мне что делать и который хрен поймешь как работает. У меня есть свои наработки моделей и наработки библиотек, которые гораздо лучше фреймворков. Зачем мне их знать? И чем сложность в них разобраться после опыта создания не менее сложных проектов от и до своими руками?

А да, а как вам функциональный метод программирования в C# - в ООП языке? Раньше за это по голове били, теперь это круто и модно.