Category: техника

Category was added automatically. Read all entries about "техника".

core5277, пример многопоточности

  Здесь я привожу дампы логики при параллельном выполнении нескольких задач на микроконтроллере ATmega328. Да, тот самый, с которым работает большинство Arduino поклонников восхваляя торговую марку вместо производителей чипа.
  Здесь чип работает на частоте 16МГц, среди прочего он имеет один аппаратный UART(который в данном примере не используется), и аппаратную поддержку TWI(I2C) - она задействована.

  На первом скрине показаны три события:
  - чтение с микросхемы реального времени DS3231(аппаратный TWI)
  - логирование в порт(программный UART 115200 8N1)
  - передача пакета данных(своя реализация шины на базе программного UART 19200 8N1)

Чтение микросхемы и логирование выполняются в одной задаче, передача пакета в другой, и еще есть две: мигание сетодиодом и анализ портов(открыта/закрыта дверь), но в дампе их не видно.




Далее немного увеличим дамп каждого события:

  3-ий канал - передача пакета:


  0-ой и 1-ый канал - TWI:


  2-ой канал - логирование в порт:


Кстати в логе указано текущее время, количество свободной динамической памяти(1018 байт) и динамической памяти всего(1246 байт). На данном чипе всего 2048 байта памяти, 802 байта было потрачено на нужды ядра, из которых только 368 байт выделено под 16 байт переменных 23-х задач и 253 байта под заголовки этих задач. Т.е. реально на нужды ядра выделено 181 байт, из них 64 байта под стек, 75 байт под таблицу прерываний и 20 байт под таблицу программных таймеров. При этом в данной прошивке проинициализировано 6 драйверов и 5 задач.

  Думаю отдельно стоит рассмотреть точность таймингов для передачи данных. К примеру канал 3, скорость не большая 19200, но, здесь важно то, что таймер программный, предоставляется ядром, при этом для данной скорости расходуется ровно 1 тик таймера. Все используемые таймеры в ядре основаны на TIMER0, он же отсчитывает тики ядра(кванты).



  А здесь скорость 115200, не используются таймеры и прерывания. Логирование выполняется как обычный код задачи, просто подсчитаны такты и на время передачи октета прерывания блокируются.


Блокировка прерываний, особенно в многопоточной ОС может привести к плачевным последствиям, например такое логирование при передаче или приеме данных по программному UART обязательно приведет к ошибкам. Для этого будет введен функционал похожий на мьютексы.

  Главное, что мне доставляет удовольствие в данном увлечении, это написание самих исполняемых задач, они просты, там нет никакой сложной логики для контролирования ресурсов.
  Вот например код задачи для тестирования драйвера моей шины:
;---CONSTANTS--------------------------------------------
_BUS5277_TEST_HELLO:
    .db   "Hello",0x00

BUS5277_TEST_INIT:
    MCALL CORE5277_TASK_READY
;--------------------------------------------------------
_BUS5277_TEST_INFINITE_LOOP:
    LDI TEMP,TID_BUS5277_DRV
    LDI YH,high(_BUS5277_TEST_HELLO)|0x80
    LDI YL,low(_BUS5277_TEST_HELLO)
    LDI TEMP_EH,BUS5277_RESP_OK
    LDI TEMP_EL,0x06
    MCALL CORE5277_DRIVER_EXEC
 
    LDI TEMP,0x01
    MCALL CORE5277_TASK_WAIT_1S

    MJMP _BUS5277_TEST_INFINITE_LOOP
    RET



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

Update: А вто как выглядят три задачи типа
BURN_INIT:
    MCALL CORE5277_TASK_READY
    SBI PINB,PB2
    RJMP PC-0x01


Сценарии, начало.

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

  Итак, выбираем в меню 'Настройка сценариев'.


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


Создаем группу.
  Изначальное состояние группы - заблокировано, это означает, что контроллер не будет выполнять сценарии внутри этой группы. Рекомендую снять галку только после описания всех сценариев группы.
Объединение сценариев в группы имеет больше тематический характер, хотя есть и особенность, ведь группу можно включать и отключать(а также можно создать сценарий который будет выполнятся при этих действиях).
Этим можно воспользоваться, к примеру, занести в группу 'Сигнализация' все сценарии отвечающие за контроль дверей и прочее. Ну или скажем создать группу содержащую сценарии имеющие отношение ко временам года(хотя в самих сценариях можно указать периоды работы, например определенные месяцы).
  На этой форме, как и на предыдущей, есть кнопки стандартных действий: добавить, удалить, редактировать, обновить и клонировать. Последняя позволяет быстро сделать копию сценария.
  Также, внизу формы, есть кнопка 'Активировать изменения'. Эта кнопка передает все ваши текущие наработки в данной группе на сервер(или контроллер). До нажатия этой кнопки все изменения хранятся только на данной форме.


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

Создаем сценарий.
  Стандартный заголовок, опять же галка 'заблокировать', имя и комментарий(который можно не заполнять).
Далее идут блоки:
1) Причина запуска - описывает причину запуска, т.е. при каких условиях контроллер приступит к анализу данного сценария.
2) Внешние факторы - по сути это дополнительные условия, которые могут влиять на выполнение сценария, например отменить его анализ или заставить контроллер проигнорировать другие условия(например период действия).
3) Период действия - по сути, это фильтр, позволяет указывать когда разрешать дальнейший анализ сценария.
4) Условие - здесь мы можем задать различные условия на базе показаний от устройств, которые также повлияют на дальнейший анализ сценария.
5) Информирование - а это уже исполнительная часть, ее выполнит контроллер только если предыдущие условия это позволили. Здесь мы можем сказать системе что сообщать и куда сообщать.
6) Управление - тоже исполнительная часть, заключительная. Здесь мы можем указать различные действия, например послать команду конечному исполнительному устройству, или запустить другой сценарий на другом контроллере, или выполнить внешний скрипт на машине где запущен контроллер.


  Теперь детально:
Причина запуска:
1) Запуск группы сценариев - будет запущен при снятии галки 'заблокировать' данной группы. Это полезно, если необходимо при включении группы выполнять ряд действий, например послать всем устройствам управления команду 'вкл'.
2) Только системный вызов - означает что данный сценарий может запустить только другой сценарий.
3) В назначенное время - можно указать время(часы и минуты) когда требуется запустить сценарий, при этом можно указать время для повторного запуска. Контроллер будет выполнять повторы, скажем если было задано время запуска 00:00 с повтором каждый час, а текущее время создания данного сценария скажем 13:45. Т.е. запуск будет выполнен в 14:00, 15:00 и .т.д.


4) Обновление показания устройств - анализ сценария будет запущен когда обновятся данные показаний участвующих в анализе(блок 'Условие')
5) Нажатие виртуальной кнопки - в конструкторе(редактор проекта) можно добавить виртуальную кнопку. Здесь можно описать эту кнопку, таким образом можно запускать сценарий нажатием кнопки устройства в клиенте.


6) Написана/произнесена фраза - запуск осуществляется когда с точки управления(Телеграм, Алиса и прочее) поступает фраза. Здесь выполняется ее анализ. Также можно задать фразу которую получит пользователь в ответ.


7) Случайно - запуск сценария осуществляется случайно, проверка раз в минуту, здесь требуется указать вероятность(1/100 - вероятность 1 раз в 100 минут) т.е. для вероятности раз в две минуты нужно указать 50/100 или 1/2.


8) События от устройств - некоторые устройства могут посылать специальные события, по которым контроллер запускает сценарий.


9) Смена состояния контроллера - здесь речь о соединении с сервером, можно запускать сценарий при успешно
установленном соединении или при недоступности сервера. Также можно указать время ожидания.


10) Смена состояния устройства - аналогично предыдущему, но здесь также можно определять перезагрузку для некоторых устройств.


11) Остановка группы сценариев - аналогично первому пункту, но здесь срабатывает сценарий когда мы ставим галку 'заблокировать'

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


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


3)  В течении периода(расширенная форма) - здесь используется методика планировки задач в crontab. Мы можем указать время, дату и дни недели в течении которых будет продолжен анализ. Используется логическое и. Т.е. если время или дата или день недели не попадает под условие то анализ будет прерван. В полях день, месяц и год можно использовать разделитель ',' и диапазон(через '-'). При наведении на поле появится подсказка.


  Условие
  Пожалуй это самый сложный блок. В нем два элемента 'По показаниям устройств (логическое 'И')' и 'По показаниям устройств (логическое 'ИЛИ')'. Т.е. для успешного анализа, условия правил внутри блока должны быть или все истинны или истинно хотя бы одно соответственно.
  Далее видим кнопки:
  1) Добавить формулу - используется если нам нужно сделать какое-то вычисление на базе показаний в добавленных правилах или констант.
  2) Разрешает повторное выполнение сценария, если мы получили событие от устройства, даже если сам снимок показаний не изменился. Актуально для таких устройств как инфракрасный датчик для ИК пультов. Он может принять одинаковую последовательность данных, что должно быть интерпретировано как еще одна команда.
  3) Разрешает выполнение сценария при первом показании. После запуска контроллера или изменении в проекте существует ситуация, при которой старого значения показания нет, а оно нужно для анализа сценариев. Т.е. анализ выполняется только при изменении показания, отсутствие старого показания не означает, что само показание изменилось. Включенная кнопка означает, что контроллер будет считать, что показание все же изменилось.
  4) Блокировка частого выполнения сценария. Существует внутренний триггер, который после успешного выполнения сценария защелкивается и не позволяет повторное выполнение до тех пор, пока сценарий не пройдет анализ. Таким образом, к примеру,  Вы не будет получать одно и тоже сообщение каждый раз когда контроллер выполнит один и тот же успешный сценарий. Отключение кнопки отключает анализ триггера.
  5) Кнопки + и -  позволяют добавлять правила и удалять выбранное правило.


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


  После выбора появился элемент списка с нашим устройством и внутренним списком условий. Который состоит из номера, названия показания, условия, значения(может иметь разный вид в зависимости от типа показания и условия) и кнопки '+'. Последующие элементы списка имеет кнопку '-', для удаления текущего элемента. Добавление новых элементов осуществляется кнопкой '+' первого элемента(первый элемент удалить нельзя, но можно удалить элемент верхнего уровня).


  Далее. Здесь мы выбираем нужное показание, указываем условие и значение этого условия(можно также указывать диапазоны и пороги).
  Порог нужен для описания работы еще одного триггера - локального триггера для каждого условия. Работает схоже с триггером описанным ранее. Его задача также не допускать повторной отработки сценария.
Принцип следующий. Он срабатывает, когда значение показания достигло указанного условия, т.е. условие истинно только при первом анализе, даже если при повторном значение также достигло указанного условия. Сброс триггера выполняется только тогда, когда показание отклонилось в обратную сторону с учетом дельты в указанный период.
  Т.е. если мы создали условие на температуру больше 20 с порогом в 1, то триггер будет установлен при температуре больше 20 и снят при температуре меньше(20-1).

  Теперь о формулах. Формула также имеет номер , поле для ввода условие и значение для условия. А также кнопку проверки корректности введенной формулы. С помощью меню(правая кнопка мыши) можно подставить показания устройств которые должны быть добавлены заранее. Как и с условиями по показаниям само условие может отсутствовать.


  Таким образом данный функционал позволяет выстраивать цепочки логического 'И' или 'ИЛИ' с любым набором устройств и с любым набором условий для каждого устройства. А также можно добавлять формулы.


Информирование
1)  Никому - блок просто игнорируется
2)  Только мне - информирование будет выполнено только автору сценария
3)  Группе - информирование будет выполнено только для участников группы(пока не реализовано)
4)  Всем - всем в проекте, кто может получать информирование

  Форма для всех типов выглядит одинаково.
  Верхняя часть элементов:
  1)   Метка - в клиенте будет подсвечено красным показания присутствующие в условиях блока 'Условие'
  2)  Сообщение - сообщение будет выведено посредством клиента.
  3)  Телеграм - сообщение получат все пользователи с точкой входа 'Телеграм'
  4)  Эл. почта - аналогично, но для эл. почты.
  5)  СМС - аналогично, но для смс(пока не реализован шлюз, смс стоят денег)
  6)  Звук - на контроллере будет проигран звуковой файл.


  Далее два поля: описание заголовка и основной текст сообщения. Здесь через меню(правая кнопка мыши) можно подставить константы, показания устройства или просто значение показания. Показания выбираются из блока 'Условие'
  Для включенного режима 'Звук' доступны галки повторять(при окончании проигрывания оно будет заново запущено) и 'Останавливать' (проигрывание будет остановлено если при повторном выполнение сценария анализ не был успешно завершен).
  Далее поле для ввода названий файлов, можно перечислять через ',', тогда контроллер будет выбирать файл случайно из указанных. И последнее поле - громкость.

Управление
1) Не управлять - игнорируем данный блок
2)  Управлять устройствами - здесь мы можем добавить несколько устройств, команды которых мы планируем выполнить.
3)  Запуск сценариев - аналогично, здесь мы добавляем сценарии, который планируем выполнить.
4)  Остановка сценариев - аналогично для остановки. На данный момент остановка нужна только для проигрывания звукового файла.
5)  Запуск внешнего скрипта - bash команда или файл выполняется на стороне контроллера
6)  Здесь можно выбрать сценарий, который не принадлежит текущему контроллеру. Т.е. текущий сценарий будет проанализирован скажем на контроллере А, а выполнен сценарий на контроллере Б.



Пример использования
  Это тестовый набор сценариев, обычного термореле(теплый пол). Задача - включать обогрев при температуре меньше или равно 35 градусам и выключать при температуре больше либо равно 36 градусам.

Первый, на включение обогрева.


Второй, на выключение обогрева.



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

update: добавил картинки

Dipex, взаимодействие устройств без контроллера

Небольшое вступление:

"Dipex Group" - это компания - официальный представитель данного проекта.

Т.е. это общий проект, но есть некоторые отличия:
1) Главное - парк устройств. Устройства отличаются по функционалу, внешнему виду, количеству, логике и даже реализацией шины. Разработка схемотехники устройств и их прошивок отдельная, функционал не заимствуется, разве что элементарных функций.
2) Облаком - при регистрации и авторизации пользователь выбирает площадку, в зависимости от выбора будут использоваться либо сервера Dipex'а, либо мой сервер.
3) Дополнительными сервисами и кастомизацией.

Здесь я хочу рассказать о своем новом функционале.
Когда-то на первых итерациях наработки железа эти функции были, но проект стал значительно сложнее и от них пришлось временно отказаться.



И так, речь идет о взаимодействии устройств посредством шины DipexBus, без контроллера.
Как известно, самый распространенный и не дорогой протокол общения железок на шине типа RS485 - Modbus.
На мой взгляд, главный недостаток этого протокола - ведомый(slave) не может инициировать передачу. Т.е. обязательное наличие ведущего(master).
Здесь создан 'свой велосипед', на шине RS485 реализован протокол поддерживающий, кроме всего прочего,  динамическую адресацию и возможность вещать любому узлу независимо от ведущего.

На видео ниже я взял два устройства:
 - датчик температуры и влажности, далее 'Термометр' (также оснащен портом для DS18B20 и контактом, например для обнаружения открытия двери),
- двухканальное реле, далее 'Реле x2' (220В, 4Вт на канал, питание реле - 5В).


https://youtu.be/frVIKQ2P0bQ

Как видно, при размыкании контакта(открытии двери) загорается светодиод на термометре и тут-же отрабатывает реле, при замыкании контакта происходит обратное действие.
Аналогично по относительной влажности, если более 50% отрабатывает второе реле, и обратное действие при влажности менее 50%.

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

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

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



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

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

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


https://youtu.be/nljlGcW8-PE

Конечно я рассказал не все, например я не стал рассказывать, как устройства обрабатывают коллизии. Но данный протокол проприетарный, поэтому подробностей не будет. Скажу только, что популярные методы CAN open я не использовал. Работает достаточно надежно. Но в любом случае будет также ряд рекомендаций для использования такого режима.

update: обновил битое видео

А что это за плата скрипит?...

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

Плата имеет функционал:
1) Диммер ламп накаливания(220В)
2) 3 канала 220В(вкл/выкл)
3) 3 канала до 24В(для светодиодных ламп, в том числе RGB)
4) Порт подключения датчика температуры ds18b20
5) Цифровой порт подключения. Например для датчика уровня воды
6) Бипер, для звуковой сигнализации
7) Порт расширения для модуля Wi-Fi, Bluetooth и т.д.
8) Часы реального времени
9) Порт расширения, например для клавиатуры и дисплея
10) Порт RS485 для настройки и подключения к проекту 5277.ru(который даст широкий функционал по большинству перечисленных пунктов)

core5277, продолжение

Что у тебя там скрипит? Спросил старший сын...


А скрипит у меня там нотами реализация бипера на Atmega88.
Конечно скрип я немного исправил, теперь оно больше похоже на писк.
Динамик ведь был просто взят из коробки с барохлом и тупо через транзистор подключен к МК.
Главное не то, что оно скрипит или пищит, можно ведь и WAV играть с карты памяти на Atmega.

Главное то, что оно пищит в данный момент задачей, которая выполняется паралельно еще нескольким:
1) Анализ свободной/занятой памяти и вывод информации в порт логирования(UART 115200)
2) Анализ температуры с датчика ds18b20 и аналогичный вывод в порт логирования
3) Вывод данных по MODBUS(UART 9600)
4) Перемигивание светодиодами с интервалом в 20мс

Ну и конечно сама задача, которая пищит по нотам мелодию с Battle City и Mario, при этом также в порт логирования выводит информацию о текущем проигрывании мелодии.

Я уже не говорю о том, что для  этого всего задействованы драйверы:
1) Логирвоания
2) Бипера
3) шины 1wire
4) ds18b20(окторый использует драйвер шины 1wire)
5) втроенного UART

А еще есть драйвер кнопок, который я пока не адаптировал к последним изменениям ядра.
Шикарый драйвер, позвляет отслеживать до 16 кнопок, анализирвать длинные и короткие нажатия, вести иторию и предоставлять на выходе эту историю длинной в 4 нажатия(длинные или корткие), ну и о не отпущенной кнопке(повтор комбинации) тоже сообщает.

Все порты драйверов задаются програмно, можно варьировать как захочется. Ну кроме конечно встроенного UART.
И да, драйвер программного UART тоже будет.

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


Смею напомнить, что речь идет про 8 бит микроконтроллер работающий на частоте 16мГц, имеет 8КБ ПЗУ, и 1КБ ОЗУ. 1(один) UART и 3 таймера, при этом ядро использует только 1(один) и предоставляет програмные таймеры драйверам.
Печалька толлько в том, что ПЗУ уже забито на 60%, но это если подгруать все, что конечно не обязательно. С ОЗУ все хорошо, стеки задачь кушают мало.

P.S. Да, задачи действительно выполняются паралельно, никакого специфичного кода задачи не имеют, кроме единственной команды CALL после инициализации. В дополнение можно использовать драйверы и процедуры ядра, но это не обязательно, задачи все равно будут работать паралельно друг другу. И да, конечно реальные ресурсы МК они одновременно использовать не могут, для этого есть функционал ядра.

P.P.S Это не Си, я не фатаник Си, это чистый ассемблер.

P.P.P.S. Ага, это один из тех МК, который используется на платах ардуино. Но я не с ними, просто не сними, просто очень, очень не с ними. Я поколение ZX Spectrum'а.

Новая ОС, не Попова.

Вы хорошо знаете rtos?

Я ее не знаю. Это правда, что она писана на си и нет решения на ассемблере?
Вообще мне по хрену, и я не Денис Попов.

Я просто не люблю зависеть от чужих решений.
Поэтому думаю, что имею полное право, в виде своего хобби, запилить ОС на ассемблере, скажем для ATMega88.

Скажу, что такое уже реализовано в коммерческом проекте.
Хочу сделать подобное, даже чем-то лучше.

Давно хочу, но пожалуй именно в этом я вижу свой стимул на текущий момент.
При этом уже есть наработки.
Сейчас ос поддерживает до 6 параллельно выполняющихся задач и еще 4 процедуры (не забываем про объем памяти - 1кБ на 16мГц максимум).

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

Все просто, 8-ми битный микроконтроллер с малым объемом ресурсов и ОС для проектов на чистом ассемблере.

P.S. Сегодня обычный день, не мой день рождения, но не обычная ночь, и мой дом до сих пор безъядерная зона. Однако GluonHQ уже не мечта в далеком будущем, а реальность, реальность с проектом реализованным на 90%, осталось просто мелочь. Интересно, как скоро я смогу пользоваться своей ос?

JSON зло

Потоковый парсинг нескольких десятков килобайт JSON на мини компьютере отработал за несколько десятков секунд в режиме процессора OnDemand.

Недавно я задавался вопросом, почему на старом смартфоне(с андроидом 4.4) происходят постоянные сетевые сбои - дело просто в таймауте, который у меня выставлен на 5 секунд.
Просто один только парсинг json'а сжирает гораздо больше времени...

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

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

В итоге я создал свой протокол, который в текстовом виде выглядит как JSON, но передача информации осуществляется чисто в бинарном виде, что значительно упрощает его парсинг.

Ардуино как шлюз

Приветствую.

Не так давно я реализовал шлюз в своем проекте с названием 'Arduino UNO'.

Все просто. Я описал в системе шлюз, у которого входным интерфейсом является UART или USB.
А исходящими GPIO, I2C и 1W.

А затем, посвятил пол дня на ардуино(ранее я с ним не работал, ну может раз среду разработки запустил оплевался и выкинул). Моих знаний было достаточно, чтобы почти не глядя создать скетчь(тьфу, матерное слово, простите). Это скетч (еще одно матерное слово) на данный момент выполняет функционал шлюза, т.е. по запросам от контроллера управляет портами. К примеру я легко запустил в проекте управление двухканальном реле и символьным дисплее winstar 1602.
Да, скетч прошивка еще сырая, будут дополнения как и по i2c функционалу так и другие плюшки. И никто не мешает доработать эту прошивку (протокол универсальный).

Для чего это?

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

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

Видео:


CNC 1310

Не так давно былa массовая истерия по поводу всяческий комнат с квэстами.
А я вот думаю, нахрена?
Ну, к примеру, закажите вы себе станочек CNC 1310, вот это квэст, это я понимаю.



Сразу предупреждаю, я это чудо в первые вижу в реале, слов умных не знаю, в общем полный новичок.

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

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

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

Пока только выяснил:
1) Движки у меня 17HS4401(1.7А макс.), драйвер A4988(2А макс.)
напряжение на подстроечном резисторе в моем случае должно быть 1.36В, было около 0.62В
(RS = 0,100 Vref = 1.7 * 8 * 0,100)
Настройку по току брал здесь: https://3deshnik.ru/blogs/akdzg/pravilnaya-nastrojka-toka-dlya-shagovyx-dvigatelej

2) Версия GRBL контроллера 0.9, есть новее (1.1), прошиваться пока не стал, хотя, как я понял, с лазером умеет работать только 1.1

3) Для управления станка выбрал программу Candle (версия 1.0.11, более свежие рассчитаны на GRBL версии 1.1)
Можно взять здесь: https://github.com/Denvi/Candle/releases/tag/v1.0

4) В настройках моего контроллера не врено заданы размеры
$130=200.000 (x max travel, mm)

$131=200.000 (y max travel, mm)

$132=200.000 (z max travel, mm)
Как менять пока еще не знаю.

5) Пока ничего не сломал, пост буду дополнять.

25.05.2019, получил от продавца архив с документацией и софтом.
Скачать можно здесь: http://5277.ru/distr/other/cnc1310/software-%e8%bd%af%e4%bb%b6.zip

Электроника вне проекта, денди джойстик

Фото:


Зачем?

Как бы можно пойти в тот-же ДНС и купить что-нибудь из рекомендаций на сайте ДНС https://technopoint.ru/product/662890f44a2b3330/gejmpad-nintendo-nes-mini-classic-seryj-sale/

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

Можно еще поискать на алиэкспрессе и в подобных магазинах.
Был такой опыт, приходит один лишь шлак.

Можно со штатов заказать, но лично меня смущает цена.

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

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

Вместо элементарной логики поставил дешевый МК (ATTiny2313A), так как решил немного расширить функционал (запаздывание отклика на 2нс, что вполне допустимо для протокола).
А именно сделал:
- TURBO для каждой кнопки A и B
- смену местами A и B
- одновременное нажатие кнопок A и B (ну или можно дописать что-то другое, более сложное)

Честно говоря я доволен, джойстики получились со 100% надежным,безошибочным откликом.
Лично я перестал замечать джойстик в руках где-то через минут 5 игры, даже с учетом щелчков.
Но, им нужен корпус, хотя бы лист оргстекла, так как с нижней стороны находятся контакты кнопок, которые срабатывают от потных рук, даже лак не помогает.

*скоро придет CNC станочек, буду экспериментировать с корпусами.