. .. ..o .oO .oO failed
Виявляється, на концерті академічного духового оркестру на початку та в кінці виступу диригент ручкається з першим… кларнетом.
Ні, я розумію, що в духовому оркестрі першої скрипки немає, але якось не задумувався над тим, «хто за неї».
p.s. А колонний зал імені Лисенка — таки не найкраще місце для виступу духового оркестру. Звуку було надто тісно 
Інформація, яку видає OpenOCD при звичайному завантаженні програми у flash-пам’ять мікроконтролера, деколи може допомогти так, як наче це був запущений зневаджувач.
Переписую на свій смак шматки, які вже працювали зі стандартною бібліотекою від NXP. При чергових змінах програми вона начисто перестає працювати. Знаходжу дрібну помилку (замість змінної часу повертається константа періоду), виправляю, перешиваю…
Знову висить.
І тут помічаю, що OpenOCD сповістив мене про те, що ядро перед програмуванням знаходилося не в стані Thread, тобто виконання програми, а в стані обробки преривання:
Але ж обробка SysTick складається у мене зараз зі скидання флагу та інкременту змінної, кілька тактів при тактовій 100 МГц. Потрапити на неї — дуже низька імовірність.
Ще раз запускаю програматор і знову отримую «Handler SysTick», що вже зовсім неймовірно за нормальних умов.
О, точно!
Так я ж забув дописати extern "C" перед обробником преривання SysTick_Handler(), коли перетягував цей шматок з С-шного файлу у C++-овий. А запускалка startup.c очікує імена без декору C++.
Відразу написав файл lpc17xx_handlers.h, простіше буде включати його в усі файли з обробниками преривань і не думати, треба ставити extern "C" чи ні.
Хоча може краще було б зробити так:
І писати CM3_HANDLER перед кожним обробником преривання, аналогічно OS_INTERRUPT в програмах з scmRTOS.
Я ще подумаю 
lpc17xx_handlerslpc17xx handler prototypes for C/C++ programs (with extern "C" for C++)
Продовжую набігами знайомитися з мікроконтролерами LPC17xx.
При цьому продовжую лізти на кактус: «щоби швидше», підключаю файли зі стандартної периферійної бібліотеки від NXP. І в черговий раз отримую помилку компіляції. На цей раз — з глибин <sys/reent.h>, який включається до <stdio.h>, якого, своєю чергою, потягнув debug_frmwrk.c з LPC1700 Peripheral Driver Library:
Причому що в збірці від Klen, що в CodeSourcery — те саме (the same, як сказали б англомовні). Тільки номери рядків відрізняються та CodeSourcery, на відміну від Klen-ового пакету, зібрано без підтримки локалізацій і він каже #if with no expression а не #if без виразу.
Лізу дивитися sys/reent.h
468 469 470 471 472 473 474 | /* Only built the assert() calls if we are built with debugging. */ #if DEBUG #include <assert.h> #define __reent_assert(x) assert(x) #else #define __reent_assert(x) ((void)0) #endif |
Рядок як рядок. Звичайний такий рядок для C-шного препроцесора…
Єдиний спосіб примусити компілятор видати оте «#if без виразу» — це визначити десь слово DEBUG як порожній рядок.
Причому це має бути десь в моєму проекті. В моєму… grep -r DEBUG * …
Знайшлося. Все там же — у периферійній бібліотеці від NXP. У файлах lpc17xx_libcfg_default.h та lpc17xx_libcfg_default.с. Якраз в такому вигляді:
44 45 46 47 48 | /************************** DEBUG MODE DEFINITIONS *********************************/ /* Un-comment the line below to compile the library in DEBUG mode, this will expanse the "CHECK_PARAM" macro in the FW library code */ #define DEBUG |
Зробив в цих двох файлах від NXP заміну на LPC_DEBUG і справа пішла.
p.s. Автори бібліотеки NXP в даному випадку не дуже і винні — в стандартах C та C++ згадується лише макрос NDEBUG (використовуєтсья в assert.h). Тому наче і нема обмежень на використання ідентифікатора DEBUG в своїх програмах…
Boot-loader в мікроконтролерах LPC17xx очікує 32-бітну контрольну суму перших семи слів прошивки (вміст вказівника стеку, та перших шести векторів) на місці не використовуваного вектора по адресі 0x1C. В це слово записується мінус-сума перших семи слів. Схожим чином перевіряє наявність програми і бутлоадер LPC2000.
OpenOCD вміє «на льоту» генерувати таку контрольну суму при програмуванні мікроконтролера, потрібно лишень в команді flash вказати аргумент calc_checksum (ця команда є у файлі target/lpc17xx.cfg пакету).
Але чомусь він не генерує її для звірки вмісту (верифікації). Причому сам він знає, що мені буде незручно, раніше навіть писав щось таке:
Тобто якщо йому дати для верифікації той же файл, що йому було дано для прошивки, то він видасть помилку в тих чотирьох байтах. Ось нещодавно я в черговий раз підятягнув з репозиторію оновлення, зібрав та встановив свіжісіньку версію, однак маю:
»»» Подивитися повідомлення про помилку верифікації та боротьбу з нею
Знадобилося поекспериментувати з avreal-ом та atmega64 на різних тактових частотах під різними операційними системами. Бо таки ж щось незрозуміле робиться у Win7/64. Але в тих платах, що під рукою, запаяні ATmega64L-8. Вище, ніж на 8 мегагерцах їх і некоректно перевіряти.
Знайшлася плата з ATmega64-16, але без кварца. Тобто навіть без місця під кварц, бо в тому виробі планувалася робота на внутрішньому RC з калібруванням по годинниковому кварцові. А плата завалялася того, що в неї помилково запаяли «-16», хоча там теж мала бути «L-8».
Шматочки цангових панельок я для заміни кварцових резонаторів на експериментальних платах використовую давно, але тут же і місця нема. Клеїти десь збоку не хотілося. Довелося викручуватися.
Поблизу потрібної сторони мікроконтролера знайшовся «земляний» перехідний отвір, його і вирішив використати для кріплення панельки.
У шматочка на три виводи центральний залишив прямим, а два крайні, що для кварца, відігнув. Прямо на виводи напаяв конденсатори 18 пФ. Конденсатори розмістилися так, що не торкаються поверхні, в яку упиратимуться зігнуті виводи:
В огляді змін в мікроконтролерах AVR при переході на нову технологію (стаття “A” and “not-A” AVRs) часто зустрічаються слова «Помінялися рівні POR».
Зміну рівнів Power-On Reset зумовлено переходом на «advanced POR circuit», що на рівні конструктора систем на мікроконтролерах означає:
Раніше (для «не-А» мікроконтролерів) перші два пункти не було вказано взагалі і залишалося лише здогадуватися, до якої межі можна без ризику наближатися.
Останній пункт розглянемо докладніше.
Наприклад, при переході від ATtiny13 до ATtiny13A (AVR520, Table 2-4. Power-On Reset) типове значення рівня POR при наростанні напруги збільшилося від 1,2 В до 1,4 В. Обидва значення менші за специфіковану для версії ATtiny13V мінімальну напругу живлення 1,8 В, тому в проектах, зроблених без порушення специфікацій виробника, перехід на нові типи не викличе проблем. Можливо, вони навіть краще працюватимуть, бо зменшиться різниця між напругою, при якій POR «відпускає» схеми мікроконтролера та фіксує значення FUSES, та мінімальною напругою гарантованої роботи.
Але в проектах «для себе» в часто виправданому в таких випадках стилі «ці конкретні екземпляри запрацювали — і добре» можуть виникнути проблеми.
Знову гриб на дереві.
Трутовик сірчано-жовтий на тополі.
Десь напівдорозі від спорткомплексу КПІ до Караваєвих Дач.
По недавніх дощах добре вродило 
Але біля самісінького стовбура вже жорсткуваті.
Ех… Треба їхати «на село». Однак в таку спеку роботу робити неохота…
Досить часто виникає потреба додати двійкові дані до «прошивки» мікроконтролера. Це може бути знакогенератор для графічного дисплея чи принтера, закодована певним чином музика чи якась інша інформація, отримана у «двійковому» (тобто не-текстовому) вигляді від якоїсь «сторонньої» відносно компілятора для мікроконтролера програми.
У моєму випадку це теж прошивка, але для програмованої логіки (FPGA). Цю прошивку можна отримати у вигляді файлу .ttf (tabular text file, а не true type font ), у якому знаходяться десяткові числа, розділені комами.
Колись давно, ще «десь між i87c51FA та AT89C55» я з такого файлу для EPF8282 генерував asm-файл. Програмою sed додавав до та після масиву чисел потрібні заголовки з мітками, на початку кожного рядка директиву .DB і тому подібне. Асемблерний файл згодом компілювався в об’єктний та прилінковувався до програми.
Для ATmega162 та EP1K10 користувався власноруч написаною програмою — основна її робота була стиснути прошивку для альтерини простим, але ефективним алгоритмом, а вже видати назовні C-масив то була проста робота.
Тепер у мене LPC1766 та EP1C3. Циклони вже мають в собі декомпресор і квартус може стискати прошивки. Він це робить гірше, ніж алгоритм від Ivan Mak, але він це робить сам і розпаковує теж без мене. Тому я, принаймні зараз, повертаюся до простого перетворення стороннього файлу прошивки в об’єктний файл з масивом.
Зараз для таких робіт зазвичай пропонують вже готові програми на зразок bin2c для генерації C-шного масиву. До речі, на мою думку, однією з найкращих програм на тему все2всюди є пакет srecord.
Але при роботі з компіляторами gcc (точніше, з набором програм GNU binutils, яким користується і gcc) можна обійтися без додаткових програм, »»» прочитати — яким саме штатним інструментом з пакету та як…
Нещодавно я писав про сім полків лелек. Цей раз ми проїхали повільніше і я роздивився їх уважніше. Зупинялися зробити фото.
В одному місці основа для гнізда піднята над стовпом:
Вийшла нова версія програматора avreal – v1.28r11 (Sat 2012-06-23).
українська
русский
english