Форум arduino.ua

Тут декілька окремих питань: відтворення звуків, колекція семплів, процедурна генерація.

Якщо не розглядати зовнішні синтезатори типу AY-3-8910, то які варіанти крім PCM? А PCM можна відтворювати хоч ШІМ'ом, хоч пасивним R-2R DACом.

Але у флешку atmega328p, наприклад, при 8 біт @ 8 кГц влізе менше 4 секунд. Можна знизити розрядність до 4 біт, тоді в два рази більше. Можна зберігати семпли у зовнішній EEPROM.

В чому проблема взяти семпли, які не можна "запустити" на мікроконтролері, і конвертувати в такі, які можна? І що значить "запустити"?

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

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

Воно ж уже Microchip Studio, і вже не рекомендується для нових розробок Рекомендують користуватись MPLAB X IDE.

Хіба воно платне в базовій версії? Щось не знайшов, скільки коштує ліцензія.
Мені не подобається, що воно проприєтарне. Microchip Studio взагалі наче тільки під вінду. MPLAB X IDE встановлювати їхнім інсталлером якось не комільфо. А пакет з неофіційного репозиторію хоче Java8 JDK, коли на дворі вже Java24.
Та й не факт, що воно не таке ж глючне як і саморобки.

Бачу, цей simavr ще навіть ворушиться, є недавні комміти. Але якось на рівні аматорської поробки. Вивод стану пінів у VCD працює, але тільки з GPIO портів. Зміна стану по Compare Match Output, наприклад, ніяк не відображається. Інші альтернативні функції пінів не перевіряв. Схоже, що це "by design". Якщо так, то толку з такого емулятора небагато. 
Доречі, є і ще один форк.

І то правда. Шʼєм програматором - в еепромці або 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

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