Форум arduino.ua

Якщо цікаво, примітивний варіант реалізації ring buffer фіксованого розміру з моєї відповіді на StackOverflow:

template <typename T>
class ring
{
    T *data;
    std::size_t size;
    std::size_t front { 0 };
    std::size_t back  { 0 };
    bool full { false };
public:
    ring(std::size_t _size) : data{new T[_size]}, size{ _size } {}

    ~ring() {
        delete [](data);
    }

    bool enqueue(T value) {
        if (full) {
            return false;
        }
        data[back] = value;
        back = (back + 1) % size;
        if (back == front) {
            full = true;
        }
        return true;
    }

    T dequeue() {
        if ((front == back) && !full) {
            return {};
        }
        full = false;
        std::size_t old_front = front;
        front = (front + 1) % size;
        return data[old_front];
    }
};

Ініціалізацію з initializer_list та інший синтаксичний цукор за бажанням прикрутити не складе труднощів.

Випадкова перестановка на те і випадкова, що елемент може залишитись на своєму місці з ймовірністю 1/N.

Он в Енігмі, наприклад, вхідна літера теж ніколи не транслювалась сама в себе

Такий алгоритм теж існує. Тільки він вимагає, щоб допоміжні елементи були унікальними, інакше розподіл вже не буде випадковим. А генерація випадкових унікальних елементів потребує випадкової перестановки

І алгоритмічна швидкодія обмежена обраним алгоритмом сортування. Для сортування вставкою найгірший випадок О(n²).
А результат такий самий: елемент також із ймовірністю 1/N може залишитись на своєму місці.

Інша справа, що ардуінівска random(long) реалізована некоректно і не дає рівномірного розподілу. Але якщо не потрібна криптографічна надійність, то для невеликих діапазонів цей ефект не дуже суттєвий.

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

Тому, щоб отримати корисні поради, потрібно давати більше інформації про проблему.

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

Правильно розумію, що кнопка послідовно зі споживачем, "входом" до живлення 29 В, які з "вихода" при натисненні подаються на споживач? Споживач має реактивну складову чи суто активний? Відбуваються якісь перехідні процеси при відпусканні кнопки? Чи допустимий невеликий струм (порядка десятків мікроампер) через споживач у вимкненому стані?

Є різні варіанти, в кожного свої переваги і недоліки, в залежності від схеми підключення вашої кнопки, характеру навантаження та інших вимог. Наприклад:

1) Дільник напруги на резисторах.
2) Діод і резистор.
3) Перетворювач рівня на транзисторі (ймовірно, знадобиться ще стабілітрон).
3.5) Комбінація попередніх.
4) Оптопара.

Чому відповіддю в іншій темі, а не окремою темою? В "Апаратних питаннях", наприклад.

Зі схемою наче все ок. Про всяк випадок, другий операційник, що в цьому ж корпусі, встановили у детермінований стан?
Якщо прибрати резистори і вихід подати напряму на інвертуючий вхід, працює як повторювач?

Так то сервер, який використовується автором для підтримання бази на цільових пристроях в актуальному стані. Наскільки бачу, його використання можна вимкнути, прибравши EZTIME_NETWORK_ENABLE. Або підняти свій аналогічний.
Якщо апдейтити прошивку з базою вручну, то для конвертації часу доступу до мережі не потрібно.

В сучасній базі теж є Kiev, бо зворотня сумісність. Kyiv та Kiev - два файла з однаковим вмістом.
Актуальна база розміщується на https://www.iana.org/time-zones, також доступна по FTP та rsync. Звідти її і потрібно брати.

Обчислення для поточного часу не дуже складні. Це ж не обчислення, наприклад, періоду між моментами локального часу в минулому, де потрібно враховувати всі зміни, що відбулись за цей період. Основна проблема - це підтримка zoneinfo в актуальному стані.
Як компроміс, можна конвертувати час в UTC засобами браузера при налаштуванні будильника, а сам контроллер працюватиме лише з UTC. Тільки тоді, якщо zoneinfo зміниться, то будильник "не знатиме" про ці зміни до наступного налаштування.
Але звісно, якщо функция не потрібна, то і заморочуватись не варто.

Саме тому для типових задач рекомендується використовувати існуючі перевірені рішення. Хоча бібліотек ардуіно це не стосується, бо там зустрічається і не таке 

Який саме board package використовуєте для attiny85? Ви впевнені, що в ньому піни нумеруються константами з avr/io.h ( pinMode(PB3, INPUT) ) і в той же час ардуінівськими ( pinMode(A1, INPUT) )?

Форматування коду навмисно прибране, щоб складніше було читати? 

Із назвами змінних Flag, Flag2, Flag3 та значеннями '1' і '2' задуману логіку зрозуміти досить непросто. Намалюйте діаграму переходів між станами, визначте умови переходів. Зробіть enum зі зрозумілими назвами.

pulseIn() повертає unsigned long (діапазон ≈ 0 .. 4295 секунд), ви його присвоюєте в int (діапазон ≈ -33 .. 33 мілісекунди).

Не викликайте millis() кожний раз. Прочитайте значення один раз на ітерацію і використовуйте його:

void loop() {
    unsigned long now = millis();
    ...
    timer1 = now;
    timer2 = now;
    ...

Затримка перед читанням ADC мала би сенс після вмикання внутрішнього джерела опорної напруги, щоб воно встигло стабілізуватись. Даташит говорить про час стабілізації 40-70 мікросекунд.
Ардуіно, по-перше, в якості опорної напруги за замовчуванням використовує Vcc; по-друге, конфігурує ADMUX всередині analogRead(). Так що затримка перед analogRead() не має жодного сенсу. Просто зробіть одне читання в setup() та проігноруйте його результат.

Якщо передавач має зчитувати та відправляти дані з певною частотою, то краще вже використовуйте millis().
На приймачі взагалі ніяких затримок не потрібно.

Просто майте на увазі, що відправлені в Serial дані хоч і буферизуються, але їх передача з буфера потребує часу. Щоб мінімізувати вплив дебажного вивода на роботу, використовуйте вищий бітрейт, наприклад 115200.

1602 - це алфавітно-цифровий дисплей? Не дуже зрозумілий його звʼязок з float. Ну то таке.

Простий не значить правильний.

1. В приймачі ви намагаєтесь читати дані навіть коли їх нема. SofSoftwareSerial::read() при цьому повертає -1.
2. В передавачі затримка між посилками 10мс (+ якийсь час на виконання інших функцій). В приймачі затримка між спробами читання 200 мс. Приймач навіть теоретично не встигатиме читати всі відправлені передавачем дані. Навіщо взагалі в приймачі ця затримка 200 мс?
3. Кожну ітерацію в UART пишеться більше десятка байт ("Zadanie = " плюс саме значення та r). На 9600 бод їх передача займає  більше 10 мс. В передавачі з часом внутрішній буфер Serial заповнюється і Serial.print() блокує виконання поки буфер не звільниться.
До проблеми не відноситься, але все ж:
4. Навіщо там використання типу float?

Я би порадив для початку відлагодити комунікацію при безпосередньому TTL-зʼєднанні приймача з передавачем. Тільки після того як все працюватиме правильно, зʼєднувати по RS485.

А репозиторій Espressif уже підключений "іскаропкі"? Я не в курсі, може вже й додали.

В File -> Preferences -> Settings -> Additional boards manager URLs додайте

https://arduino.esp8266.com/stable/package_esp8266com_index.json

Далі як звичайно, оберіть плату і порт.

Яка версія датчика? Який режим роботи сконфігуровано на платі? Для версії 2.0 описано 3 режими, а для
версії 3.0 цілих пʼять.
Крім того, в режимі UART передається 4 байти: 0xFF, high data, low data і контрольна сума, а ви читаєте тільки два.