Ви не увійшли.
хм. В platformio хоч є кнопка для очистки кешу. а в Arduino ide я її не побачив
Обідно що глюк з логічними рівнями зламався сам по собі
У мене склалося враження, що відтворюваність залежить від того, чи почистили кеш фреймворку після зміни борди в IDE або встановлення іншого BSP. В лінухах він в ~/.cache/arduino/. У IDE ще є свій RAM-кеш в /tmp/arduino-ide2-<sketch_id>/, який зберігається при перезапуску IDE. Але він щось пустий.
Намагався повторити ситуацію - наче IDE при зміні борди перезбирає ядро заново, тільки вже при повторних білдах бере з кеша:
Compiling core...
Using previously compiled file: .../.cache/arduino/sketches/88E89C526180E920CC9AC97AD811FBB4/core/pins_arduino.c.o
Using precompiled core: .../.cache/arduino/cores/digistump_avr_digispark-tiny_3c94b2ea733e4d576f0033e398c581c3/core.a
а надійніше переписати як state machine.
Потрібно його або переписувати з 0
Якщо мета - отримати працюючу програму, то написати з нуля - це найпростіший варіант
Особисто мені, наприклад, було би цікавіше докопатись до причини: в якому саме рядку digitalWrite() скидає стан піна в 0 через неправильно побудовану умову. А для цього потрібно досягти детермінованої відтворюваності в емуляторі при перезбірці прошивки.
Неспортивно
Я так розумію, що тему можна закривати. Так?
Тоді питання. Хто з учасників взявся б за написання нормального коду, з нуля?
Звісно ж, що не безкоштовно.
Пропозиції можна в приват.
Дякую всім за участь.
Обідно що глюк з логічними рівнями зламався сам по собі не люблю коли баг сам приходить і сам зникає.
А врюхати в цей код реально складно. Глобальні змінні, саморобні таймери, умови дивні.. Спробувати в статичний аналізатор зарядити? Можна спробувати по черзі біля кожного digitalWrite додавати свій blink и дивитись де воно вистрелить. а надійніше переписати як state machine.
Цей глюк відтворюється навіть в нано, принаймні в протеусі (звісно що порти 0,1 змінив на інші). Проблема тут явно не в тінці і не з епром. Щось не те в Датському королівстві коді. Потрібно його або переписувати з 0 або їсти частинами поки не вилізе цей баг
stas_amp пише:Якщо у Вас все це проінстальвано, й налаштовано, чи можна Вас попросити, скомпілювати прошивку, для проби?
Та льогко: DigiSpark_Oiler_Moto_hex.zip
Ось тільки знайшов хвилину, щоб перевірити все.
Записав через програматор.
Спочатку на виході, на мотор, нічого не було.
Довге утримання кнопки, і все запрацювало..... Але не довго, мабуть 20 імпульсів зробило, в знову PWM, тільки ще гірше. Його відсотків 20 тільки.
От так.
З кожним постом, спробою, опускаються руки, і є бажання, просто, і без заморочок залишитися на простому блінкері, з поправкою тайменгів, і спокійно жити далі.
Якщо в учасників обговорення ще є сили, час та натхнення, то я готовий, разом з Вами, іти далі.
Якщо ні, то блінкер, і крапка.
Ще раз, всім щиро вдячний.
Це на PB1 чи на PB2?
РВ2
Чому ж, в C++ and, or, not - така ж валідна форма булевих операторів, як і &&, ||, !. Сам іноді використовую таку форму.
Воно то так, але настоящщі ардуїнщики так майже не пишуть
В протеусі аналогічно
Це на PB1 чи на PB2?
Присвюювання змінним типу boolean HIGH або LOW теж якось око ріже.
Теж звернув увагу, дивний "стиль". Хоча з точки зору мови все валідно.
та й (millis() > (durationLongPressMode + btnModeNoLongPressed)) and (LongPressMode == HIGH)
не зовсім з тієї опери
Чому ж, в C++ and, or, not - така ж валідна форма булевих операторів, як і &&, ||, !. Сам іноді використовую таку форму.
Думаю, якщо його переписать в стилі state machine - буде хоч більш зрозуміло що там відбувається.
В протеусі аналогічно
конструкції типу
Присвюювання змінним типу boolean HIGH або LOW теж якось око ріже. та й
(millis() > (durationLongPressMode + btnModeNoLongPressed)) and (LongPressMode == HIGH)
не зовсім з тієї опери
jokeer пише:проблема, схоже, була в кривій реалізації eeprom
Не схоже. Прибрав eeprom взагалі. Картина маслом залишилась та сама
https://forum.arduino.ua/img/members/2306/oil4.jpg
Ядро офіційне digispark-івське ще з часів його підтримки. IDE 1.8.19
Це підблимування не в такт бачу на світлодіоді, але тільки в режимі надто довгого утримання кнопки. Мене воно не бентежить, і не бентежило. Якось не звертав на нього увагу.
Цей проект квові вип'є більше, чим віллє мастила на цеп.
проблема, схоже, була в кривій реалізації eeprom
Не схоже. Прибрав eeprom взагалі. Картина маслом залишилась та сама
Ядро офіційне digispark-івське ще з часів його підтримки. IDE 1.8.19
Ну так і так millis переповниться через 50 днів.
millis не "переповнюється", для unsigned типів застосовується модулярна арифметика.
Чи для unsigned переповнення при відніманні не undefined behavior?
Для unsigned і при додаванні ніякого undefined behavior нема.
Просто порівнювати потрібно інтервали, а не точки часу.