Форум arduino.ua

Arduino ISP - це програматор у вигляді окремого пристрою на базі attiny: https://docs.arduino.cc/retired/boards/arduino-isp
Вам потрібно, як зазначено вище, Arduino as ISP.

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

Ну, значення Buffer[0], Buffer[3] та Buffer[4] відповідають тим, на які перевіряєте. Що не так?

Ви впевнені, що саме таку послідовність має видавати дисплей? Це десь зазначено в описі протоколу?

Так умова спрацьовує тільки коли набереться 20 байт ТА байти у певних позиціях мають певні значення.

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

Тут же всі символи зливатимуться, "1 23" не відрізнити від "12 3".

for (auto i : Buffer) {
    Serial.print(i, HEX);
    Serial.print(' ');
}

Або, з лідируючими нулями:

for (auto i : Buffer) {
  char s[4];
  snprintf(s, sizeof(s), "%02x ", i);
  Serial.print(s);
}

Взагалі, якщо вся комунікація з дисплеєм іде по послідовному порту, а чіткого опису протоколу немає, я би для початку підʼєднав би його до компа і відлагодив комунікацію у програмі для компа, без всяких ардуін. На будь якій мові, яку знаєте, хоч C#, хоч Python, чи що інше. Потім би уже портував на ардуіну.

Та там весь код наркоманський.
Навіщо аж три таймера з однаковим інтервалом?

В ReadSerial()

      if (Buffer[0] == 0X5A & Buffer[3] == 0X83) {
          if (Buffer[4] == 0X50) {           

виконується навіть коли прочитано лише 1 байт, а в Buffer[3] і Buffer[4] може бути хто зна шо.

Точніше, в Buffer[3] і Buffer[4] значення ніколи і не записуються, бо як тільки прочитано один байт, Buffer_Len скидається в нуль.

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

Взагалі, якщо Serial читається побайтно, навіщо зайвий раз перевіряти available()?

Це:

if (Buffer[0] == 0X5A & Buffer[3] == 0X83)

з логічної точки зору працюватиме, але семантично мабуть малось на увазі

if (Buffer[0] == 0X5A && Buffer[3] == 0X83)

Можна припустити, що відображається число (N*256+M)/100, де N - перший байт двічі в BCD, M - другий байт один раз в BCD. Але це якесь збочення. Там же в цих дисплеях наче програмується формат даних для відображення. Може варто перепрограмувати сам дисплей, щоб сприймав дані у нормальному форматі, аніж підганяти дані під такий дивний формат?

О, це вже щось. Для 0x00 0x22 я би сказав, що це BCD, але тоді для 0x22 0x00 було би 22.00. Гіпотеза про BCD не підтверджується. Які значення на дисплеї відповідають наступним записаним значенням:
0x01 0x00
0x00 0x01
0x80 0x00
0x00 0x80
0x55 0x55
?

Тип float в C++ - це 4 байта (в більшості реалізацій це IEEE 754). В 2 байта без втрати точності вони не влізуть. В якому конкретно форматі потрібно представити значення float? Який порядок байт, little endian чи big endian?

Є здогадка, що ви хочете відображати температуру у вигляді двозначного десяткового числа. Якщо так, то для цього ніякого конвертування float в HEX не потрібно. Що за дисплей? В якому форматі він очікує дані, ASCII-коди символів?

Тут нічого специфічного для ардуіно, тут основи C++. В ардуіно хоч і недо-, але все таки підмножина С++. Потрібно навчитись читати код і діагностику компілятора, він же все підказує.

А якщо мета - навчитись програмувати, то вивчати C++ на прикладі ардуінівських бібліотек категорично не рекомендую.

Так звідки ви її взяли? Схоже, що та бібліотека - якась обгортка для Adafruit SSD1306, а ви їй даєте LiquidCrystal_I2C.

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

0,01 mF - це 10 uF, або 10000 nF, або 10000000 pF.

Там же в скетчі явно написано:

  if (microFarads < 0.01) {
    microFarads = 0.00;  // Set to 0 for values below the threshold
    u8g.print("Unknown !");

тобто менше 10000 pF (0.01 uF) не показувати, бо немає сенсу.

Так у вас час вимірюється з гранулярністю 1 мс. При опорі 1 МОм це відповідає ємності 1 нФ. Тобто якщо наміряли 1 мс, то ємність може бути десь від 0 до 2 нФ, якщо наміряли 2 мс, то ємність десь між 1 і 3 нФ.

Це якби в millis() не було джиттера. В 16МГц ардуіно millis() оновлюється з частотою ≈976 Гц, тобто спочатку відстає від реального, потім стрибком "наздоганяє". Крім того, час вимірювання АЦП також вносить похибку.

Такий метод дозволяє приблизно оцінити порядок величини ємності, але аж ніяк не вимірювати нанофаради.

Збільшення опору резистора в 4 рази теоретично збільшує роздільну здатність в 4 рази. Але тільки теоретично. Дивіться коментар вище щодо sample and hold конденсатора в АЦП. Ні про які 0.01 нФ (10 пФ) не може бути мови.

Можна було би заміряти час за допомогою micros() із вимкненими перериваннями. Але все одно, на малих ємностях S/H конденсатор в АЦП уже впливатиме.

По-хорошому, потрібно використовувати capture event в TIMER1 і аналоговий компаратор.

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

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

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

4.02 МОм, відхилення менше 1%. В ряді E48 можуть попадатись і практично точні 4 МОм.
Або 2×2 МОм послідовно.

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

Мене більше приколює, що вони привʼязались до рівня саме 63.2%, хоча можна брати будь-який поріг, наприклад 1/2.

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

Та думаю, зручніше, коли окреме питання - окрема тема.