Archive for the ‘Програмування’ Category.

arm-eabi-ld buffer overflow

або помилка повертається.

Лінкер від gcc-linaro-7.2.1-2017.11-x86_64_arm-eabi (binutils 2.28), має ту ж саму біду, що й avr-ld.
А саме *** buffer overflow detected ***, переповнення буфера sprintf (і знову лаюся — чому використано не snprintf ?!)

p.s. «родич» gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf — the same, тобто те саме.
p.p.s. Arduino навіть для лінукса тягне всі компілятори з собою. Там не увімкнуто локалізацію, тому цієї проблеми нема. У старенького «рідного» в убунті-16.04 arm-none-eabi- теж. Все залежить від того, як збирався лінкер.

Scratch і двійкове дерево пошуку

З різних міркувань вирішив прослухати курс CS50 на «Прометеусі» (саме українською).
Перший тиждень там Scratch. Завдання без оцінки, просто щоб погралися, хоча деякі формальні вимоги є (не менше двох спрайтів і трьох скриптів чи щось таке — насправді дуже легкі обмеження).
Ну я й вирішив таки побавитися. Озброївся CLRS і зробив побудову та центрований обхід двійкового дерева пошуку з випадкової перестановки чисел 1–10:

Враження від Scratch » » »

Універсальний gcc-avr.mak

У зв’язку з описаною раніше помилкою avr-ld та методом боротьби з нею мене спитали про той «універсальний» файл gcc-avr.mak, яким я користуюся у всіх проектах. «Нічого воєнного», це просто файл, у який зібрано команди, які без змін переходили б з проекту в проект шляхом копіювання (і наступного редагування) Makefile від попереднього проекту 😉

Тепер файл gcc-avr.mak підключається до Makefile проекту командою include. Так само, як і подібний мейк-файл для роботи з програматором avreal — avreal.mak. Файл для проекту тепер короткий, містить лише головні налаштування. Легше знайти потрібне, важче поламати те, що вже перевірене.

Повернімося тепер до цього універсального мейк-файлу для avr-gcc і до згаданої помилки в avr-ld.

Окрім іншого, на початку gcc-avr.mak здійснюється налаштування шляхів до програм, використовуваних при компіляції. Виглядає це так (нумерація рядків відповідає файлу, доданому у прикріплений архів).

40
41
42
43
44
45
46
47
48
49
# Set default toolchain prefix if it does not defind in environment or project makefile
TOOL ?= avr-

# Set tool names
CC  := $(TOOL)gcc
AS  := $(TOOL)gcc -x assembler-with-cpp
BIN := $(TOOL)objcopy
OBJCOPY := $(TOOL)objcopy
OBJDUMP := $(TOOL)objdump
SIZE    := $(TOOL)size

Читати далі » » »

Attached Files:

Випалювач з ЧПК

Ось дивіться, яку цікавезну штуку я надибав — випалювач з числовим програмним керуванням.

Arduino Nano, трохи іншої електроніки плюс механіка; «великий» комп’ютер або OrangePi Zero. Прошивка ардуінки як ардуінівський скетч і зроблена. А ще Qt-шні програми — для OrangePi і для Linux/Windows десктопів.

Опис у блозі автора (там і посилання на GitHub):

І все це там, де найближча «Нова пошта» за 25 кілометрів. Але у автора «Випалювача» девіз — «Зробити можна все, головне мати терпіння й бажання». І у нього є і перше, і друге.

LPUART? USART1? обидва і в одну прошивку!

Є в мікроконтролерах STM32L0x така приємна штука, як LPUART. Може працювати від LSE — 32768Hz кварца коли мікроконтролер спить і піднімати його по приходу байта. Ну там ще дрібно-дробовий дільник, який дозволяє витягувати доволі високі частоти обміну від такого кварца, але то для мене вже не так важливо було. Просто є за оптроном ще один мікроконтролер, який періодично посилає інформацію про стан того, що він контролює. А на цій стороні бажано побільше спати.

У пристрої і STM32L011K вистачить, програма ледь перевалює за 8 кілобайт флеша. На нього і розраховував. Але на малих кількостях ціноутворення штука малопередбачувана, STM32L051K8 може бути суттєво дешевшим за STM32L011K4. Тому хочеться, щоб можна було поставити чи те, чи те.
Все було б добре, але «світ дуже недосконалий»© Лис з «Маленького принца». LPUART не потрапив на ніжки в 32-виводному корпусі STM32L051K. Мікроконтролери L051 мають можливість незалежної роботи від LSE є і для USART1, USART2. Але ж (ой правий Лис, ой правий!) L011 спрощений, USART2 у нього є, але він так не вміє.

Зрештою, знайшлася ніжка (PB7), де сидить LPUART_RX для L011K і USART1_RX для L051K. Все добре.

Тільки от прошивка має бути єдина, щоб той, хто прошиватиме плати, не вдивлявся у маркування мікроконтролера. Ну та до цього не звикати, все одно під одну прошивку маю реально п’ять різних варіантів виконання пристрою (на 4 різних платах). Плати візуально відрізняються відчутно, але однак простіше віддати одну прошивку. Код плати задано підключенням двох ніжок мікроконтролера на VCC/GND і ще один резистор каже «тут запаяно лише ту малу частину, яка спільна для всіх плат, це спрощений п’ятий варіант».

Вид мікроконтролера L011 («категорія 1») чи L051 («категорія 3») можна прочитати з ідентифікаційного регістра

// cat1 (L011) or cat3 (L051)
bool is_mcu_cat1()
{
    return (DBGMCU->IDCODE & 0xFFF) == 0x457;
}

і далі все просто. Відмінності ініціалізації LPUART і USART1 невеликі. Ініціалізувати і дозвіл переривань лише для одного, та ще ніжку треба увімкнути на потрібний номер альтернативної функції.

Два обробники переривань викликають одну й ту ж процедуру обробки

extern "C" void USART1_IRQHandler(void)
{
    device.octrl.byte_received(USART1->RDR);
}

extern "C" void LPUART1_IRQHandler(void)
{
    device.octrl.byte_received(LPUART1->RDR);
}

До речі, гарна штука LTO (link-time optimization). Ця byte_received() в іншому файлі, але воно чудово проінлайнило функцію в обидва обробники.

avr-ld buffer overflow

Дійсно прикра помилка в avr-ld (binutils-avr 2.25) — та, що спонукала мене до перевірки використання Raspberry Pi як комп’ютера для роботи, — виявилася доволі цікавою.

Почала вивалюватися вона у мене доволі давно, але я помилково вважав, що вона притаманна 64-бітній версії Ubuntu 16.04, бо на роботі в 32-бітній все працювало. Думав, що це якісь проблеми невраховування розмірів чи співвідношення розмірів змінних на зразок «подаруночка від FTDI». Чесно кажучи, у повідомлення не особливо і вчитувався — «та хай, це по роботі, то на роботі й зберу» і вдома більше не запускав аж до того, як нещодавно перезібрати знадобилося негайно, бо це зупиняло термінову роботу. Тоді ж ото зібрав на Raspberry й написав про все це.

Ну й на ключову фразу *** buffer overflow detected *** Іван у коментарях пояснив, як із цим можна боротися.
Докладніше читайте » » »

Raspberry Pi як комп’ютер для роботи

Не від хорошого життя довелося провести тест Raspberry Pi як робочого комп’ютера.

Не знаю, після якого оновлення Ubuntu MATE, але на моєму основному комп’ютері перестав працювати avr-ld, валиться з помилкою «*** buffer overflow detected ***» (це на 64-бітній системі, пізніше я перевірив, що на 32-бітній такій же МАТЕ і з тими ж оновленнями все працює — це не так, залежить не від розрядності, докладніше тут).
А мені терміново знадобилося внести маленьку зміну в прошивку ATtiny13A. Мій «червоненький» ноутбук зараз інтенсивно використовує дружина, то щоб їй не заважати, я згадав про Raspberry, на яку оце ж нещодавно ставив (таку ж!) убунту.

Поставив там avr-gcc, все зібрав, перекинув на основний комп, прошив.

Стало цікаво порівняти швидкість. Цей маленький (близько 400 байт прошивки) асемблерний проект на роль такого тесту геть не годиться, тому я вирішив позбирати більший. Поставив, відповідно, arm-none-eabi-gcc, щоб збирати поточний проект для STM32F105. Там десятки файлів, за 40 кілобайт результат, — час вже можна міряти. Збирав на Raspberry, на основному своєму комп’ютері (AMD A8), на «червоненькому» Dell Vostro V130 (Core i3) і на роботі на Pentium D (дохлий, як на нинішні часи, комп’ютер, але його там цілком вистачає). На всіх системах стоїть Ubuntu MATE 16.04 з усіма оновленнями. Лише на AMD A8 64-бітна, всі інші 32-бітні (і на всіх 32-бітних avr-ld свою роботу чесно робить).

Ось що вийшло (time make -j число_ядер, час у секундах).
Воно від збирання до збирання трохи стрибало, але не принципово.

система
(ядер*ГГц)
real user system
Raspberry Pi 3
(4*1.2)
12.2 32.6 3.3
Pentium D E2160
(2*1,8)
9.5 13.3 1.8
Core i3 M380
(4*1,33)
8.2 20.6 2.7
AMD A8-7600
(4*3.1)
3.1 7.7 1.2

Тут у табличці нема ширини і швидкості шини пам’яті, своє слово сказало і те, що Raspberry працює з SD-карти, Pentium-D і AMD A8 з SATA-дисків, а Core-i3 з SSD. Але тут я хочу порівняти все ж таки не кількість зкомпільованих рядків коду на гігагерц-ядро чи DDR-истість пам’яті, а абсолютний час — питання, що турбує: «чи йти заварювати чай, чи воно раніше збере» 🙂

Виявилося, що Pi 3, на відміну від перших Raspberry, цілком придатний для роботи з прошивками такого обсягу.
І що ця плата реально набагато швидша, ніж комп’ютер, на якому років 15 тому я запускав альтерівський Quartus-II 9.1 для збирання прошивок альтер (не можу пригадати, що у мене тоді було… якийсь Athlon-550 чи що). Та й «мікроконтролерні» компіляції там більше часу займали.

Оболонка Arduino українською

Потихеньку завершив переклад оболонки Ардуіно українською мовою. Станом на кінець літа там близько третини (із майже шестисот) рядків у .po-файлі було ще не перекладено. Дещо було перекладене, але не потрапляло в оболонку жодною мовою, довелося шукати проблемне місце, виправляти і робити pull-request.

Дещо з перекладеного раніше також довелося виправити. Напевне ж, ще треба виправляти, як старе, так і зроблене мною. Хоча б тому, що в англійській мові нема відмінків, а я сам не пройшов всю оболонку, не викликав усі можливі повідомлення і не знаю контексту, у якому вони виникають. У дуже підозрілих місцях я просто по java-коду оболонки здогадувався про цей контекст.
От цікаво, де виникає повідомлення «Як сюрреалістично!» (в оригіналі «How very Borges of you»), але в код не ліз, такий квест треба проходити чесно 😉

Зараз з сайту Arduino можна завантажити Arduino IDE «стабільної» версії 1.8.5 від кінця вересня, туди частина перекладу вже увійшла.
У чергову preview-версію 1.8.6 від 30 жовтня (нижче, розділ HOURLY BUILDS) ще не потрапили дві фрази (див. issue), тепер вони є в перекладі. В релізі (чи наступному пре-релізі) 1.8.6 мають бути.

Будь-ласка, хто використовує Arduino, беріть найсвіжішу збірку (зараз ота 30 October 2017) звертайте увагу на меню і всі повідомлення, які трапляються у реальній роботі. Як щось криве побачите — пишіть. Хочу підчистити до релізу. Ну і потім продовжувати підтримувати стан.

Зовнішні відносно Arduino плагіни для роботи з платами/бібліотеками, навіть якщо вони прямо із сайту завантажуються разом з оболонкою, не мають можливості перекладу. Але пишіть про все, а я вже розбиратимуся — то щось нове додали і треба перекласти, чи воно не вміє бути перекладеним.

До речі, довідка в Arduino IDE, на відміну від власне оболонки, існує лише англійською. Так і не зрозумів, чи збираються додавати перемикання. Пізніше питатиму, зараз інша в чомусь близька робота час забрала.

OpenOCD, STM32L011 і всі-всі-всі

Тему так і не закінчено. Доводиться тримати на столі обидва адаптери — і саморобний на FT2232H, і китайський ST-Link.

Мікроконтролери STM32L011, на відміну від інших STM32L0, мають одну особливість. Якщо флеш стерта (точніше, якщо стерте перше слово флеша, у якому початкова адреса стеку сидить), то незалежно від ніжки BOOT0 мікроконтролер стартує у boot-loader. Зроблено це з метою «полегшити початкове прошивання», але мені лише поважчало.

Біди не було б, якби OpenOCD у комбінації з адаптером на FT2232 з цією ситуацією міг упоратися. Але він чомусь не може прошити флеш. Під’єднується по SWD до ядра, показує вміст вказівника команд десь у діапазоні системної пам’яті, каже, який мікроконтролер побачив і обсяг флеш-пам’яті, а от шити відмовляється. Цей же OpenOCD з адаптерами ST-Link, що з «чесним» з плати STM32F3DISCOVERY, що з китайським, — перешиває.

Іноді потрібно стерти геть усе, через що влетіти у бут-лоадер, а плату DISCOVERY, у якої є reset, використовувати як програматор мені трохи незручно.
От тому лежать на столі два адаптери.

p.s. Про всяк випадок повторю: якщо не зупиняти основний генератор (не піднімати біт SLEEPDEEP у регістрі SCB->SCR) і не перепрограмовувати ніжки, потрібні для SWDIO/SWDCLK, то цілком можна обійтися китайським ST-Link-ом. Інакше — доведеться шукати/робити інший програматор або додавати кнопку reset і вчитися її відпускати у потрібний момент 🙂

Китайський ST-Link v2 проти STM32F3-Discovery

Щоб вже закінчити вчорашню тему.

Витягнув із шухлядки плату STM32F3-Diіcovery — на ній є вбудований ST-Link, який можна відключити від процесора на платі і використовувати для програмування інших плат. На штирі виведено всі сигнали, включно з RESET і SWO. До речі, перемички розривають лише лінії SWCLK і SWDIO, тому свою плату можна скидати, натиснувши кнопку на платі Discovery.

Ну що — все працює, RESET піднімає мікроконтролер зі Stop-у і перепрошиває. Тобто проблема в тому, що клон ST-Link з Ali-Express-у не вміє виконувати відповідні команди.

Коли вже знову сів за макетку з STM32L051, то перевірив і роботу команд stm32lx lock / stm32lx unlock і швидкість програмування. У клонованого ST-Link тут теж щось в генотипі порушене, бо набагато повільніший. Хоча в ньому стоїть STM32F101, тобто USB зроблене програмно, тому швидким він і не може бути, але ж одиниці кілобайт на секунду не така вже й велика швидкість.

Результати тестування на швидкість (файли для прошивки 2-12kB).
Команда “reset init” перемикає STM32L0x з внутрішнього MSI 2 MHz на HSI 16 MHz і піднімає частоту обміну.

Програматор Fswclk = 300 kHz
(-c “reset halt”)
Fswclk = 2.5 MHz
(-c “reset init”)
Клон ST-Link 1.5-1.7 KiB/s 1.5-1.7 KiB/s
F3-Discovery 4.9-5.0 KiB/s 5.2-5.3 KiB/s
FT2232H 3.8-4.2 KiB/s 8.0-8.3 KiB/s

Платку з FT2232D діставати було ліньки, на цих швидкостях має бути не набагато повільніша за FT2232H, хіба ото не зможе виставити 2.5 MHz частоти SWCLK, буде 2.

[flagcounter image]