STM32F4 і HAL


23

Тому я деякий час експериментував із STM32F407 (я новачок в ARM) і вирішив написати простий додаток, використовуючи бібліотеки HAL, оскільки, здається, ST припинив використання стандартних периферійних бібліотек. Отже, моє запитання полягає в тому, який сенс у HAL? Хіба StdPeriph не робив свою роботу? Чому б вони відмовились від HAL? Мені це здається, що HAL - це повний безлад.

Документація AWFUL, принаймні для StdPeriph є повна довідка, організована досить добре, щоб легко знайти те, що ви хочете ( http://stm32.kosyak.info/doc/ ). Для HAL існує шалений PDF ( http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00105879.pdf ), який має, здавалося б, випадкову структуру. Читаючи будь-який розділ, наприклад, щодо периферійного пристрою, я, здається, не розумію вимог, щоб його налаштувати та налаштувати належним чином. Це більше схоже на особисті нотатки того, хто не хоче забувати речі, ніж на довідку.

Я знаю, що можу використовувати CubeMX для ініціалізації GPIO та налаштування периферійних пристроїв, але моя мета - зробити це самостійно, щоб я краще розумів їхню роботу, не маючи програмного забезпечення для мене це все. Я щось роблю не так? Невже мене бентежить новачок ARM в мені? Або наявна документація ЩО погана?


Чи краще вам підійде щось на зразок ChibiOS? У них є RTOS, але також дуже хороший HAL, який ви можете використовувати без RTOS.
IgorEE

ST точно не припинив використання стандартних периферійних бібліотек, але вони не будуть випускати нові його версії для нових сімей. Вони заявили (десь на своєму форумі, але, здається, не знаю), що вони продовжуватимуть підтримувати SPL для сімей, для яких воно було випущене (включаючи STM32F4). Оскільки ви новачок у ARM, можливо, найкраще працювати з HAL. У мене дуже багато модулів вже написано за допомогою SPL, тому перехід буде болем, і я відкладаю це. Це погано, оскільки як тільки я вирішу використовувати нову сім'ю, буде більше коду для порту до HAL
Tut

Ця електронна книга: leanpub.com/mastering-stm32 є хорошим вступом для новачків (але також і для професіоналів) у світ STM32.
Лоренцо Мелато

Відповіді:


13

Створити власні бібліотеки досить просто. Їх документація специфікацій реєстру досить хороша, більшість, якщо не всі периферійні пристрої легко налаштувати. Мені набагато болючіше користуватися їх бібліотеками. але, мабуть, це тільки я. Це справедливо для st, nxp, ti, atmel, щоб назвати декілька (не стільки для Intel, і мікрочіпа).

Чому вони змінюють бібліотеки, це може бути з будь-якої кількості причин, якийсь новий начальник перейшов на посаду, якийсь відділ закрили, інший взяв на себе. Маркетинг хотів новий імідж продукту. Як зазначалося ElectronS, це може бути спробою відмовитися від апаратних засобів більше, щоб залучити користувачів, які не бажають чи не вміють робити голий метал. Я б пішов далі про це і сказав, що вони, ймовірно, намагаються конкурувати з явищем Ардуїно. Який mbed і всі інші завжди намагалися зробити і провалилися (ще до Ардуїно).

У будь-якому випадку, чим далі від апаратури він стає більш роздутим і повільнішим, тому більше вам доведеться витрачати на одиницю для рому, таран і мГц. Просто, щоб ви могли витратити стільки ж часу на програмування? Просто робити це по-іншому?

Ви кажете, що ви родом із світу PIC, тепер вони зробили гарну роботу з інструментами, хоча їхні чіп-документи були жахливими, хоча і найгіршими. вони компенсували бібліотеками та пісочницями.

Наприкінці дня спробуйте різні варіанти, спробуйте конкурентоспроможні продукти, щоб побачити, як їх інструменти порівнюють. Багато чого можна зробити безкоштовно, лише щоб побачити, чи є сенс і чи можна складати речі. Можливо, навіть використовувати тренажер набору інструкцій. Знайдіть той, який відповідає вам.

Зверніть увагу, що параметр без збережених бібліотек ЗАВЖДИ доступний для вас. Ви не обмежуєтесь тим, якою ланцюжком інструментів ви можете користуватися, якою операційною системою хосту, яким ідеєм, редактором і т. Д. Вони можуть дотримуватися вас при програмуванні деталей, якщо їхні можливості вкрай обмежені в цьому відношенні переходять на якусь іншу мікросхему або продавця, якщо можете.

Щоб продати такий чіп-продукт, вони повинні забезпечити середовище розробки, будь то їхнє чи безкоштовне, яке вони склеюють. І вони, як правило, збирають якусь бібліотеку. Він повинен виглядати достатньо добре, і моргнути приведений приклад працює достатньо добре, щоб або ваше керівництво, або ваша апаратна команда розробляли дизайн свого продукту, тоді коли ваш продукт на борту перекидається через стіну на програмне забезпечення, це коли біль прибуває чи не прибуває. Якщо це майже працює, але не зовсім, це великий виграш для постачальника чіпів, оскільки тепер ви заплатите за технічну підтримку за цей останній дрібницю. Тож їм в інтересах бути майже там, але не зовсім.

Постачальники чіпів повинні виглядати достатньо добре, щоб отримати дизайн. Вони повинні постійно вдосконалювати (змінювати) товар, щоб залучити нових та старих клієнтів. Таким чином, у них доведеться робити надмірні зміни, наскільки відстань і скільки попередніх бібліотек продовжують підтримувати, змінюється. Тож майже будь-яка бібліотека, до якої ти звик, з часом піде. Тому навчіться адаптуватися (або не використовуйте їхні речі та йдіть самостійно, які ви можете підтримувати нескінченно). Зрозуміло, в ідеалі вам потрібно розробити додаток лише один раз на продукт, зробити свою прошивку ідеальною (удача, якщо ви користуєтеся сторонніми бібліотеками), і вам не потрібно повернутися назад і знайти комп’ютер, який буде завантажувати їхню ланцюжок інструментів, якщо ви зможете знайти його копію та пам'ятайте, як користуватися цією старою бібліотекою. Пам’ятайте не тільки про збереження вихідного коду, але й про всі їх інструменти та документи.

Їх бібліотеки підтримуються лише на одній ланцюжку інструментів, під одним, можливо, двома IDE, а іноді лише в Windows та певних версіях. Знову ж таки, у вас немає жодних з цих обмежень, і, звичайно, не для ARM, якщо ви робите свою справу. Ви завжди можете прочитати будь-яку / всі їх бібліотеки, щоб побачити, як вони роблять справи. Але це часто дуже страшно, вони не використовують своїх розробників команди A для бібліотек, я вилучив декілька рядків коду, щоб запитати кандидатів на співбесіду, що з цим кодом не так.

щоб заощадити час і зусилля як на стороні кремнію, так і на стороні програмного забезпечення, вони дуже часто переробляють один і той же ip, тож коли ви бачите, як периферія працює на одній з своїх мікросхем, вона часто працює однаково на багатьох інших їхніх чіпах. Так, годинникові системи можуть бути складними з бібліотеками або без них. Висока ймовірність затримати чіп, саме там трапляється більшість моїх чіпів / дощок. Допомагає зрозуміти, як працюють їхні чіпи, наприклад, AVR, більшість, якщо не всі, можна перепрограмувати під час скидання чіпа, тому будь-який поганий код, який переплутує штифти, необхідні для перепрограмування, або висить логіку, необхідну для перепрограмування, не Має значення, ви можете перепрограмувати ці фішки. Деякі з цих постачальників (st - це один) мають внутрішній завантажувач, який ви можете вибрати за допомогою ремінця (наприклад, BOOT0 у світі),

Один розмір підходить всім підходить нікому добре. Особливо це стосується програмного забезпечення. Таким чином, будь-яка спроба абстрагувати обладнання, просто робить його повільним і роздутим. Ви також можете отримати більший чіп і запустити на ньому Linux, якщо ви це справді хочете. Багато цього відбувається в результаті розробників, хоча вони не хочуть забруднити руки, тому ми в основному просили цього, і вони намагаються його поставити.

Знову ж таки, не замикайтесь на новому або будь-якому постачальнику (якщо тільки не пізно, і менеджмент і, або команда апаратури приклеїли його до вас, зауважте, що продукти stm32 приємні та прості у використанні). Магазин навколо. TI кладе багато яєць у кошик cortex-m4. Ви можете зробити mbed річ на багатьох цих продуктах, а також на рішеннях, що підтримуються постачальником.

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


Чудовий аргумент щодо розробки власних бібліотек, майже переконаний, і я хотів би спробувати це, що, на вашу думку, мені знадобиться інше, ніж посібник із stm32fxx? Чи повинен я також прочитати посібник з основних кронштейнів? я буду використовувати CMSIS? як я отримаю доступ до регістрів та пам'яті? Ви можете детальніше розглянути або надати приклад того, як розпочати роботу
ElectronS

ще кілька речей, про які варто подумати. кожен рядок коду додає ризик. пояснивши своєму начальникові, що ви плануєте використовувати десятки до сотень тисяч рядків коду інших людей, не переглядаючи кожен фрагмент, який ви використовуєте. шари коду, особливо при абстрагуванні, призводять до того, що двійкові файли збільшуються, а продуктивність падає. Тож ще раз пояснивши вашому начальникові, що 10 мільйонів одиниць продукції коштуватимуть додаткових 35 центнетів за 3,5 мільйона доларів, тому що ви вирішили скористатися бібліотекою, ви викликаєте лінивість.
old_timer

ваш начальник може найняти армію людей, щоб замінити вас на такі гроші, перегляньте кожен рядок коду, щоб вони не отримали 10 000 одиниць і виявили, що їм доведеться їх виправити через помилку програмного забезпечення, викликану використанням ризикованого програмного забезпечення. а також використовувати меншу частину, яка менше коштує при меншій тактовій частоті, яка споживає менше енергії та працює довше на одному заряді акумулятора. іноді варто докласти зусиль. і точно, іноді ні.
old_timer

дякую за більше пунктів, які ви сказали, але чи могли б ви відповісти на моє запитання, як краще почати? використовуючи файли CMSIS і HAL .h для імен реєстру та місць пам'яті ??
ElectronS

Немає "найкращого", використання цього слова робить його особисту думку, а не факт. Просто виберіть один і почніть, або зробіть так, як я міг би, спробуйте один, поки ви не потрапите на дорожній блок, потім спробуйте інший та інший, і обходьте штовхаючи кожен блок дорожнього руху назад до наступного дорожнього блоку, поки один чи всі не прорвуться.
old_timer

14

Дозвольте сказати, що багато хто з нас розділяє те саме розчарування, яке ви маєте в бібліотеках HAL, вони справді погано і розпливчасто задокументовані, і все ж нові містять багато помилок.

Тож відповісти на ваше запитання, чому ST вирішив на HAL просто:

  1. Вони хочуть створити апаратний рівень абстракції, який простою англійською мовою означає, що вони хочуть, щоб розробка та код програмного забезпечення був незалежним від мікроконтролера, тому якщо сьогодні ви пишете код для stm32f4 і вам потрібно через пару років перейти на stm32f7 це буде легко, і код буде дуже модульним.

  2. Це також дозволяє більшій кількості розробників, як програміст програмного забезпечення, працювати з мікроконтролером, не розуміючи і не вникаючи в глибокі деталі того, як апаратне забезпечення вирішує завдання. Такі компанії, як ST і TI (починаючи цю дорогу зараз) намагаються зробити вбудовану розробку подібною до розробки коду ПК, де ви використовуєте драйвери високого рівня для розробки коду FAST. Незграбність та відсутність оптимізації в їх драйверах та бібліотеках компенсується високою продуктивністю пристроїв ARM.

  3. Я думаю, що STM32cubeMX - це чудовий інструмент, якщо ви використовуєте бібліотеки HAL, тому що найбільш трудомістка робота - це ініціалізація периферійних пристроїв, і тепер ви можете це зробити за дуже короткий час, з візуальним інтерфейсом, який можна легко змінити, не впливаючи на код користувача (якщо ви пишете свій код у відповідному місці) Ви можете використовувати Stm32cubeMx, а потім переглянути код і спробувати зрозуміти, як і чому вони використовують кожну функцію, таким чином ви намагаєтеся вирішити вправу і поруч із посібником з рішення для виправлення, яке є чудовий ІМО.

  4. Ядро ARM є тихим складним, тому старі методи, які ми використовували на 8-бітовому мікроконтролері, як безпосередньо обробка реєстрів (написання С у монтажному режимі), нездійсненно, це забирає багато часу і робить код важким для підтримки завдяки складній архітектурі (перевірте Налаштування годинника, наприклад)


6
Це все дуже зрозуміло, проте все це стосується і StdPeriph, чи не так? Я маю на увазі, це вже є апаратною бібліотекою абстракцій, тож який сенс у створенні нової замість покращення старої? Мені справді цікаво, я дуже новачок у ARM, я використовую PIC багато років.
Джон

Тим більше для бібліотек, сумісних із CMSIS
Скотт Сейдман

1
@john, наскільки я розумію, HAL більш обмежений і менш апаратний, ніж стандартні бібліотеки.
ElectronS

12

Я знаю, що це буде довго і впевнено, але оскільки ми щойно (успішно) випустили наш новий продукт за допомогою HAL, я думаю, що це варто розглянути. Крім того, я не працюю на ST, я ненавидів кожен шматочок HAL, майже перезапустив проект зі StdPeriph, я відчув біль - але тепер я розумію, чому.

По-перше, трохи тла. Ми розробляємо системи телеметрії наднизької потужності, і наш продукт працює від STM32L1. Коли ми почали працювати над прошивкою, у нас був звичний вибір (голий метал) пристроїв ST: робити все вручну, користуватися бібліотеками StdPeriph або йти з HAL. Хлопці ST переконали нас піти з HAL - так ми і зробили. Це було боляче, нам довелося обійти помилки в програмному забезпеченні (частина I2C зводила нас з розуму протягом досить тривалого часу), і мені все ще не подобається загальна архітектура. Але це працює.

Коли я перейшов з робочого столу на вбудований, трохи більше року тому, мене приголомшило щось дивне, що я не міг назвати або навіть зрозуміти. З часом я зміг зрозуміти, що відбувається, а точніше, що відбувається: вбудований світ перебуває в перехідному періоді. Кремній щодня дешевшає, а MCU - більш потужні та універсальні. Все більше й більше пристроїв, незалежно від їх розміру, потреби в електроживлення, покладаються на загальні MCU. Все більше і більше компаній приєднуються до гри, привносячи орду нових розробників з різним фоном. Культура "середнього значення" відходить від традиційного "хлопця з програмного забезпечення з навичками майстра програмування" до "хлопця з неясними технічними знаннями".

Це добре чи погано - не має значення. Це просто відбувається. Власне, це траплялося і в світі програмного забезпечення не раз. Веб-бум 2000 року залучив новачків PHP / MySQL - іди, скажи їм, що в ЦП є регістри, вони відповідуть "Я використовую Linux, тому в моїй ОС немає реєстру". Раніше багатокористувацькі ОС, що працюють в захищеному режимі, дозволяли ледачим розробникам ніколи не встановлювати ІСР протягом усієї своєї кар'єри і бути добре . Навіть раніше виробники карток для клавіатур та екрану виготовлені з божевільних карт та з принтерів.

І так, сучасні тенденції мене особисто сумують, оскільки я бачу необізнаних розробників в захваті від останніх блискучих технологій, але зовсім не в змозі пов’язати їх з історією. Коли я бачу, як молодший я кодував гру в Javascript з WebGL в 2015 році, я хочу кричати "Нічого нового! Я те ж саме робив із C ++ та 3Dfx SDK ще в 1995 році!". Що історія не розповідає, що його гра працює на моєму мобільному телефоні, тоді як моєму потрібен геймерський ПК (і інсталятор, і я не міг підштовхувати оновлення в Інтернеті). Правда, він міг розвинути гру в один місяць, де я робив те саме в шість, або дванадцять.

Очевидно, що ні ST, ні TI, ні Intel, або хто виробляє чіпи, не хочуть пропустити чергу. І вони праві. HAL - це відповідь ST, і насправді це досить добре, не тільки з боку бізнесу чи маркетингу, але й з боку інженерії. Причина, чому це звучить, криється в назві:

Шар абстракції обладнання

Якщо що-небудь ще, це те, що ви повинні пам’ятати. HAL - це намагання відійти від обладнання. Це хороша інженерія, тому що дозволяє відключити функціональність від деталей. Напластованість - це те, що дозволяє розробляти складні програми - одна абстракція поверх іншої, аж до апаратної. Абстракція насправді є найпотужнішим інструментом, який ми маємо для управління складністю . Я дуже сумніваюся, що хтось на цій планеті зможе запрограмувати веб-браузер у зборі для конкретного процесора.

Культурний зсув насправді важко засвоюється, але, як я повинен вважати, не потрібно читати Книгу мистецтва комп’ютерного програмування Кнута, щоб розвивати веб-додатки, світ EE повинен визнати, що є нові люди, які можуть (і будуть!) Розробляти вбудований код не прочитавши Посібника з чортів .

Хороша новина - нові гравці не означають меншої роботи для старших гравців - навпаки, IMHO. До кого вони дзвонять, коли речі "не працюють?". Якщо у вас є RTFM (на відміну від них), і якщо ви знаєте, що робить кожен біт цього неясного реєстру конфігурації, ви маєте перевагу.

Між вашими читаннями та експериментами просто перейдіть до програми HAL. Новий MCU? Без проблем. Нова лінія MCU? Також немає проблем (я зашифрував тест на STM32F4 Nucleo всього за день із CubeMX, а потім просто переніс його на наш пристрій ... це просто почувалося правильно ). Знущання з одиничних тестів? Без проблем. Список продовжується і продовжується, тому що абстракція хороша.

Звичайно, сама HAL не на 100% нормальна. Це документація жахлива (але у вас RT F HRM, чи не так?), Є помилки, ST просто скинув бета-версію у нас (здається досить стандартною в наші дні), і їх громадська підтримка - жарт. Але не звільняти HAL було б ще гірше.


Я бачу, звідки ти родом. Як я розумію, речі (на жаль) йдуть ардуїнським шляхом, намагаючись приховати якомога більше реальності від програміста, щоб заманювати більше програмного забезпечення високого рівня в апаратне програмування, і це є причиною таких бібліотек, як HAL. Однак, бачачи, як це погано задокументовано, і повний безлад, я не думаю, що їм це вдасться зробити в найближчий час.
Джон

@John: HAL не приховує жодної "реальності". Все є для вас, щоб налаштувати. Всі деталі необов’язкові - наприклад, ви можете використовувати лише макроси для доступу до регістрів, або лише певний драйвер (наприклад, I2C) або все, включаючи ISR та конфігурацію годин. Твій вибір. Однак, я погоджуюся, що документація дуже гасить. (Я сказав ST, і вони пообіцяли, що працюють над цим BTW)

Ми повторюємо те, що робимо те ж саме з новими інструментами. Оскільки нові інструменти обіцяють зробити роботу простішою та швидшою, тим самим економічно вигідною. Але ми все ще робимо те саме, тому що люди все ще однакові, незалежно від того, було це 2095 чи 1995 рр. Вибір залишається нам, якщо ми будемо дотримуватися нових інструментів або залишитися з нашими вже знайомими інструментами.
Джоні
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.