Ви не увійшли.
https://raw.githubusercontent.com/ArminJo/DigistumpArduino/master/package_digistump_index.json же ж. Без ніяких хитрощів.
А, в 1.7.5 EEPROM уже є в поставці. Тільки IDE навіть з verbose mode не показує як її компілює, тільки Compiling library "EEPROM".
Але автор писав, що доставляв ще якусь додатково. От якщо ліби з однаковими іменами є і в packages/digistump/hardware/avr/1.7.5/libraries/, і в ~/Arduino/libraries, яку з них воно бере? Це тільки з лога збірки можна побачити:
Alternatives for EEPROM.h: [EEPROM@2.0]
ResolveLibrary(EEPROM.h)
-> candidates: [EEPROM@2.0]
...
Using library EEPROM at version 2.0 in folder: ...
І який там Clock обрано в меню, теж може впливати.
Є підозра що емулятор цього не покаже. Якщо косячаться логічні рівні на виході - значить там всередині щось комутується неправильно.
Якщо апаратний баг, то так. Але в datasheet errata нічого такого нема. Тільки для ревізії A "EEPROM read may fail at low supply voltage / low clock frequency".
А у випадку програмного багу як мінімум стан регістрів можна перевірити. Взагалі можна було б і просто асемблерний код проаналізувати, але мені за то не заплатять
До речі, в якійсь з ревізій цих tiny85 щось було з eeprom, саме з записом в 0 адресу, і були рекомендації від аксакалів починати запис з 10..
Наскільки знаю, то якщо бутлоадер теж використовує EEPROM для збереження своїх даних. Micronucleus такого не робить наче.
А так, відчуття якоїсь незавершеності.
У мене це відчуття щодо більшості інструментів для розробки під МК
Якраз нещодавно хотів в simavr перевірити ту багу з attiny85. Але ж ні URL та версії тієї EEPROM бібліотеки, ні опцій збірки так і не отримав, щоб відтворити збірку 1-в-1.
У когось вийшло?
Колись трошки грався з самим simavr (не в рамках platformio). Ну, воно працює, вивод на UART показує в консолі, gdb чіпляється як до будь-якої іншої remote target. Але для моніторингу периферії потрібно додавати код в саму фірмварь.
Якщо у Вас все це проінстальвано, й налаштовано, чи можна Вас попросити, скомпілювати прошивку, для проби?
Та льогко: DigiSpark_Oiler_Moto_hex.zip
Тобто, я встановлюю цей софт, копіюю текст скетчу, вставляю скопійоване, додаю Arduino.h на початку, отримую hex, пишу його в плату, через програматор.
Так?
Як під віндою його ставити і користуватись не знаю, вибачте. Під лінухами я просто встановив пакет 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/
Якщо так, то чи підійде цей код, чт треба все переписувати заново?
Може що порадите?
PlatformIO
Скетч збирається без переписування, тільки в самому початку додати
#include <Arduino.h>
Стосовно еепрому.
Може його прочитати програматором, і глянути, де нічого не пишеться, і саме туди писати дані.
Чим писати, бібліотекою EEPROM, яка в EEPROM нічого не пише, а пише в регістри або RAM?
Спершу впевніться, що проблема викликана записом в EEPROM. Мої здогадки тільки теоретичні, бо не знаю, яку саме бібліотеку і як ви там встановлювали, і не маю заліза, щоб перевірити.
Також спробуйте зібрати скетч за допомогою platform.io, з його дефолтним framework-arduino-avr-digistump.
Що за бібліотеки мені треба завантажити, щоб все працювало нормально?
Я би спершу зʼясував, чи це проблема з самою лібою EEPROM, чи з функціями eeprom_write_* з avr/eeprom.h. Якщо функції eeprom_write_*/eeprom_read_* працюють нормально, то використав би їх, без всяких бібліотечних обгорток.
А якщо вирішувати глобально, то не користувався би Arduino IDE.
Можете глянути, наче Compare Match Output вимкнуто.
Цей витвір ШІ працює нормально? А якщо в setup() закоментувати запис в TCCR0A?
Може там вказати адресу еепром 100, або 200 ?
Якщо EEPROM працює неправильно, то вона працюватиме неправильно і з іншими адресами. Буде псувати якусь іншу область памʼяті.
Скомпілюйте скетч з нуля, з увімкненим verbose compiler output. Покажіть лог збірки.
Дивіться, яка цікава річ. У вас EEPROM.put(10, ImpulseOilMotor) має записувати два байта в EEPROM за адресою 10.
Якщо припустити, що ваша ліба EEPROM зібрана якось неправильно (з іншим -mcu, наприклад), і замість EEPROM пише в адресний простір даних, то адреса 10 попадає на адресу 0x2A в I/O просторі. Це якраз регістри TCCR0A та OCR1B, які відповідають за Compare Match Output для PWM.
Цікаво, що дає саме PWM.
Ну, один із можливих варіантів я вже написав: пін перемикається на функцію Compare Match Output. Чому - це вже інше питання.
https://forum.arduino.ua/img/members/4083/OSC-_-OUT-PB1.jpeg
У мене ось такий сигнал на PB1
...
https://forum.arduino.ua/img/members/4083/PXL_20250611_042428586.jpeg
Було ж 1.2 вольта, тут бачу чесні 5. Після яких змін амплітуда імпульсів стала 5 вольт?
понавстановлював все, що можна було стосовно Attiny 85.
Потрібно якось фіксувати ці зміни: з якого URL, яка версія. Щоб можна було собі теж скачати та проаналізувати код цього конкретного пакунка.
Частота стала 16кГц, цикл 70 відсотків.
PB1 має альтернативну функцію виходу компаратора таймера. (Доречі, PB0,PB3,PB4 також). Якщо якимось чином біти вибору режима стають ненульові, то це досить очікуваний результат: різні core можуть використовувати таймери по-різному.
Якось би здампити вміст регістрів TCCR0A, TCCR1 та GTCCR, коли баг проявляється. Я би увімкнув debugWIRE. Але без досвіду це буде непросто зробити: потрібно перешивати фʼюзи і вимикати функцію піна Reset, а також підʼєднуватись UART'ом до піна Reset як мінімум через діод, і на компі запускати відлагоджувальний софт.
Можна спробувати записати вміст цих регістрів в EEPROM, потім зчитати програматором.
Але в першу чергу я би все таки перевірив з
#define HAVE_BOOTLOADER 1
в core_build_options.h.
А також мінімізував би програму до такого стану, коли баг ще відтворюється.
Ось схема всього пристрою.
Для повноти картини ще би домалювати USB'шні резистори зі стабілітронами, а також вбудований світлодіод.
входи вільно теліпаються, хз що вони ловлять у вас і що у мене. Їх було б непогано підтягнути чи до 0 чи до VCC - хз як правильно за вашою схемою.
Автор же писав, що є підтяжки по 5.1к. Мені тільки не подобається, що підтяжка на PB3, бо там же ще через 47 Ом стабілітрон в землю. А свої 3.6В стабілітрон тримає тільки при відносно великих струмах, десь 5 мА. При малих струмах через підтяжку на ньому падає десь 3 В, або й менше. Мабуть, тому там і analogRead(). UPD: хоча "analogRead() < 512" це майже те ж саме, що "digitalRead() == LOW", тільки без гистерезису.
Цікаво, чи вдастся відтворити баг з пінами на голій attiny85, без USB-шних стабілітронів та бутлоадера.
Можу лог показати
Будь ласка, якщо не складно. У мене один раз скомпілилось. Потім перезапускав IDE - перестало, каже, нема EEPROM.h. І дійсно, в packages/digistump такого нема. Крім дефолтної arduino та цієї digistump (з https://raw.githubusercontent.com/digistump/arduino-boards-index/master/package_digistump_index.json) ніяких інших пакунків не ставив. Якась китайська чудасія з цим IDE.
Але сайд ефекти дуже дивні.
Ну, чудес не буває. Але причина може бути так глибоко, що у нас може не вистачити засобів до неї докопатись. Наприклад, який-небудь апаратний баг МК, який проявляється тільки при певних хитрих умовах.
Хм, як воно взагалі компілиться, якщо в packages/digistump/hardware/avr/1.6.7/libraries/ нема EEPROM. Ви її доставляли вручну, чи у вас вона є в самому package, а це у мене чомусь нема?
Також підозріле місце: digistump-avr/cores/tiny/core_build_options.h:138
Micronucleus bootloader там часом не залишає таймери в якомусь PWM-режимі? (UPD: Та не схоже)
https://forum.arduino.ua/img/members/3983/2025-06-10_19-06.png
А у вас що за board package?
https://raw.githubusercontent.com/digistump/arduino-boards-index/master/package_digistump_index.json
Як мінімум для плат "Digispark (Default - 16.5mhz)" та "Digispark (16mhz - No USB)" опції компіляції наче правильні.
tiny core 1.6.7 (що в Arduino IDE) старіший за dtiny 1.7.2 (що дефолтовий в platform.io). Але суттєвих відмінностей, які могли би впливати, поки не бачу.
В dtiny 1.7.2 є деякі виправлення, повʼязані з калібровкою тактового генератора. Але не схоже, що це може бути якось повʼязано з вашою проблемою.
Якщо у вас вибрано "Digispark (Default - 16.5mhz)", для експерименту спробуйте "Digispark (16mhz - No USB)". USB ж у вас в програмі ніяк не використовується.
Нажаль, не знайшов у себе attiny85 чи 45, щоб перевірити безпосередньо на залізі. Наче колись купляв, десь були, а нема
не можу прикріпити картинку
Під полем редагування є "Завантаження". Заходите туди, завантажуєте картинку. Клікаєте на неї, копіюєте її адресу, вставляєте в тег [img]<адреса тут>[/img].
Ще б здогадатись, звідки крім 1.2 вольта ще ті 5.2 кГц.
Не дуже розумію, чому стан кнопки зчитується як аналоговий сигнал. Там звичайна механічна кнопка, чи якась особлива? Спробуйте для експерименту
if (analogRead(btnMode) < 512) {
замінити на
if (digitalRead(btnMode) == LOW) {
Не зовсім зрозумів питання.
Ще одне припущення щодо дивної поведінки - що ви збираєте прошивку під якусь іншу плату чи контролер, і воно якимось чином успішно прошивається.
Наприклад, щоб зібрати ваш скетч в platform.io, я обираю плату "digispark-tiny", при збірці воно підтягує пакунок framework-arduino-avr-digistump і компілює з опціями, поміж інших, "-mmcu=attiny85 -DARDUINO_AVR_DIGISPARK -DF_CPU=16500000L".
З якими опціями компілюється прошивка у вас?
версія ардуіно - остання з сайту.
На сайті дві активні версії IDE: Arduino IDE 2.3.6 та Arduino PLC IDE 1.0.8. Як вгадати, яку з них ви поставили?
В репозиторії мого дистрибутиву Arduino IDE версії 2.3.6. Воно знає тільки ардуінівські плати, про DigiSpark нічого не знає.
Віндова збірка "з сайту" підтримує плати DigiSpark "з коробки"? Чи ви додавали board package вручну?
Я пробував додавати https://github.com/ArminJo/DigistumpArduino/blob/master/package_digistump_index.json (який ставиться для platform.io), також http://drazzy.com/package_drazzy.com_index.json. Але IDE все одно не бачить плат DigiSpark. Схоже, це якийсь відомий баг IDE.
Тому й питаю, який пакунок плат ви ставили, щоб зібрати скетч під DigiSpark Attiny85?
Де можна подивитися те, що Ви запитуєте?
File -> Preferences -> Settings -> Additional boards manager URLs. Також, яка плата обрана в Tools -> Board (не тільки назва, а повний шлях в тому меню), Tools -> Processor та інші пункти з опціями збірки.
Також не завадило би в File -> Preferences -> Settings увімкнути "Show verbose output during: compile", зібрати скетч "з нуля" і показати лог збірки.
@stas_amp, доречі, який board package використовуєте для своєї плати? Який URL у package index json?
Мене цікавить, чому себе так поводить контролер.
Документованих способів видавати на пін 1.2 В при живлені 5 В у контролера нема.
Можу припустити, що analogRead() з якоїсь причини перемикає опорну напругу на Vref або на внутрішній опорник (який, доречі, 1.1 В, звідси ваші 1.2 В може і вилазять), а потім намагається вимірювати напругу на цьому ж Vref піні (PB0).
Також не можна виключати, що і сам чіп - якийсь клон з глюками, у всій партії плат.
Так як ніяких особливостей Attiny85 у вас не використовується, перевірте програму на якій-небудь "класичній" платі ардуіно з атмегою.
я задав конкретне питання по програмній частині, в якій я не розуміюся.
Код програми сумбурний, але явних причин для такого глюку поки не побачив. Метод діагностики вже написали: вимикаєте #if'ами або коментуєте спочатку весь функціональний код, перевіряєте. Поступово вмикаєте невеликі частини коду, і дивитесь, після включення якої частини глюк починає проявлятись.
Що дасть вимкення BOD ?
При увімкненому BOD при просадці живлення нижче встановленого рівня (1.8, 2.7 або 4.3 вольт) контроллер гарантовано входить в reset, а не намагається з глюками працювати до останнього.
В заглюченому стані пін може тіліпатись на досить високій частоті, що осцилограф з недостатньою полосою пропускання (або за наявності паразитних ємностей на платі) може цього не бачити.
На саму плату ардуіно даю 14 вольт, на виході стабілізатора чітко 5, і на вході контроллера - теж 5 вольт
Судячи по схемах з інтернета, там перед регулятором нема ніякого конденсатора. А по даташиту має бути.
Живлення там достатньо, перевіряв, та до всього ж, якщо що, то звичайний блінкер там працює без проблем.
Так як ви живите плату у вашій схемі, не в блінкері?
І що показує осцилограф на піні живлення під час глюку?
Може бути таке, що у схемі якийсь із інших виходів зʼєднаний малим опором в землю, а ви видаєте на нього високий рівень (або підтягнутий до Vcc, а ви видаєте низький). Контроллер може намагатись працювати при живлені навіть менше 1 вольта. BOD мабуть же вимкнений у фʼюзах.