Форум arduino.ua

Який діапазон швидкостей обертання?

Енкодер не видає значення, енкодер видає сигнали. Як ви їх обробляєте?

Щось все одно не дуже ясно. Бачу три перемикачі 4P1T і один 2P1T. Але 4P мають ще одне положення, у якому повзунок "висить у повітрі"?

Тобто при такому положенні перемикачів як на малюнку:
вимір №1: outPin=A0, inPin=A2  (ємність між повзунками верхнього і нижнього перемикачів)
вимір №2: outPin=A1, inPin=A2  (ємність між провідником від A1, що йде до одного з контактів верхнього перемикача, і повзунком нижнього перемикача)
?

По малюнку він підключений до повзунка перемикача. Повзунок може мати помітний ємносний звʼязок з контактами, в залежності від конструкції.

А якщо потім знову перша пара?

Після деструкції обʼєкта CapacitorLite перед створенням нового ви переводите outPin у його початковий стан - floating input?

В конструкторі CapacitorLite вони уже переводяться в output з низьким рівнем. Але при створенні нового обʼєкта з іншим значенням outPin, попередній залишається в output. inPin, наскільки розумію, в даному випадку залишається тим же.

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

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

Що за блок? З чого він складається, як підʼєднаний, що на нього подається в "інших режимах"?

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

Плюси: одночасний доступ до декількох бітів у межах однієї GPIO банки; на деяких контролерах можливіть атомарного toggle; зазвичай трохи швидше, трохи менше розмір коду.
Мінуси: не кросплатформно.

На якому контроллері, з яким фреймворком?
Реалізуйте обидва варіанти, заміряйте швидкість або проаналізуйте асемблерний код.

Іноді варто, іноді ні. Залежить від задачі.

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

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

Як сказано вище, у вас чомусь дві бібліотеки, що надають Control_Surface.h. Що таке Control-Surface-main?
Як ви встановлювали Control_Surface? Яку версію?

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

Та наче і Legacy IDE, і 2.x IDE використовують один і той же тулчейн з gcc 7.3.0.

Щойно перевірив: в Arduino IDE 1.8.19 приклад "3. MIDI Interfaces/USBMIDI-Adapter" з Control_Surface версії 2.1.0 компілюється успішно для UNO, якщо замінити "midi_ser {Serial1}" на "midi_ser {Serial}". Але це ніяк не повʼязано з помилкою, що вилазить у автора.

Припускаю, що автор багато років не оновлював тулчейн, і там ще якийсь 5.x. Але це не точно. Потрібно бачити лог компіляції.

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

100%

Ні, не памʼятаю такого в своїй біографії)

Therac-25? Якраз після того інциденту вимоги до сертифікації в мед.індустрії були переглянуті та суттєво посилені.

Яка там у автора мотивація використовувати STM32 і RTOS для цієї задачі - то не моя справа) Я про загальну тенденцію в індустрії, де "не влазить в STM32F103 - візми STM32F411", бо так виходить дешевше.

В розробці так завжди За виграш в одному доводиться платити чимось іншим.

Можна відмовитись від ардуіно фреймворка і збирати прямо з FreeRTOS. Звісно, бібліотеки, що використовують ардуіно-специфічні API, доведеться або адаптувати, або замінити, або реалізувати самому.

Жирне воно буде в будь-якому разі. 32 кілобайта на 32-бітній архітектурі - це не ті ж 32 кілобайта на 8-бітній.   

Доречі, хіба у 1602 дисплея рідний інтерфейс - I2C? Там же мабуть HD44780 і екстендер типу PCF8574. Якщо підключити через рідний інтерфейс, то не потрібно ні Wire, ні I2C HAL. Датчик MAX6675 на SPI же наче б то.

Що у вас за конфігурація platformio?
Які саме ліби використовуєте?

Для термостата що там потрібно? Регулятор та примітивний UI. Не дуже розумію, навіщо там RTOS.

А objdump що показує? Окрім .text є ще секції .data та .rodata.

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

Їх може і який-небудь snprintf() притягнути.

Так це мабуть ардуінівська Wire. Вона дурна.
UPD: сама по собі HAL_I2C_EV_IRQHandler() в stm32f1xx_hal_i2c.c монструозна. Не розумію, навіщо імплементувати і master, і slave mode в одному місці одночасно.