ReAl

Колись я вже жалівся, що китайський клон ST-Link v2 не має виходу RESET для STM32.

Дещо пізніше від автора цього чудового перехідника між клоном ST-Link, стандартним 20-контактним з’єднувачем JTAG, однорядними штирями STM32FxDiscovery і платкою BluePill (+ ще щось, що мене наразі не цікавить), я дізнався, що клон ST-Link можна підправити.

Потрібні сигнали проcто не виведені на штирі. Якщо підтримка STM8 непотрібна, можна штирі SWIM і RESET (STM8) відрізати від сигналів, а туди вивести SWO і RESET (STM32). На сторінці проекту написано, які виводи мікроконтролера слід під’єднати до штирів.

Після ознайомлення я навіть знаходив якийсь допис з рекомендаціями-фотографіями по такому виправленню. Після відрізання доріжок від штирів RESET і SWO автор на їхні кінчики напаяв 22-омні резистори, а вже до них припаяв дротики.

Коли я зрештою сів паяти, я помітив, що можна все зробити простіше. На нижній стороні плати зняти резистори R7 і R8, які приєднують до штирів виходи, перерізати доріжки, що йдуть до ближніх до резисторної збірки кінців цих резисторів (червоні позначки на фото), а тоді припаяти дротики до контактних майданчиків цих резисторів. На штирі сигнали потраплять через резистори зі збірки.

Ми це зробили. «Вступ до алгоритмів» Кормена та компанії, відомий як CLRS, вийшов друком українською мовою.

Перекласти ці 1200 сторінок, вичитати, висперечатися щодо формулювань — вечорами та на вихідних — було непросто і робилося це довго.
Але книжку вже надрукували.
Докладніше на сторінці у Facebook facebook.com/clrs.uk

Може вже всі це знають, але для мене було новиною.

Маючи посилання на diff-сторінку на github-і, можна легко отримати format-patch цих змін.
Досить лише додати .patch в кінці посилання.

Наприклад, така сторінка перегляду змін
https://github.com/ivkos/hostap-force-ht40/commit/004876e562b310d85ffab0f1d671b7a51ff0ce51
І отак отримуємо format-patch
https://github.com/ivkos/hostap-force-ht40/commit/004876e562b310d85ffab0f1d671b7a51ff0ce51.patch

p.s. Вже не можу знову знайти сторінку, де про це прочитав, тому без посилання.

Щось останнім часом я практично лише про помилки і пишу. Але тут поруч з поганою новиною є і хороша.

Ще десь перед новим роком виявив біду — у найсвіжішому на той час OpenOCD команда stm32f1x unlock захист зчитування наче знімає, але по тому записати у мікроконтролер нічого не вдається.

На щастя, у мене десь лежала перевірена версія, зібрав її, встановив і все пішло. Вже десь у січні підключився до OpenOCD через telnet, потикався різними командами і з’ясував, що в усі option bytes (окрім readout protection) записані випадкові значення, тобто на довільні сектори flash-пам’яті було встановлено захист від запису, а також попсовано опції SW/HW WDT і інші.

І оце лише на минулому тижні розібрався. Драйвер stm32f1x використовується для роботи з stm32f10x, stm32f0xx, stm32f3xx, але біда лише з stm32f10x. З’ясувалося, що в них захист від зчитування поширюється і на область флеш-пам’яті для блоку опцій. Для двох інших згаданих лінійок цього нема, у документації в табличках окремо відзначено можливість такого зчитування (при захисті з рівнем L1). Можливо, саме тому в коді зчитування опцій з регістрів FLASH_OBR і FLASH_WRPR замінили зчитуванням безпосередньо з адрес 0x1ffff800..0x1ffff80f.

Процедура unlock перед стиранням опцій зчитує їхні значення, щоб під час запису коду дозволу зчитування відновити те, що було. Але ж доступу нема, OpenOCD доповідав, що прочитати не може і йшов далі. Тобто записував випадкові значення, які на той час були у неініціалізованій структурі.

Відповідно, ремонт простий — повернутися до зчитування з регістрів. Зараз патч лежить на узгодженні в їхньому gerrit-і, а я вже користуюся виправленим 🙂

Міняв диск, заразом поміняв і Убунту 16.04 на 18.10. Як і минулого разу на шістнадцятій, поставив «рідний» для системи пакет arm-none-eabi-. Мабуть, пора закінчувати з такою практикою, всістися на якусь іншу збірку компілятора, ту ж linaro. Бо проекти перестали збиратися. І на чому, на рівному місці! Компілятор не знаходить файл cstdint.

Короткий пошук показав, що версія компілятора 6.3.1, include-файли лежать в /usr/lib/gcc/arm-none-eabi/6.3.1/include та в /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/include, який, зрештою, вказує на /usr/include/newlib.

А от заголовочні файли C++ лежать в /usr/include/newlib/с++/7.3.1. Звідки взялася сімка — важко сказати. Може це одрук, може дійсно поклали іншу версію, але жодного файлу від C++ cpp не знаходить. Назву 7.3.1 вирішив не чіпати, просто поруч додав лінк 6.3.1->7.3.1. Після цього cpp по -v показав додаткові шляхи до файлів і все стало збиратися.

Зазвичай я не поспішаю переповзати на нову версію Ubuntu і досі сиджу в Ubuntu Mate 16.04. І я не один такий, на роботі також 16.04 (тільки не Mate, а «звичайна», зі стільницею Unity).
І от на роботі ж і виловив помилку в Doxygen, який в убунті 16.04 стоїть версії 1.8.11. Заманулося отримати для перегляду дерева викликів, CALL_GRAPH і CALLER_GRAPH, щоб швидше ознайомитися зі структурою чужого коду. А отримав страшну кашу з довгими циклічними петлями викликів. Виявилося, що всі функції, прототипи яких описано в .h-файлі безпосередньо під inline-функцією, вважаються такими, що викликані з цієї inline-функції.
Мінімальний приклад, doxy-bug.{h,c}:

Doxygen 1.8.11 генерує для inline-функції foo() такий граф викликів

а для moo() взагалі отакий:

Уявляєте, що я отримав на дереві з кількох каталогів і сотень функцій, а в h-файлах під inline-функцією може бути описано декілька прототипів, всі з яких стають «викликаними» з неї? Оскільки всі ці функції викликали ще у глибину на декілька рівнів статичні функції всередині своїх файлів, а вже ті викликали ці inline-операції, утворювалося багато довгих петель.

На щастя, у свіжій версії Doxygen 1.8.15 цю помилку виправлено. Все красиво:

Переставлю тепер doxygen і на роботі, буде легше.

Сьогодні над CLRS сиділося під Creedence Clearwater Revival.
Але ж у голові паралельно й інше крутиться, то вийшло:

Oh Working Queue, oh Waiting Queue
And IRQ, how I love you, all IRQ
I like the way you walk
I like the way you talk
I like all your spinlocks
 but hate if you deadlock, All Linux *Q*

Well, say that you’ll be hard
Well, say that you’ll be soft
Well, say that you’ll work fine
 and never give me pain, oh IRQ

Well, say that you’ll be mine
Well, say that you’ll be mine,
Well, say that you’ll works fine,
 works all the time, my Working Queue

Oh Working Queue, oh Waiting Queue
And IRQ, how I love you, all IRQ

I like the fast top half
I like the bottom half
I like the user space
I like the user space, oh Working Queue

Oh Working Queue, oh Waiting Queue
And IRQ, how I love you, all IRQ

© моє

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

Лінкер від 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- теж. Все залежить від того, як збирався лінкер.

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

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

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

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

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

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

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