Фон

Я розробляю проект, який вимагатиме скромних характеристик мікроконтролера:

• 8 12-бітних, 10 кГц АЦП
• 1 кБ оперативної пам’яті
• 48-QFN або менший слід
• 20 кбіт / с, захист від шуму, стійкий до шуму та виправлення помилок, протокол зв'язку

Вимоги до обробки сигналів досить низькі, і більшість може бути експортовано до головного процесора в системі. Перші три характеристики легко зустріти, і їх можна зробити за менше 2 доларів. Однак спілкування буде відбуватися в дуже шумному середовищі, тому мережі, вразливі від шуму, такі як LIN та I2C, виходять із мережі. Додатковий аргумент проти LIN полягає в тому, що я хотів би запустити все на 5V або 3.3V, а для приймачів LIN потрібно 12В, і тому потрібен буде додатковий регулятор або провід на платі датчика. Спочатку я вибрав CAN для цього завдання. Однак контролери CAN додають значних витрат, і мені цікаво, чи можна це зробити в програмному забезпеченні.

МОЖЛИВО фізичний шар

Специфікація CAN визначає шари передачі даних та фізичні рівні еталонної моделі мережі OSI. Для реалізації фізичного рівня існує безліч недорогих 8-контактних ІС, таких як NXP TJA1040 / 50 , Maxim MAX3058 / 59 , Microchip MCP2551 та TI SN65HVD1050 . Реалізація фізичного рівня за допомогою перетворювачів D / A або підсилювачів буде важкою, якщо не неможливою, тому ці ІМС коштують 1 долара або близько того, що вони коштують.

МОЖЛИВО Зв’язок даних / протокол

Для рівня даних Data Link деякі мікроконтролери додають модулі протоколу CAN на базовий рівень зв'язку UART, I2C та SPI. Однак вони значно дорожчі, ніж основні чіпи.

Дослідження вартості модулів протоколу CAN

Щоб обґрунтувати це твердження, ось кілька популярних мікро-версій у версіях CAN та не-CAN:

• ATmega16 - ATMEGA16M1 (з CAN): $ 3,87, ATMEGA168A (без CAN): 3,23 дол.
• dsPIC - DSPIC33FJ64MC802 (з CAN): 6,14 дол. США, DSPIC33FJ64GP202 (без CAN): 5,48 дол.
• PIC18 - PIC18F2480 (з CAN): 6,80 дол. США, PIC18F24J10 (без CAN): 2,10 дол. США
• Cortex-M3 - STM32F103C4T6A (з CAN): $ 6,50, STM32F100C4T6B (без CAN): $ 2,73

Справедливо кажучи, я порівнював лише мікроконтролери з еквівалентними розмірами пам’яті, однак багато версій, які не є CAN, доступні з меншими розмірами пам’яті для менших. Зовнішні контролери CAN, як Microchip MCP2515 , коштують майже 2 долари, тому, очевидно, вигідніше інтегрувати CAN в мікроконтролер, якщо є можливість.

Цікаво, що частина ATmega - це найдешевша з CAN-комплектуючої частини в інвентарі Digikey.

Функція шару протоколу CAN

Модуль CAN, знайдений в мікроконтролерах dsPIC, виконує наступні дії:

Модуль шини CAN складається з двигуна протоколу та буферизації / управління повідомленнями. Двигун протоколу CAN обробляє всі функції прийому та передачі повідомлень на шині CAN. Повідомлення передаються спочатку завантаженням відповідних регістрів даних. Стан та помилки можна перевірити, прочитавши відповідні регістри. Будь-яке повідомлення, виявлене на шині CAN, перевіряється на наявність помилок, а потім порівнюється з фільтрами, щоб побачити, чи слід його отримувати та зберігати в одному з регістрів прийому.

Це здається досить можливим у програмному забезпеченні.

Питання

Чи можна використовувати рівень протоколу програмного забезпечення, що реалізує специфікацію CAN лише з недорогим мікроконтролером UART та приймачем CAN? Якщо так, то чи існують будь-які реалізації з відкритим кодом?

Чи можна CAN-приймачі використовувати з UART для впровадження користувальницького протоколу? Я з нормальною топологією одноосібника; Я розумію, що арбітраж може бути важким для отримання права в користувальницькому протоколі.

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

Однак ваші ціни високі. Я щойно перевірив, і dsPIC 33FJ64GP802 в пакеті QFN продається за 3,68 USD на microchipdirect за 1000 штук. Ціна буде нижчою для реальних обсягів виробництва.

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

Додано:

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

Ви хочете зробити CAN зі швидкістю 20 кбіт / с. Це дуже повільна швидкість для CAN, які піднімаються до 1 Мбіт / с принаймні 10 с метрів. Щоб надати вам одну точку даних, стандарт сигналізації судна NMEA 2000 розміщений на CAN зі швидкістю 200 кбіт / с, і це означає, щоб перейти з одного кінця великого корабля на інший.

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

На шині CAN є два сигнальних стани, рецесивне та домінуюче. Рецесивним є те, що відбувається, коли нічого не їздить в автобусі. Обидві лінії об'єднуються загалом на 60 Ом. Звичайна шина CAN, реалізована загальними мікросхемами, такими як MCP2551, повинна мати кінцеві термінали 120 Ом на обох кінцях, отже, загалом 60 Ом, пасивно потягуючи дві диференціальні лінії. Домінуючий стан - це коли обидві лінії активно відриваються один від одного, десь близько 900мВ від рецесивного стану, якщо я добре пам'ятаю. В основному це схоже на шину відкритого колектора, за винятком того, що вона реалізована за допомогою диференціальної пари. Шина знаходиться в рецесивному стані, якщо CANH-CANL <900mV і домінантна, коли CANH-CANL> 900mV. Домінантний стан сигналізує 0, а рецесивний 1.

Щоразу, коли вузол "записує" a в шину (відпускає його), він перевіряє, чи записує якийсь інший вузол 0. Коли ви знаходите шину в домінуючому стані (0), коли ви думаєте, що ви надсилаєте та поточний біт, який ви надсилаєте, - це 1, то це означає, що надсилається і хтось інший. Зіткнення мають значення лише тоді, коли два відправники не згодні, і правило полягає в тому, що той, хто надсилає рецесивний стан, відступає і скасовує своє повідомлення. Вузол, що надсилає домінуючий стан, навіть не знає, що це сталося. Так працює арбітраж на шині CAN.

Правила арбітражу CAN шини означають, що вам потрібно спостерігати за маршрутом шини через кожен біт, який ви надсилаєте як 1, щоб переконатися, що хтось інший не надсилає 0. Ця перевірка зазвичай робиться приблизно на 2/3 шляху в біт , і є основним обмеженням довжини шини CAN. Чим повільніше швидкість бітів, тим більше часу для гіршого випадку поширення з одного кінця шини на інший, а значить, і шина може бути довшою. Цю перевірку потрібно робити кожен біт, коли ви думаєте, що ви володієте шиною та відправляєте 1 біт.

Ще одна проблема - коригування швидкості передачі бітів. Усі вузли в шині повинні узгоджувати швидкість передачі бітів, більш тісно, ​​ніж для RS-232. Щоб запобігти накопиченню невеликих годинних різниць у значні помилки, кожен вузол повинен мати можливість зробити трохи довший або коротший, ніж його номінальний. В апаратному забезпеченні це реалізується за допомогою годинника десь від 9x до 20x швидше, ніж швидкість передачі бітів. Цикли цього швидкого годинника називаються квантами часу. Існують способи виявити, що початок нових біт блукає щодо того, де ви вважаєте, що вони повинні бути. Потім апаратні реалізації додають або пропускають одноразові кванти, щоб повторно синхронізувати. Існують і інші способи, які можна реалізувати, якщо ви можете пристосуватись до невеликих перепадів у фазі між очікуваними бітовими часом та фактичними виміряними бітовими часом.

Так чи інакше, ці механізми вимагають робити різні речі в різний час протягом декількох разів. Такі терміни стануть дуже складними у вбудованому програмному забезпеченні або вимагатимуть запуску шини дуже повільно. Скажімо, ви впроваджуєте систему квантів часу в прошивці при швидкості 20 кбіт / с. Як мінімум 9 квантів часу на біт, це вимагатиме переривання 180 кГц. Це звичайно можливо з чимось на зразок dsPIC 33F, але з'їсть значну частину процесора. При максимальній швидкості інструкцій 40 МГц ви отримуєте 222 цикли інструкцій за переривання. Не потрібно забирати стільки часу, щоб провести всі перевірки, але, мабуть, 50-100 циклів, тобто 25-50% процесора буде використовуватися для CAN і що йому потрібно буде викупити все, що працює. Це перешкоджає застосуванню багатьох процесорів, якими часто користуються ці процесори, як імпульс пульсовим регулюванням живлення комутації або драйвера двигуна. Затримка циклу 50-100 на кожному іншому перериванні буде повною зупинкою шоу для багатьох речей, які я робив з подібними чіпами.

Тож ви збираєтеся витратити гроші, щоб якось зробити МОЖЛИВО. Якщо не в спеціальній апаратній периферії, призначеній для цієї мети, то в отриманні більшого процесора для обробки значних накладних програм і потім вирішувати непередбачувані та можливі великі затримки переривання для всього іншого.

Потім є передня техніка. CAN-периферія просто працює. З вашого коментаря, здається, що додаткова вартість цього периферійного пристрою становить $ 56. Мені здається, що це угода. Якщо у вас дуже високий обсяг продукту, ви не зможете повернути значну кількість часу і витрат, які знадобляться для впровадження CAN лише в прошивці. Якщо ваші обсяги такі високі, ціни, про які ми вже згадували, так чи інакше не реалістичні, і різниця для додавання апаратних засобів CAN буде нижчою.

Я справді не бачу в цьому сенсу.

Ми використовуємо PIC18F25K80 . Хоча він не має DSP, він становить ~ 2 долари. Це майже прямий замінник згадуваного вами PIC18F2480. Ми використовуємо компілятор CCS та їхній стек програмного забезпечення для CAN, який, ймовірно, переноситься з Microchip. Він добре працює на все, що мені потрібно і спробував.

Якщо я читаю це право, це здається, що ви хочете трохи розбити функціонал CAN, використовуючи лише UART та деякі розумні прошивки. Повірте, це ніколи не вийде - пропоную прочитати хороший текст про тонкощі CAN або CANopen. Ви знищили будь-яку економію витрат, шукаючи цей маршрут.

Я б або використовував мікроконтролер з модулем CAN і передав зайві $ 2, або ви думали про інший протокол, сумісний з UART, наприклад Modbus над RS-485 ?

Я також замислююся над бітовим ударом CAN-протоколу на PIC µC, тому, будь ласка, EricM, якщо ви дійсно це зробили, будь ласка, відповідайте і скажіть принаймні, який бітрейт на якій базовій частоті PIC18F або DSPic у вас є. Дякую!

Загалом: RS 485 буде вирішенням первинної заданої проблеми, але також можна було б використовувати CAN- (або навіть FlexRay) -приймачі з не повним дуплексним UART-зв’язком (точка 2 бала) як усі ці протоколи використовувати кодування NRZ.

Але в UART / V24 / RS232 повний дуплекс використовується здебільшого, не замислюючись докладно, тому, можливо, вам знадобиться покласти трохи мозку на суперлоп або державний апарат вашої програми ...

Але повернемося до CAN-bitbanging: я працюю з CAN протягом багатьох років і ніколи не бачив впровадження бітбінгу, але, наскільки я можу подумати, це повинно працювати для тимчасових розрядів до tp 100kBit з сучасними µC, такими як DSPic або ARM і т.д. (з ядрами на 80 МГц і вище ...)

Принаймні, якщо враховується лише перечитання ... Відправка означатиме деякий накладний витрата на підготовку бітових структур, так що не 100% завантаження буде доступним, але в CAN більше 65% є рідкістю взагалі ...