Arduino & Pi

Всем привет! Линейка одноплатных компьютеров Orange Pi расширяется в CusDeb и следующим устройством стал Orange Pi Zero. Теперь CusDeb позволяет кастомизировать Debian 10 «Buster» для этой модели одноплатника.

А можете напомнить, что такое Orange Pi Zero?

Конечно. Orange Pi Zero – это китайский одноплатный компьютер, который был анонсирован в ноябре 2016-го, но до сих пор остается популярным среди разработчиков за счет того, что является достаточно мощным и при этом дешевым устройством.

Может показаться, что производитель одноплатников выпустил модель под названием Zero, чтобы составить конкуренцию Raspberry Pi Zero, но устройство оказалось совершенно другим и, как следствие, предназначенным для решения других задач. К примеру, в отличие от Raspberry Pi Zero у Orange Pi Zero нет HDMI, но есть Ethernet.

Стоит искать подвох в его дешевизне?

Определенно. Главным недостатком любых моделей Orange Pi на протяжении долгого времени оставалась хреновая поддержка производителем. К примеру, подобного рода устройства выпускаются на рынок, как правило, в сопровождении «эталонной» Linux-подобной операционной системы, которая поддерживает все заявленные фичи устройства. Затем проходит немного времени и устройство начинает морально устаревать, т.к. производитель забивает на продукт, не обновляет операционную систему и, вероятно, фокусируется на чем-то другом.

Сложившуюся ситуацию с переменным успехом исправляют два проекта – Armbian и CusDeb. Armbian выпускает универсальные образы на базе Debian-подобных дистрибутивов, которые патчатся с целью предоставить пользователям наиболее полную поддержку того или иного устройства. Недостатки и достоинства здесь – две стороны одной медали.

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

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

CusDeb, в свою очередь, старается упростить установку на одноплатники «ванильных» версий Debian и производных от него дистрибутивов, что положительно сказывается на стабильности и безопасности полученного решения. Более того, CusDeb предлагает создавать т.н. проблемно-ориентированные образы операционных систем, т.е. те, которые содержат только необходимый набор компонентов для решения конкретной задачи. «Ванильный» путь CusDeb'а, очевидно, является его самым главным недостатком – не все компоненты устройства могут поддерживаться.

А что предлагает Debian Buster на Orange Pi Zero?

Debian, как всегда и везде, предлагает стабильность и большую пакетную базу, а также выпуск обновлений на протяжении 5 лет (3 года – стандартная поддержка + 2 года – расширенная). В Debian Buster входит ядро Linux 4.19.

Заметьте, что Buster сейчас находится на стадии заморозки и тестирования. Его выход запланирован на лето.

А есть что кроме Debian'а?

Да. Напомню, что в основе CusDeb'а лежит инструмент под названием Pieman, который является свободным и открытым программным обеспечением. Поддержка новых операционных систем и устройств сначала добавляются в Pieman, а только потом прокидываются в CusDeb, что, в свою очередь, иногда приводит к тому, что CusDeb слегка отстает по возможностям от Pieman'а. К примеру, сейчас у вас есть возможность подготовить образ операционной системы на основе Kali Linux для Orange Pi Zero и получить так называемое «leave behind» устройство – устройство, которое может скрыто и незаметно собирать данные, но если будет обнаружено то 1) вам его будет не жалко потерять из-за копеечной стоимости и 2) никто и никогда не поймет, чем оно там вообще занималось.

Могу ли я чем-то помочь?

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

Добрый вечер, уважаемые.

Спаял на днях схему:

Использованы компоненты(названия кликабельны):

Транзисторы BC546 - 2 шт.

Реле NRP-02-C-05DH - 2 шт.

МК Attiny 13 - 1 шт.

Стабилизаторы напряжения:

L78L05 на 5 и L78L33 на 3.3 вольта - по 1 шт.

Диод 1N4007 - 1 шт.

Мотор какой то китайский с алишки

3 модуля датчика линии на LM393

Схема даже работает(сам охуел, не ожидал)

Алгоритм в МК простой: если LOW идет с датчика X, тогда мотор крутится в одну сторону, если с датчика Y, тогда тормозит, ждет секунду и в обратку. Если с датчика Й, тогда стоп, основан на if.

#define PIN_IN1 3

#define PIN_IN2 4

#define PIN_SENSOR_VERH 0

#define PIN_SENSOR_NIZ 1

#define PIN_SENSOR_PUSK 2

int state;

void setup()

{

pinMode(PIN_IN1, OUTPUT);

pinMode(PIN_IN2, OUTPUT);

pinMode(PIN_SENSOR_VERH, INPUT);

pinMode(PIN_SENSOR_NIZ, INPUT);

pinMode(PIN_SENSOR_PUSK, INPUT);

}

void loop()

{

int val1 = digitalRead(PIN_SENSOR_PUSK);

int val2 = digitalRead(PIN_SENSOR_NIZ);

int val3 = digitalRead(PIN_SENSOR_VERH);

{

if(val1==LOW)

{

digitalWrite(PIN_IN2, HIGH);

}

if(val2==LOW)

{

digitalWrite(PIN_IN2, LOW);

delay(1000);

digitalWrite(PIN_IN1, HIGH);

}

if(val3==LOW)

{

digitalWrite(PIN_IN1, LOW);

digitalWrite(PIN_IN2, LOW);

}

}

}

1. Подскажите, как можно оптимизировать код? Может через switch case?

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

3. Все работает не стабильно. После нескольких раз активации, начинает работать с задержкой в несколько секунд. Т.е. есть препятствие, но двигатель переключается в другой режим или останавливается с задержкой в несколько секунд, или наоборот, видит препятствие, реле щелкает и сразу возвращает перемычку на место, то есть такое вот, "полусрабатывание" и мотор не успевает начать вращаться.

А мы тут ПЛК делаем

18 входов, из них 13 дискретных, 5 аналоговых. 14 выходов. Питание от 10 до 40 вольт.

Есть необходимость видеть с утра в ванной текущее время и температуру на улице.

Была идея сделать это всё в зеркале.

Итак погнали!

Чертим проект будущего зеркала.

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

Жду зеркало своё в фирме по изготовлению зеркал и через неделю примерно получаю его.

Начинаю монтировать RGB ленту

Монтирую сенсорные кнопки и дисплей к зеркалу с помощью горячего клея. И соединяю всё это добро.

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

Примеряю  в ванной (на дисплее 2 режим 49% влажности)

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

Как говорится, продолжение следует.... :)

Продолжение 1ой части.

Ссылку на прошивку уже давал, повторю: https://github.com/N-Storm/autolight

В README.md описание есть, код более-менее прокомментировал. Но всё ес-но на английском.

В разделе Releases лежат скомпилированные прошивки с настройками по-умолчанию.

Прошивка написана под ATTiny10, который вписывается в эту задачу. В общем-то никаких особых сложностей, чтобы адаптировать прошивку под другой AVR нет. Кроме GPIO (ногодрыга) используется только прерывание INT0, Watchdog для сброса МК при ошибке, да и вроде всё.

Все настройки работы датчика и порогов срабатывания задаются жестко в прошивке. Все настройки в общем-то в файле autolight.h. Разберу их:

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

#define LIGHT_TH 100 - это порог срабатывания датчика освещения. Опять же в условных попугаях, да еще я использую жесткое округление при расчете. Потому что ДШ датчика приводит сложную формулу с делениями на дробные числа, это для тиньки 10 будет слишком много. Больше - ярче.

#define DELAY 600 - задержка в мс между проверками на уровень освещения и закрытие в рабочем состоянии (т.е. когда подсветка горит). Для экономии батарейки не слишком часто считаем, 600 мс реакция на такое событие для человеческого глаза вполне норм.

// #define RECHECK_AL - если раскомментировать эту строчку, слегка поменяется поведение прошивки. В рабочем состоянии помимо проверки на закрытие, будет также выполнятся проверка на изменение освещенности. Т.е. если подсветка работает, но вдруг включили свет в комнате, тогда подсветка выключится.

#define WTIME_DEFAULT 0xB6 - время ожидания между проверками расстояния датчиком в автономном режиме. Значение из ДШ и соответствует 202 мс между проверками. Потребление тока при этом будет копеечное. Порядка 66 мкА в среднем. Т.е. датчик раз в 202 мс "выстреливает" пульсами из ИК-светодиода и проверяет расстояние.

#define PPULSE_DEFAULT 4 - соб-но количество пульсов 4.

#define PERS_CON 0b00110000 - это то, о чем я говорил в прошлой части, настройка PERS. В ДШ даны значения, в данном случае это 3 раза подряд (202 мс * 3 + время на обработку) значение дальности должно быть ниже PROX_TH. Соб-но поэтому 3 и поставил, потому что 202 * 3 = 606, примерно тот же 600 мс отклик, как и на закрытие.

#define ATIME_DEFAULT 0xED, #define PTIME_DEFAULT 0xFF - время на обработку АЦП значений, тут взяты рекомендованные из ДШ на датчик.

Дальше всё уже идут определения констант адресов регистров датчика, битов и т.д.

I2C в Attiny10 нет аппаратного, используется софтовая либа, которую я чуть допилил. В i2csoft.h можно поменять пины SDA и SCL.

В autolight.c основная логика работы. Первым делом из main() вызывается функция init(), где мы вырубаем Watchdog и устанавливаем параметры МК. Включаем тактирование от внутреннего источника и ставим предделитель, чтобы получить итоговую тактовую частоту 250 кГц. Да, нам этого с головой тут, зато тайминги I2C можно делать просто одной инструкцией NOP.

Дальше вырубается не используемая аналоговая периферия для снижения потребления.  Ну и соб-но настраивается прерывание INT0.

После init() "инициализируется" I2C через SoftI2CInit() и через функцию apds_init() отправляем в датчик все описанные ранее настройки из .h. В случае ошибки тут и любой ошибки на I2C дальше, вызывается функция reset(), которая через Watchdog сбрасывает МК через 15 мс. Т.е. если связь с датчиком пропадет (отвалится линия или еще что), МК будет пытаться перезагружаться.

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

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

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