Чому б не завжди використовувати DMA на користь перерв з UART на STM32? [зачинено]

Минулого місяця я витрачаю багато часу на те, щоб UART (для MIDI) працював з STM (STM32F103C8T6), використовуючи переривання, не дуже багато успіху.

Однак цього вечора за допомогою DMA він працював досить швидко.

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

Я використовую STM32CubeMx / HAL.

Хоча DMA знімає процесор і, таким чином, може зменшити затримку інших програм, керованих переривами, що працюють на одному ядрі, з цим пов'язані витрати:

• Існує лише обмежена кількість DMA-каналів, і є обмеження в тому, як ці канали можуть взаємодіяти з різними периферійними пристроями. Інша периферійна мережа на тому ж каналі може бути більше підходить для використання DMA.

  Наприклад, якщо у вас є об'ємна передача I2C кожні 5 мс, це здається кращим кандидатом для DMA, ніж випадкова команда налагодження, що надходить на UART2.

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

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

• Для роботи з DMA потрібні буфери пам’яті (якщо ви не використовуєте DMA від периферійних до периферійних), тому з цим пов’язані певні витрати на пам'ять.

  (Вартість пам’яті також може бути при використанні переривань символів, але вона може бути значно меншою або зовсім зникне, якщо повідомлення інтерпретуються відразу всередині переривання.)

• DMA створює затримку, оскільки процесор отримує сповіщення лише тоді, коли передача завершена / наполовину завершена (див. Інші відповіді).

• За винятком потокової передачі даних у / з буфера дзвінка, вам потрібно заздалегідь знати, скільки даних ви будете отримувати / надсилати.

  • Це може означати, що потрібно обробити перші символи повідомлення за допомогою символів переривань: наприклад, під час взаємодії з XBee, ви спершу прочитаєте тип і розмір пакету, а потім запускаєте передачу DMA у виділений буфер.

  • Для інших протоколів це взагалі неможливо, якщо вони використовують лише роздільники кінця повідомлення: наприклад, текстові протоколи, які використовують '\n'як роздільник. (Якщо периферія DMA не підтримує відповідність символу.)

Як бачите, тут можна розглянути багато компромісів. Деякі пов'язані з обмеженнями обладнання (кількість каналів, конфлікти з іншими периферійними пристроями, відповідність символів), деякі базуються на використаному протоколі (роздільники, відома довжина, буфери пам'яті).

Щоб додати деякі анекдотичні докази, я зіткнувся з усіма цими компромісами в хобі-проекті, який використовував багато різних периферійних пристроїв з дуже різними протоколами. Було здійснено деякі компроміси, здебільшого ґрунтуючись на питанні "скільки даних я передаю і як часто я це роблю?". Це по суті дає вам приблизну оцінку впливу простого переривання, керованого перериванням на процесор. Таким чином, я віддав перевагу вищезгаданій передачі I2C кожні 5 мс через передачу UART кожні кілька секунд, яка використовувала той самий канал DMA. Інша передача UART відбувається частіше, і з іншого боку більше даних отримує пріоритет над іншою передачею I2C, яка трапляється рідше. Це все компроміси.

Звичайно, використання DMA також має переваги, але це не те, про що ви просили.

Використання DMA зазвичай означає, що ви більше не приймаєте переривань щодо кожного символу, а скоріше лише після отримання (або передачі) "буфера, повного" символів. Це збільшує затримку обробки цих символів - перший символ не обробляється, поки не буде отримано останній символ у буфері.

Ця затримка може бути поганою справою, особливо в застосуванні, залежно від затримки, такого як MIDI, де декілька мс тут і там можуть спричинити серйозні проблеми відтворення для виступів у прямому ефірі.

DMA не замінює переривання - вони зазвичай використовуються разом! Наприклад, якщо ви використовуєте DMA для надсилання даних через UART, наприклад, вам все одно потрібно перервати, щоб повідомити, коли надсилання закінчиться.

Використання DMA вводить цікаві питання та виклики, що перевищують усі інші аспекти периферійного використання UART. Наведу кілька прикладів: Припустимо, що ваш комп'ютер сидить на шині RS485 (або будь-якій іншій) з іншими пристроями. У автобусі є багато повідомлень, деякі призначені для вашого UC, деякі - ні. Крім того, припустимо, що всі ці сусіди шини говорять про різні протоколи даних, що означає, що довжина повідомлень різна.

Деякі питання, які виникають лише при використанні DMA:

• коли я перебиваю?
  • Перешкоджати перерві DMA дуже хочеться лише тоді, коли вони перенесли заданий обсяг даних.
  • Що ви робите, якщо ніколи не отримуєте достатньо даних, щоб викликати перерву DMA?
• Що робити, якщо ви отримуєте лише часткове повідомлення, коли DMA переривається?
• Як виглядають ваші буфери RX? Вони лінійні чи кругові?
  • DMA може бути непорушним учасником кругового буфера в тому сенсі, що він підпорядковується лише кордону адреси, але не має проблем пробиватися повз інші вказівники в системі кругового буфера.

У всякому разі, просто їжа для роздумів.

На стороні прийому (наскільки я пам'ятаю) DMA припиняється або на символьній відповідності, або на терміналі. Деякі протоколи та багато інтерактивних додатків не легко вписуються в цю модель, і вам справді потрібно обробляти речі за характером. Методи DMA також можуть бути крихкими, якщо зв’язок зв'язку ненадійний, втрата одного символу в потоці може легко зіпсувати ваш стан DMA.

Я використовував STM32CubeMx / HAL в декількох проектах зараз і виявив, що програмне забезпечення для обробки UART, яке він створює, має певні недоліки на стороні прийому.

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

Що стосується прийому даних, то функції, передбачені ST, передбачають, що ви знаєте, скільки символів надасть вам пристрій, що надсилає, перш ніж він почне надсилати. Зазвичай це не відомо. Функціональність переривання розміщує отримані дані в буфер і вказує лише на те, що є дані, коли отримано заздалегідь задану кількість символів. Якщо ви спробуєте використовувати функцію DMA або перервати функціональність для отримання даних, встановивши послідовні передачі одного символу, то час настройки для кожного з них означатиме, що ви втратите символи за будь-яким іншим, ніж найповільніші швидкості передачі даних (швидкість передачі даних, яку ви будете мати Початок втрати даних буде залежати від тактової частоти процесора) і надмірно завантажить процесор, не залишаючи циклів інструкцій для будь-якої іншої обробки

Щоб обійти це питання, я написав власну функцію обробника переривань, яка зберігає дані в невеликому локальному круговому буфері і встановлює кількість, яка читається основним кодом (RTM-рахунковий семафор), щоб вказати, що отримані дані готові. Основний код може потім збирати дані з цього буфера у вільний час, неважливо, чи є певна затримка в зборі даних, якщо локальний буфер не переповнюється до збору даних.