Форум arduino.ua

І то правда. Шʼєм програматором - в еепромці або FF'ки, або старий контент, в залежності від фʼюзів та опцій програматора. З першим імпульсом FF'ки стають нулями. Шʼєм бутлоадером - micronucleus еепромку не чіпає, а якийсь інший може й стирає. В різних емуляторах також стан еепромки може зберігатись, а може й ні.

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

Наче ж при кожному імпульсі подачі виконується EEPROM.put(10, ++ImpulseOilMotor).

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

У мене склалося враження, що відтворюваність залежить від того, чи почистили кеш фреймворку після зміни борди в 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

Якщо мета - отримати працюючу програму, то написати з нуля - це найпростіший варіант
Особисто мені, наприклад, було би цікавіше докопатись до причини: в якому саме рядку digitalWrite() скидає стан піна в 0 через неправильно побудовану умову. А для цього потрібно досягти детермінованої відтворюваності в емуляторі при перезбірці прошивки.

Це на PB1 чи на PB2?

Теж звернув увагу, дивний "стиль". Хоча з точки зору мови все валідно.

Чому ж, в C++ and, or, not - така ж валідна форма булевих операторів, як і &&, ||, !. Сам іноді  використовую таку форму.

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

Доречі, в програмі є й інші баги, не повʼязані з сигналом на піні. Наприклад, конструкції типу

if (millis() > (durationVeryLongPressMode + btnModeNoVeryLongPressed))

на граничних значеннях (на 50-й день роботи ) працюватимуть неправильно.

Тепер я зрозумів, чому IDE не показало команди компіляції. Бо ця EEPROM - header only.

Реалізація в avr-libc: libc/misc/eewr_byte.S
Вона в ісходніку виглядає страшно, бо там реалізація для всіх платформ. А в згенерованому коді для attiny85 досить проста:

0000096c <eeprom_write_byte>:
 96c:	26 2f       	mov	r18, r22

0000096e <eeprom_write_r18>:
 96e:	e1 99       	sbic	0x1c, 1	; 28
 970:	fe cf       	rjmp	.-4      	; 0x96e <eeprom_write_r18>
 972:	1c ba       	out	0x1c, r1	; 28
 974:	9f bb       	out	0x1f, r25	; 31
 976:	8e bb       	out	0x1e, r24	; 30
 978:	2d bb       	out	0x1d, r18	; 29
 97a:	0f b6       	in	r0, 0x3f	; 63
 97c:	f8 94       	cli
 97e:	e2 9a       	sbi	0x1c, 2	; 28
 980:	e1 9a       	sbi	0x1c, 1	; 28
 982:	0f be       	out	0x3f, r0	; 63
 984:	01 96       	adiw	r24, 0x01	; 1
 986:	08 95       	ret

А, не знав, що з libc'шними функціями той глюк теж проявляється.

Тоді може це просто сайд-ефект через таймінги, і відповідний delay() замість eeprom_write_byte() так само впливатиме.
А збірка в platformio працює тільки тому що інша версія avr-gcc

У мене це відчуття щодо більшості інструментів для розробки під МК

Колись трошки грався з самим simavr (не в рамках platformio). Ну, воно працює, вивод на UART показує в консолі, gdb чіпляється як до будь-якої іншої remote target. Але для моніторингу периферії потрібно додавати код в саму фірмварь.

Як під віндою його ставити і користуватись не знаю, вибачте. Під лінухами я просто встановив пакет platformio-core з репозиторію.
Створюю директорію і проект в ній:

$ mkdir test-project
$ cd test-project
$ pio project init -b digispark-tiny

Копіюю ваш скетч в test-project/src/, дописую на початку "#include <Arduino.h>", збираю:

$ pio run

(а краще "pio run -v", щоб бачити, які команди воно викликає).
Для прошивки зазвичай достатньо

$ pio run -t upload

Для digispark-tiny, мабуть, повинно так само працювати. Принаймні у мене воно скачало й запустило micronucleus, просить підключити плату.

Всі налаштування в platformio.ini.
Бінарик, hex та інші артефакти лежать в .pio/build/digispark-tiny/

Чим писати, бібліотекою EEPROM, яка в EEPROM нічого не пише, а пише в регістри або RAM?
Спершу впевніться, що проблема викликана записом в EEPROM. Мої здогадки тільки теоретичні, бо не знаю, яку саме бібліотеку і як ви там встановлювали, і не маю заліза, щоб перевірити.

Також спробуйте зібрати скетч за допомогою platform.io, з його дефолтним framework-arduino-avr-digistump.

Цей витвір ШІ працює нормально? А якщо в setup() закоментувати запис в TCCR0A?

Якщо EEPROM працює неправильно, то вона працюватиме неправильно і з іншими адресами. Буде псувати якусь іншу область памʼяті.

Скомпілюйте скетч з нуля, з увімкненим verbose compiler output. Покажіть лог збірки.