Ви не увійшли.
stas_amp пише:Тобто, я встановлюю цей софт, копіюю текст скетчу, вставляю скопійоване, додаю 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 це таки ваше рішення Тупо зібралось, прошилось. На P1 нормальний 0, на P2 - іноді нормальні 5В імпульси. Без провалів. Дивно трохи - індикаторний LED прикрутити не до ноги з LED, а до іншої
- framework-arduino-avr-digistump @ 1.7.2
- tool-micronucleus @ 1.250.210222 (2.50)
- toolchain-atmelavr @ 1.70300.191015 (7.3.0)
Походу, framework 1.7.5 що в arduino ide якийсь кривий. Зручно коли все автоматизовано, але коли автоматизовано криво то це ПЦ
Хоча platformio той ще ПЦ всередині Просто повезло.
Остання редакція jokeR (2025-06-11 16:47:37)
Неактивний
Якщо у Вас все це проінстальвано, й налаштовано, чи можна Вас попросити, скомпілювати прошивку, для проби?
Та льогко: DigiSpark_Oiler_Moto_hex.zip
Неактивний
Вставлю і я свої 3 копійки картинки з логаналізатору
Як видно - ШИМ з частотою 5 кГц з’являється лише на РВ2 (LEDMode) при довгому натисканні кнопки.
Спробуйте тимчасово вимкнути в коді (закоментувати) все що стосується індикації
Неактивний
Там цікава проблема, схоже, була в кривій реалізації eeprom в саме цьому BSP саме для Arduino IDE. При ініціалізації eeprom щось писалося не в ті регістри, і виходи переходили в дивний стан, коли логічні рівні якось міксуються як аналогові сигнали.
Ну, якщо лампочка буде трохи блимати, думаю це допустимо може так і задумано.
@JokeR, вам же наче вдавалось відтворити баг? А можете зашарити .lst-файл прошивки, на якій баг стабільно відтворюється? IDE наче створює .lst при експорті бінарика і кладе його поряд.
Неактивний
Доречі, в програмі є й інші баги, не повʼязані з сигналом на піні. Наприклад, конструкції типу
if (millis() > (durationVeryLongPressMode + btnModeNoVeryLongPressed))
на граничних значеннях (на 50-й день роботи ) працюватимуть неправильно.
Неактивний
@л@!
Не відтворилось.
Я здивований.
Тут ще можливо, що в мене якось в board urls було і digistump 1.6.7 (офіціально протухший), і 1.7.5 (неофіціально свіжий), різні репозиторіі, однакові назви.. хз.. Видалив всі, встановив тільки 1.7.5.. не відтворюється. Може @stas_amp це ще не виправив, і в нього ще все зламане
на 50-й день роботи
Для мотоцикла не думаю що це сильно актуально Які є кращі ідеї? Є якийсь софтовий таймер, чи підпирати перевірками?
Неактивний
Вчора так і не дістався до цієї грачки.
А якщо вирізати частину, яка рахує кількість спрацювань насосу, це зробить стабільним пристрій?
Якщо так, то я й сідушку підніму, щоб глянути, що там з мастилом.
Одне б що залишити, так це пам'ять вибраного редиму.
Це б не вадило.
Якщо можна, то виріжте той шмат.
Дякую.
Неактивний
А якщо вирізати частину, яка рахує кількість спрацювань насосу, це зробить стабільним пристрій?
Так як точної причини глюку ми не знаєм, то перевірити це може тільки той, у кого є пристрій.
Неактивний
>> А якщо вирізати частину, яка рахує кількість спрацювань насосу, це зробить стабільним пристрій?
Та хтозна. А в чому нестабільність?
>> if (millis() - btnModeNoVeryLongPressed > durationVeryLongPressMode)
Ну так і так millis переповниться через 50 днів. Чи для unsigned переповнення при відніманні не undefined behavior?
і взагалі я б туди rgb led вкрутив. або хоча б 2-колірний . Було б красиво
Ну так і так millis переповниться через 50 днів.
millis не "переповнюється", для unsigned типів застосовується модулярна арифметика.
Чи для unsigned переповнення при відніманні не undefined behavior?
Для unsigned і при додаванні ніякого undefined behavior нема.
Просто порівнювати потрібно інтервали, а не точки часу.
Неактивний
проблема, схоже, була в кривій реалізації eeprom
Не схоже. Прибрав eeprom взагалі. Картина маслом залишилась та сама
Ядро офіційне digispark-івське ще з часів його підтримки. IDE 1.8.19
Неактивний
jokeer пише:проблема, схоже, була в кривій реалізації eeprom
Не схоже. Прибрав eeprom взагалі. Картина маслом залишилась та сама
https://forum.arduino.ua/img/members/2306/oil4.jpg
Ядро офіційне digispark-івське ще з часів його підтримки. IDE 1.8.19
Це підблимування не в такт бачу на світлодіоді, але тільки в режимі надто довгого утримання кнопки. Мене воно не бентежить, і не бентежило. Якось не звертав на нього увагу.
Цей проект квові вип'є більше, чим віллє мастила на цеп.
Остання редакція stas_amp (Вчора 20:28:12)
Неактивний
В протеусі аналогічно
конструкції типу
Присвюювання змінним типу boolean HIGH або LOW теж якось око ріже. та й
(millis() > (durationLongPressMode + btnModeNoLongPressed)) and (LongPressMode == HIGH)
не зовсім з тієї опери
Неактивний
Думаю, якщо його переписать в стилі state machine - буде хоч більш зрозуміло що там відбувається.
В протеусі аналогічно
Це на PB1 чи на PB2?
Присвюювання змінним типу boolean HIGH або LOW теж якось око ріже.
Теж звернув увагу, дивний "стиль". Хоча з точки зору мови все валідно.
та й (millis() > (durationLongPressMode + btnModeNoLongPressed)) and (LongPressMode == HIGH)
не зовсім з тієї опери
Чому ж, в C++ and, or, not - така ж валідна форма булевих операторів, як і &&, ||, !. Сам іноді використовую таку форму.
Неактивний
Це на PB1 чи на PB2?
РВ2
Чому ж, в C++ and, or, not - така ж валідна форма булевих операторів, як і &&, ||, !. Сам іноді використовую таку форму.
Воно то так, але настоящщі ардуїнщики так майже не пишуть
Неактивний
stas_amp пише:Якщо у Вас все це проінстальвано, й налаштовано, чи можна Вас попросити, скомпілювати прошивку, для проби?
Та льогко: DigiSpark_Oiler_Moto_hex.zip
Ось тільки знайшов хвилину, щоб перевірити все.
Записав через програматор.
Спочатку на виході, на мотор, нічого не було.
Довге утримання кнопки, і все запрацювало..... Але не довго, мабуть 20 імпульсів зробило, в знову PWM, тільки ще гірше. Його відсотків 20 тільки.
От так.
З кожним постом, спробою, опускаються руки, і є бажання, просто, і без заморочок залишитися на простому блінкері, з поправкою тайменгів, і спокійно жити далі.
Якщо в учасників обговорення ще є сили, час та натхнення, то я готовий, разом з Вами, іти далі.
Якщо ні, то блінкер, і крапка.
Ще раз, всім щиро вдячний.
Неактивний
Цей глюк відтворюється навіть в нано, принаймні в протеусі (звісно що порти 0,1 змінив на інші). Проблема тут явно не в тінці і не з епром. Щось не те в Датському королівстві коді. Потрібно його або переписувати з 0 або їсти частинами поки не вилізе цей баг
Неактивний
Обідно що глюк з логічними рівнями зламався сам по собі не люблю коли баг сам приходить і сам зникає.
А врюхати в цей код реально складно. Глобальні змінні, саморобні таймери, умови дивні.. Спробувати в статичний аналізатор зарядити? Можна спробувати по черзі біля кожного digitalWrite додавати свій blink и дивитись де воно вистрелить. а надійніше переписати як state machine.
Я так розумію, що тему можна закривати. Так?
Тоді питання. Хто з учасників взявся б за написання нормального коду, з нуля?
Звісно ж, що не безкоштовно.
Пропозиції можна в приват.
Дякую всім за участь.
Неактивний