Форум arduino.ua

Чому це? Від конкретної дитини залежить. У 8 років я вже ZX Spectrum на бейсіку програмував.

Але тоді цей програмований модуль не потрібен. Звичайний модуль з реле плюс Arduino або будь-який інший контролер. Якщо потрібна привʼязка до реального часу, то ще плюс модуль RTC.

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

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

Так ардуїно може "вийти з ладу" і залишити пін в будь-якому стані, в тому числі тримаючи транзистор відкритим.
Взагалі, ні ардуіно, ні будь-яка інша схема не повинна керувати лампами, тільки аналізувати струм.

Щось там у вас дуже дивне відбулося. Якщо в тойотівському блоці такий же принцип як в тому вазівському, то він не керує самими лампами. Струм ламп тільки проходить через шунти (оті дротяні "перемички" на фото мабуть вони і є). Тобто щоб перестало працювати все, потрібно щоб одночасно згоріли всі шунти або доріжки до них. Ну, ще чисто теоретично, один із входів могло би коротнути на масу і згорів би запобіжник.
Хоча, не виключаю, що там якийсь зовсім інший принцип, і ті мікросхеми дійсно керують лампами.

Якщо дуже умовно і приблизно, то так:

while (true) {
    if (analogRead(pinInPos) < analogRead(pinInNeg)) {
        digitalWrite(pinOut, LOW);
    } else {
#ifdef OPEN_DRAIN_OUTPUT
        pinMode(pinOut, INPUT);
#else
        digitalWrite(pinOut, HIGH);
#endif
    }
}

Так отож, спочатку треба схему бачити, що звідки куди йде, а потім уже щось вигадувати.

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

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

Не зовсім зрозуміло, що там у автора за ідея з "захистом" та реле, що та від чого захищати.

Я ж так розумію, там дві або чотири лампи в паралель. Щоб розрізнити "всі живі" від "одна згоріла", потрібно умовно вимірювати опір з точністю 1/N. А опір - це відношення напруги до струму. Якщо напруга фіксована, достатньо виміряти тільки струм. Але ж напруга не фіксована. Тому при вимірюванні абсолютного значення струму необхідна така точність, щоб дозволяла відрізняти "всі живі" при мінімальному значенні напруги від "одна згоріла" при максимальному. Або вимірювати відносний струм. Датчик і так видає напругу, пропорційну струму. ЇЇ достатньо порівнювати з напругою, пропорціїною напрузі бортової мережі. Тоді абсолютне значення напруги бортової мережі не має значення.

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

Не дуже зрозуміло, що значить "зчитувала опір всіх ламп"? Ви хочете відключати лампи від бортової системи, подавати тестову напругу та вимірювати струм? Чи вимірювати струм за наявності напруги увімкнення?

За яким критерієм збираєтесь визначати, що ардуїно вийшло з ладу?

Якось занадто кучеряво. Вам як мінімум доведеться узгоджувати бортову напругу 12-14.5 В з напругою I/O ардуіно. Причому для ланцюгів габаритів та стопів окремо.

Тут мало би бути достатньо вимикати індикаторну лампу, коли струм в ланцюгу ламп перевищує пороговий. Тобто датчик струму (шунт?), компаратор та транзистор.

А, тепер зрозумів.
Як варіант - сам датчик на рухомій частині, а магніти в крайніх стаціонарних положеннях.
Ще варіант без кінцевика - моніторити струм двигуна. Але може знадобитись фрікцион. Бо якщо момент у двигуна великий, та ще й червʼячна передача, то поки система зреагує на зростання струму, може встигнути щось поламати.

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

Дуже приблизна оцінка порядку величин: ESP32 в активному режимі споживає біля 20 мА (а вона скоріш за все буде в активному, бо потрібно читати ADC і писати на флешку). Ємності 3000 мкФ після діода при падінні напруги з 5 В (не з 12, бо LM7805 зʼїдає 7 вольт) до 3 В (берем як мінімум для ESP32) має вистачити десь на 300 мс. Теоретично можна встигнути. Але це дуже оптимістична оцінка. Якщо працює вайфай, споживання ESP32 може бути в 3-4 рази більше. Якщо замкенене реле, це ще +30 мА.

12 вольт іде з мережевого БЖ? Я б запропонував детектити наявність напруги AC мережі. Баластний конденсатор + 814 оптопара (або 817 паралельно з діодом). Тоді в запасі вся ємність БЖ, в тому числі й високовольтна.

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

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

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

Так, на передавачі. Наприклад, наміряли 13.6 В, 18.2 А. Передавач формує строку: "\002U: 13.6 V\nI: 18.2 A\003" і відсилає її.
Тут для прикладу застосовано символи керування ASCII:
'\002' - STX, start of text
'\003' - ETX, end of text
'n' ('\012') - LF, line feed

Приймач отримує цей потік байтів і обробляє символи керування.
Коли приймає '\002' - встановлює поточну позицію для виводу на початок екрана: row=0, col=0.
Коли приймає '\003' - очищає екран від поточної позиції до кінця екрана.
Коли приймає 'n' - переміщує поточну позицію на початок наступного рядка: row=row+1, col=0.

Інші ASCII символи просто виводить на екран у поточну позицію (row, col) та зсуває її на наступну: col=col+1.

Як організувати звʼязок - залежить від потрібної дальності та надійності. Можна взагалі взяти пару так званих "бездротових подовжувачів UART" на 433 МГц і передавати/приймати як через звичайний UART.
Можна приймати і по NRF24, але виводити не на окремий дисплей, а в смартфон через USB-UART конвертор.

Звісно, можна передавати і не готовий потік символів для відображення, а "сирі" дані, і обробляти їх уже на приймачі. Але тоді потрібно розробляти хоч і примітивний, але протокол передачі. А там і до protobuf чи efficient XML interchange недалеко. Воно вам треба?

Взагалі, розбийте задачу на окремі підзадачі:
1. Звʼязок
2. Формат даних (протокол)
3. Відображення інформації
і вирішуйте їх окремо.

Не дуже розумію, що значить "всередині на ifdef". Застосовуються директиви препроцесора для умовної компіляції? Так це нормально, так забезпечується кросплатформенність. Тим більше, коли фреймворк не надає інших засобів. Та й ліби від Adafruit - теж далеко не взірець хорошого коду.

Так отож, що "якось". В core умовна компіляція в основному для різних цільових платформ, які взаємовиключні при збірці.
Поблимати світлодіодом та намалювати прямокутник на єдиному дисплеї - це ще ок. А коли потрібно більше одного інстанса з різними параметрами?

Де, в Platform IO? Так з шаблонами те ж саме, навести курсор на ідентифікатор, і спливає підказка, з якими параметрами клас інстанційовано. А в імплементації самого класу по-хорошому не має бути ніяких драбин з if ... else if ... else.