Загрузчик XModem


Для девайсов на AVR с RS-485 я использую бутлоадер AVR Universal Bootloader sites.google.com/site/shaoziyang/Home/avr/avr-universal-bootloadere. Бутлоадер работает по протоколу XModem CRC (или Check Sum). Для загрузки есть родной софт он прикольный и может кроме загрузки делать конфиг для бутлоадера, при выборе соотвествующего мк и опций. Все работает все ок. Но родной софт несколько сложен для пользователей далеких от программирования, которым нужно только перезалить прошивку, поэтому я решил учудить свой вариант попроще и надеюсь более понятный.
Программа умеет заливать данные по протоколу XModem c CRC. Здесь хорошее описание протокола и контрольной суммы www.amulettechnologies.com/GEMhelp/GEMstudio/xmodem.htm. Заливается бинарный файл — предварительно сконвертированный из hex утилиткой Hex2Bin. В моем варианте зафиксированы параметры порта: 19200/n/8 — это дает скорость ~1.6кб/с, что вполне нормально. Да и должна работать нормально из под Win7 64 — собственно еще одна причина для написания ибо Hyperterminal тут уже нет.
XModem начинает загрузку после получения символа коннекта -'C' от устройства и посылает следующий пакет только после получения сообщения ACK или NACK от устройства.
Как пользоваться:
1.Открыть bin файл
2. Выбрать и открыть порт -«Open»
3. Нажать «Load»
4. Включить устройство с активированным режимом бутлоадера

После загрузки файла видно что было загружено:

Заливаем:

Процесс окончен:


Пожелания, предложени, баги (а они есть :)) — короче пишите если что.
  • +3
  • 06 апреля 2012, 20:09
  • GYUR22
  • 1
Файлы в топике: XModem_loader.zip

Комментарии (16)

RSS свернуть / развернуть
За статью Вам «+», но позвольте позанудствовать:

Но родной софт несколько сложен для пользователей далеких от программирования

Если хотите сделать простой лоадер для «обывателя», то, в идеале, интерфейс должен состоять из одной кнопки «сделать зашибись» «обновить прошивку»

У Вас для этого есть все возможности

XModem начинает загрузку после получения символа коннекта -'C' от устройства

Значит можно автоматически определить номер нужного COM-порта, прослушивая поочередно все доступные порты. При необходимости, можно автоматически определить baudrate и т. д.

А вот вывод дампа прошивки – (ИМХО) излишне, такая фича даже программисту не особо нужна, а «обывателю» — не нужна подано.

Как по мне, идеальный вариант для «обывателя» – одна кнопка + ProgressBar + MessageBox с результатом в конце операции. Остальное можно спрятать в меню для «продвинутых» пользователей.
+2
все эти фичи пользователю то не очень нужны, но они важны для диагностики т.е. если, что то пойдет не так чтобы можно было понять где это произошло.
прослушивать все доступные порты это не айс… а если нужный порт тупо занят обменом по другим делам?
0
все эти фичи пользователю то не очень нужны, но они важны для диагностики

Если речь идет о выводе дампа – то среднестатистическому пользователю диагностика особо не нужна. Пользователю нужно знать, чем закончилась операция. Если произошла ошибка – лучше вывести понятное для пользователя описание ошибки и возможные пути устранения (проверьте подключение устройства, убедитесь, что закрыты другие приложения и т. д.).

прослушивать все доступные порты это не айс… а если нужный порт тупо занят обменом по другим делам?

Если порт занят другим приложением – то «рядовой» пользователь не сможет прошить девайс. Даже если он явно укажет номер ком-порта, он получит ошибку типа «невозможно открыть порт» и т. д. Для рядового пользователя – это «сложная» ошибка. Лучше рядом с описанием ошибки писать возможные причины/пути устранения (см. выше).

Не воспринимайте мои комментарии как критику. Это просто совет из личного опыта. Была программа (ориентированная как раз на рядового пользователя), которая требовала от пользователя выбрать ком-порт, к которому подключено устройство. После того как добавили функцию автоматического поиска устройства – количество обращений в тех. поддержку по этому поводу уменьшилось раз в 10-20. Это не панацея, все равно были проблемные моменты, но обращений стало на порядок меньше.
+1
в нашей индустрии ком порты автоматически не принято выбирать,
человек это использующий дожен знать на каком порту висит преобразователь,
а вот тип протокола, объем памяти мк, начальные символы он может и не знать
0
Не буду с Вами спорить — Вы автор, Вам и решать, как должна выглядеть программа.

Просто (ИМХО) для людей «нашей индустрии» GUI интерфейс, в таких случаях, не нужен вообще — лучше интерфейс командной строки (такую программу легче интегрировать в скрипт/IDE). А если писать софт для «пользователей далеких от программирования» — то лучше сделать интерфейс максимально простым (с расчетом на то, что пользователь вообще не знает, что такое ком-порт).
+3
здрасьте…
любой интерфейс лучше чем ацкий ад командной строки ( особливо в моем коннкретном случае)
темпаче что это отдельностоящая софтина
я говорил про пользователей далеких от программирования — а не от компьютера
-3
любой интерфейс лучше чем ацкий ад командной строки ( особливо в моем коннкретном случае)

Зря Вы так, интерфейс командной строки будет жить еще очень долго, т.к. позволяет интегрировать программу в скрипты и т.д. Вот Microsoft тоже долго отрицала необходимость нормального средства управления системой из командной строки. А потом, на радость админам, появился PowerShell. Намного проще один раз написать скрипт и запустит его на нескольких ПК, чем на каждом ПК вручную «прокликивать» кучу окон.
+1
у командной строки свое место — которое вы описали, не спорю — но она для подготовленных людей и которым не лень запоминать все 100500 ключей
я честно признаюсь мне лень :) и в gcc меня вполне устраивает что там напишет студия или кокос.
А по поводу сканирования портов, если имелось ввиду занесение в комбо бокс только активных портов, то это да я собирался делать- чуть позже обязательно добавлю
0
в любом случае спасибо за критику и предложения :)
0
А прошиваемый девайс как подключается? Отдельный UART выведен? Или по RS-485? Но тогда, я так понимаю, девайс должен быть на линии один.
0
  • avatar
  • ACE
  • 06 апреля 2012, 23:44
В общем случае через основной uart RS-485
Девайсу не обязательно быть одному — протоколы загрузки и коммуникации разные остальные тупо ждут запросов
0
А если в прошивке встретится блок, совпадающий с каким-либо запросом? Ну скажем, с модбасом. Совпасть должен только адрес и один байт crc, не такая уж маленькая вероятность. У XModem'а, как я понял, первый байт 0x01 пакета. Значит не должно быть в сети модбас-устройства с адресом 1.
0
нет должно совпасть все+ у модбаса crc на всю посылку здесь на data секцию только
0
Хм, как это всё? Вроде только адрес и CRC, дальше устройство уже попытается интерпретировать код команды, но даже если не поймет, скорее всего ответит ошибкой. CRC у модбаса один байт, у xmodem'а — два, значит и случайные совпадения могут быть.
0
у модбас rtu — два байта
у modbas asc — один
у xmodem check sum — один
у xmodem crc -два
0
да кстати не модбасом единым живет передача данных в BMS
сейчас я использую в основном N2Open (тк основное оборудование его поддерживает), а Modbus для совместимости
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.