Як ефективно декодувати нестандартний послідовний сигнал

Я є членом наукової групи дослідницької групи, яка працює над проектом, який передбачає передачу радіочастотних сигналів ASIC та його бездротовий приймач, який в кінцевому рахунку повинен надсилати дані на ПК.

Одержувач видає швидкий , безперервний, асинхронний нестандартний послідовний сигнал (тобто не SPI, I2C, UART тощо), тому моя робота полягає в написанні програмного забезпечення мікроконтролера для інтерфейсу приймача до комп'ютера. В даний час мій підхід полягає у використанні переривань, що викликаються краєм, щоб розмістити дані в круговому буфері і виконати весь процес розшифровки побітів в основному циклі. Мікроконтролер повинен одночасно виводити ці дані за допомогою USB (віртуального компонента) на комп'ютер.

Ось проблема, яка у мене є, і одна, яку я передчуваю:

1. Я не можу обробляти завантажені дані досить швидко навіть за допомогою мого досить потужного процесора ARM Cortex M3 72 МГц. Бітрейт становить 400 Кбіт / с (2,5 нас / біт). Для довідки, що залишає лише 180 циклів на біт (включаючи декодування AND ISR, що має ~ 30 циклів накладних оч!). MCU також має вирішувати безліч інших завдань, які він запитує в основному циклі.

2. USB-драйвер віртуального компорту також заснований на перериванні. Це робить мене майже впевненим, що драйвер врешті-решт перерве процесор настільки довго, що він пропустить вікно 2,5 мікросекунди (цикл 180), в яке може бути передано трохи. Я не впевнений, як нормально вирішуються подібні конфлікти / перегони.

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

Ще одна відповідь: припиніть використовувати переривання.

Люди стрибають, щоб використовувати переривання занадто легко. Особисто я їх рідко використовую, оскільки вони насправді витрачають багато часу, як ви виявляєте.

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

loop
{
    if (serial_bit_ready)
    {
        // shift serial bit into a byte
    }

    if (serial_byte_ready)
    {
        // decode serial data
    }

    if (enough_serial_bytes_available)
    {
        // more decoding
    }        

    if (usb_queue_not_empty)
    {
        // handle USB data
    }        
}

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

loop
{
    if (serial_bit_ready)
    {
        // shift serial bit into a byte
    }

    if (serial_byte_ready)
    {
        // decode serial data
    }

    if (serial_bit_ready)
    {
        // shift serial bit into a byte
    }

    if (enough_serial_bytes_available)
    {
        // more decoding
    }        

    if (serial_bit_ready)
    {
        // shift serial bit into a byte
    }

    if (usb_queue_not_empty)
    {
        // handle USB data
    }        
}

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

Ви можете, можливо, використовувати FPGA замість мікроконтролера для декодування та буферування бездротового потоку даних. Потім використовуйте процесор ARM для промивання буферів FPGA (наприклад, за допомогою інтерфейсу SPI) та відправлення вмісту на порт USB Comm. Це працює, але FPGA повинна бути в змозі легко підтримувати, доки ви зможете її обслуговувати досить часто, щоб гарантувати, що її апаратні буфери не перевищують (або якщо ви можете працювати з випалими даними на більш високому рівні протоколу ).

Простота: Використовуйте мікроконтролер PSoC5 .

Ви маєте всю простоту використання мікроконтролера, а також він містить CPLD, тому ви можете записувати власні апаратні периферійні пристрої у Verilog. Просто запишіть свій декодер послідовних даних у verilog та використовуйте DMA, щоб передати його на порт USB.

Тим часом потужне 32-розрядне ядро ​​ARM може вдруге впорядкувати свої інструменти Thumb.

Я думаю, у вас є класичний інженерний вибір: швидко, дешево, працює: виберіть два.

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

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

Перш за все, мені вже подобаються деякі відповіді, а за деякі я отримав свій голос.

Але просто запропонувати інше можливе рішення: якщо врахувати обмеження вашого проекту, чи було б додавання другого мікроконтролера поганим (якщо це передбачає запуск іншої плати)? Можливо, простий 8-бітовий мікроконтролер, який підключається до вашого Cortex-M3 через такий швидкий периферійний апарат, як SPI. 8-бітний контролер, який ви обрали, опитував бити та формує байти так само, як у вибраній відповіді, але коли у нього є байт, він може скинути його до реєстру даних SPI для передачі.

Сторона cortex-M3 просто перериватиме отримані дані SPI. Це зменшує попередній перерив, що спрацьовує зовнішній край 400 кГц, до 50 кГц.

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

Крім цього, я думаю, що ідея PSoC приголомшує ваш власний периферійний перехід через DMA на USB.

Якщо ваш формат даних схожий на формат UART, але з непередбачуваною, але послідовною швидкістю передачі даних, моя схильність полягатиме у використанні CPLD для перетворення кожного слова вхідних даних у формат SPI або стандартний асинхронний формат. Я не думаю, що немає потреби проштовхуватися до царини CPLD. Насправді навіть дискретна логіка може бути майже працюючою. Якщо ви могли генерувати годинник, розмір якого перевищував 5 разів більше бажаної швидкості передачі даних, ви можете використовувати лічильник ділення на п'ять та ділення на 16 з кількома воротами. Впорядкуйте лічильник ділення на п’ять так, щоб він утримувався в режимі скидання, коли вхід не працює, а лічильник поділу на 16 не дорівнює нулю. В іншому випадку генеруйте тактовий імпульс SPI та піднімайте лічильник ділення на 16 у будь-який момент, коли лічильник розділення на п'ять потрапляє на 2.

Враховуючи 5-кратний годинник, можна створити годинник SPI, використовуючи 16V8 (найменший і найдешевший на даний момент програмований логічний пристрій). Другий 16V8 або 22V10 може бути використаний як роздільник часток частот для генерації 5-кратного годинника, або можна використовувати трохи більший чіп (CPLD) і робити все в одному.

Редагування / Додаток

Після деякого подальшого розгляду, якщо хтось збирається використовувати CPLD, можна легко додати до схеми кілька додаткових удосконалень. Наприклад, можна досить легко додати логіку до зупинки ланцюга, поки вона не отримає щонайменше 1,5 бітових разів стоп-біта, а потім 3,5 бітових разів стартового біта; якщо він отримує занадто короткий стартовий біт, він повинен повернутися до пошуку стоп-біта. Крім того, якщо хтось використовує SPI, можна використовувати сигнал / CS, щоб переконатися, що приймаючий пристрій побачить правильно встановлені дані. Якщо пристрій, що приймає дані SPI, може обробляти 10-бітні кадри, такі кадри можна надсилати безпосередньо. В іншому випадку кожен десятирозрядний кадр може бути надісланий як 8-бітний кадр з набором LSB (7 біт даних), так і кадр з усіма чіткими LSB (3 біти даних); Час SPI буде пришвидшений під час зупинки бітів, тому всі дані будуть відправлені.

Деякі мікроконтролери мають досить універсальні модулі генерації ШІМ, які включають в себе такі речі, як можливість утримувати скидання за допомогою зовнішнього сигналу та синхронізувати їх синхронізацію до виходу такого сигналу. Якщо ваш мікроконтролер може це зробити, залежно від його точних особливостей, це може значно спростити схему CPLD або схему генерації часу.

Ще одним підходом, який Rocketmagnet трохи торкнувся, було б мати невеликий мікрофон, єдиною метою якого є декодування послідовних даних та перетворення їх у формат, придатний для використання основним мікрофоном. Ваша швидкість передачі даних на 400 КГц досить швидка для розшифровки програмного забезпечення, але щось подібне до PIC може впоратися з цим, якщо одночасно нічого не потрібно було робити. Залежно від того, які пристрої ви знайомі, це може бути простіше або складніше, ніж використання CPLD.