Завантажувач - це програма, яка працює в мікроконтролері, який потрібно запрограмувати. Він отримує нову програмну інформацію зовні через деякі засоби зв'язку та записує цю інформацію в програмну пам'ять процесора.
Це на відміну від звичайного способу потрапляння програми в мікроконтролер, який здійснюється за допомогою спеціального обладнання, вбудованого в мікросхему для цієї мети. На PIC це інтерфейс, подібний до SPI. Якщо я пам'ятаю правильно, AVR використовують Jtag, або принаймні деякі з них. Так чи інакше, для цього потрібне деяке зовнішнє обладнання, яке змішує шпильки програмування правильно, щоб записати інформацію в пам'ять програми. Файл HEX, що описує вміст програмної пам'яті, походить з комп'ютера загального призначення, тому це обладнання з'єднується з комп'ютером з одного боку та спеціальними штифтами програмування мікро - з іншого. Моя компанія робить програмістів PIC, крім усього іншого, стороною, тому я досить добре знайомий з цим процесом на PIC.
Важливим моментом зовнішнього програмування за допомогою спеціалізованого обладнання є те, що воно працює незалежно від наявного вмісту програмної пам'яті. Мікроконтролери починаються зі стираної пам'яті програми або в невідомому стані, тому зовнішнє програмування - єдиний засіб для отримання першої програми в мікро.
Якщо ви впевнені в програмі, яку ви хочете завантажити у свій продукт, і ваші обсяги досить великі, ви можете мати для вас виробника чи дистриб'юторські чіпи програми. Мікросхема припаюється до плати, як і будь-яка інша мікросхема, і пристрій готовий до роботи. Це може бути доречно для чогось, наприклад, іграшки. Після того як прошивка буде зроблена, вона майже зроблена, і вона буде випускатися великими обсягами.
Якщо ваш обсяг менший, або що ще важливіше, ви очікуєте постійної розробки мікропрограмного забезпечення та виправлень помилок, ви не хочете купувати заздалегідь запрограмовані чіпи. У цьому випадку пусті мікросхеми встановлюються на платі, і прошивка повинна завантажуватися на мікросхему в рамках виробничого процесу. У цьому випадку рядки програмного забезпечення апаратних засобів повинні бути доступні якось доступними. Це може бути через явний роз'єм або пого контактні колодки, якщо ви готові створити виробничий тестовий кріплення. Часто такі продукти доводиться перевіряти і, можливо, все-таки калібрувати, тому додаткові витрати на написання програми на процесор зазвичай мінімальні. Іноді, коли використовуються невеликі процесори, спочатку в процесор завантажується спеціальна виробнича тестова прошивка. Це використовується для полегшення тестування та калібрування пристрою, тоді реальна прошивка завантажується після того, як апаратне забезпечення, як відомо, добре. У цьому випадку є деякі міркування конструкції схеми, щоб дозволити доступ до ліній програмування достатньо для того, щоб процес програмування працював, але також не створював надто незручності для схеми. Детальніше про це дивіться у моїйсписання програмування в ланцюзі .
Поки що добре, і завантажувач не потрібен. Однак розгляньте продукт із відносно складною прошивкою, який потрібно оновити на полі або навіть дозволити кінцевому клієнту оновити. Ви не можете очікувати, що кінцевий клієнт матиме гаджет-програміст або знати, як правильно ним користуватися, навіть якщо ви його надали. Насправді це робить один із моїх клієнтів. Якщо ви купуєте їх спеціальний варіант налаштування поля, ви отримуєте одного з моїх програмістів із продуктом.
Однак у більшості випадків ви просто хочете, щоб клієнт запустив програму на ПК та оновив програмне забезпечення магічним чином. Тут надходить завантажувач, особливо якщо ваш продукт вже має порт зв'язку, який може легко взаємодіяти з ПК, наприклад, USB, RS-232 або Ethernet. Клієнт запускає програму ПК, яка спілкується з завантажувачем вже в мікрофоні. Це посилає новий бінарний файл до завантажувача, який записує його в пам'ять програми, а потім призводить до запуску нового коду.
Звучить просто, але це не так, принаймні ні, якщо ви хочете, щоб цей процес був надійним. Що робити, якщо трапляється помилка зв’язку, і нова прошивка пошкоджується до моменту надходження до завантажувача? Що робити, якщо живлення переривається під час завантаження? Що робити, якщо завантажувач має помилку і лаєть на собі?
Спрощений сценарій полягає в тому, що завантажувач завжди працює від скидання. Він намагається спілкуватися з господарем. Якщо хост відповідає, він або повідомляє завантажувачу, що він нічого нового, або надсилає йому новий код. По мірі надходження нового коду старий код перезаписується. Ви завжди додаєте контрольну суму із завантаженим кодом, щоб завантажувач міг визначити, чи є новий додаток неушкодженим. Якщо ні, то він залишається у завантажувачі, постійно вимагаючи завантаження, поки щось з дійсною контрольною сумою не завантажується в пам'ять. Це може бути прийнятним для пристрою, який завжди підключений і, можливо, там, де виконується фонове завдання на хості, який відповідає на запити завантажувача. Ця схема не є корисною для одиниць, які значною мірою є автономними та лише зрідка підключаються до хост-комп'ютера.
Зазвичай простий завантажувач, як описано вище, є неприйнятним, оскільки не існує безпечного відключення. Якщо зображення нового додатка не отримано неушкодженим, ви хочете, щоб пристрій продовжував працювати зі старим зображенням, не бути мертвим, поки не буде виконано успішне завантаження. З цієї причини зазвичай у прошивці є два спеціальні модулі, програма завантажувача та завантажувач. Завантажувач є частиною основного додатка. У рамках регулярного спілкування з хостом можна завантажувати нове зображення програми. Для цього потрібна окрема пам'ять від основного зображення програми, як-от зовнішній EEPROM або використання більшого процесора, щоб половина простору пам’яті програми могло бути виділено для зберігання нового зображення додатка. Завантажувач просто записує отримане нове зображення програми десь, але не запускає його. Коли процесор скидається, що може статися за командою від хоста після завантаження, завантажувач працює. Зараз це повністю автономна програма, яка не потребує можливості зовнішнього спілкування. Він порівнює поточну та завантажену версії додатків, перевіряє їх контрольні суми та копіює нове зображення на область програми, якщо версії відрізняються та перевіряє нову контрольну суму зображень. Якщо нове зображення пошкоджене, воно просто запускає старий додаток, як і раніше.
Я зробив багато завантажувачів, і жодне два не те саме. Немає завантажувача загального призначення, незважаючи на те, що деякі компанії з мікроконтролерів хочуть, щоб ви повірили. У кожного пристрою є свої вимоги та особливі обставини в роботі з господарем. Ось лише декілька конфігурацій завантажувача та інколи завантажувачів, які я використовував:
- Базовий завантажувач. Цей пристрій мав послідовну лінію, і він був би підключений до хоста та увімкнувся у міру необхідності. Завантажувач завантажився з режиму скидання і надіслав хосту кілька відповідей на запит на завантаження. Якщо програма для завантаження працювала, вона відповість та надішле нове зображення програми. Якщо він не відповів протягом 500 мс, завантажувач відмовиться від запуску наявного додатка. Щоб оновити прошивку, потрібно було спочатку запустити програму оновлення на хості, а потім підключити та включити пристрій.
- Завантажувач програмної пам'яті. Тут ми використовували наступний розмір PIC, що мав удвічі більше пам'яті програми. Пам'ять програми була розділена приблизно на 49% основного додатка, 49% нового зображення додатка та 2% завантажувача. Запуск завантажувача запускається зі скидання та копіює нове зображення додатка на поточне зображення додатка за правильних умов.
- Зовнішнє зображення EEPROM Як і №2, за винятком того, що зовнішній EEPROM був використаний для зберігання нового зображення програми. У цьому випадку процесор з більшою кількістю пам’яті був би також фізично більшим і в іншій під-сім’ї, яка б не мала необхідну нам суміш периферійних пристроїв.
- TCP завантажувач. Це було найскладнішим з усіх. Був використаний великий PIC 18F. Останні 1/4 пам'яті або близько цього містили завантажувач, який мав власну повну копію мережевого стеку TCP. Завантажувач працює від скидання та намагався підключитися до спеціального сервера завантаження у відомий порт за попередньо налаштованою IP-адресою. Це було для великих установок, де завжди була виділена серверна машина для всієї системи. Кожен невеликий пристрій після закінчення скидання перевіриться на сервері завантаження та отримає нову копію програми. Завантажувач замінить існуючу програму новою копією, але запустить її лише в тому випадку, якщо перевірена контрольна сума. Якщо ні, то він повернеться на сервер завантаження і спробує ще раз.
Оскільки завантажувач сам по собі був складним фрагментом коду, що містить повний стек мережі TCP, він також повинен був бути оновлений полем. Ми зробили це так, щоб сервер завантаження подав його спеціальним додатком, єдиною метою якого було перезавантажити завантажувач після його виконання, а потім скинути машину, щоб новий завантажувач запустився, що призведе до того, що сервер завантаження надсилатиме останнє зображення основного додатка. Технічно перелом енергії протягом декількох мілісекунд знадобився спеціальним додатком, щоб скопіювати нове зображення через завантажувач, було б непоправною помилкою. На практиці цього ніколи не бувало. У нас все було в порядку з дуже малоймовірним шансом на те, оскільки ці пристрої були частинами великих установок, де вже були люди, які б обслуговували систему, що іноді означало заміну вбудованих пристроїв з інших причин у будь-якому випадку.
Сподіваємось, ви можете побачити, що існує низка інших можливостей, кожна з яких має свої компроміси ризику, швидкості, вартості, простоти використання, простоїв тощо.