Easyelectronics.ru

Электроника для всех
Текущее время: 01 апр 2020, 14:20

Часовой пояс: UTC + 5 часов



JLCPCB – Прототипы печатных плат за $2/10pcs (Любой цвет!)
Крупнейший производитель печатных плат и прототипов. Более 600000 клиентов и свыше 10000 заказов в день!
Получите скидку на почтовую отправку при первом заказе в JLCPCB!

Начать новую тему Ответить на тему  [ Сообщений: 16 ] 
Автор Сообщение
 Заголовок сообщения: Реализация утилиты для заливки конфигов файлов и прошивки МК
СообщениеДобавлено: 20 авг 2015, 15:46 
Только пришел

Зарегистрирован: 15 дек 2014, 01:18
Сообщения: 11
Необходимо реализовать заливку конфигурационного файла *.txt в микроконтроллер STM32f103 по USB(виртуальный COM порт), а также заливку прошивки через bootloader (но это чуть позже).
Пример конфига:
Код:
ID=678999
SERV0IP=139.74.71.223
SERV0PORT=8000
DrvInput=I 
AD1=voltP

Со стороны ПК необходимо реализовать утилиту которая будет посимвольно передавать данные в МК. И тут вопрос как это реализовать оптимально, я когда-то делал общение ПК и МК но делал это на достаточно простом уровне на Delphi 7, у меня ждал МК от ПК символа «А», после того как он получил он МК принимал ровно 400 байт от ПК и после этого снова переходил в режим приема, для передачи данных из МК в ПК – утилита на ПК (написанная на Delphi) ждала символа «B» и только после этого готова была принимать данные от контроллера так же 400 байт. Ну это как бы вариант передачи данных между ПК и МК очень ограниченный и ненадежный, и там я не делал проверок CRC.
Я знаю, что есть протоколы обмена данными такие как XModem, YModem и ZModem но опытна работы с ними не имею, вроде как пишут что есть еще сетевой протокол Telnet.
Подскажите мне какой будет лучший, оптимальный или более правильный способ реализация утилиты на ПК передачи данных и протокол передачи, а также реализация приема данных со стороны микроконтроллера.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация утилиты для заливки конфигов файлов и прошивки МК
СообщениеДобавлено: 21 авг 2015, 14:44 
Старожил
Аватара пользователя

Зарегистрирован: 23 янв 2012, 00:31
Сообщения: 1797
Откуда: Новокузнецк
2Geryhold, у вас путаница в уровнях протоколов.
Есть у вас виртуальный Компорт, что по сути является потоком: что в него засунешь, то с другой стороны вылезет. Это базовый уровень связи, который широко используется. Но использовать его в таком сыром виде проблематично: поток не позволяет отлавливать начало и конец пакета. Поэтому нужно пойти дальше и наложить на это поточное соединение какой-нибудь протокол, который бы позволил нам передавать осознанные данные. К примеру изобразим пакетную передачу данных. Пакет - набор данных фиксированной известной величины, полученной от передающего устройства. Рисуем примерный состав пакета: стартовый байт, длина пакета, данные, crc. Ну или чуть-чуть по другому. На этом уровне нам нужно решить следующие задачи
1. Детектировать начало и конец пакета.
2. Определить длину полученного пакета.
3. Удостовериться в корректности и целостности полученных данных (опционально, если поток не проверяется на нижнем уровне).
В итоге с этим уровнем протокола мы имеем возможность отправить и получить массив байт любой длины, не больше максимальной. Так же этот уровень можно озадачить заниматься контролем доставки пакетов, повторной отправкой, в случае их утери, отброса дубликатов. Программа должна сама искать начало и конец пакета, проверять контрольную сумму и т.д. Со стороны пользователя вся работа на этом уровне должна заключаться грубо говоря в двух функциях: отправить массив и получить массив.

Дальше на это накладываем еще один уровень протокола, который позволит непосредственно передавать осознанные данные. Для этого создадим шаблон сообщений, которые будем передавать как массив байт: номер команды, данные команды. Допустим, чтобы записать ID в устройство, отправим ему такую команду: "1 678999", где 1 - это номер команды, которая означает "записать ID". И так далее. На этом уровне программа должна сама формировать буферы данных, которые она будет отправлять с помощью протокола низкого уровня. А со стороны пользователя будут функции только: записать ID, прочитать ID, записать адресс и т.д.

Это я описал простейшее взаимодействие с малым количеством уровней.
На примере сказанного выше, поясняю, что XModem, YModem и ZModem это протокол, которому нужен только поток, и он обеспечит передачу файлов. Тоесть он выполнит первый уровень описанного мной (он передает пакеты данных методом запроса ответа с проверкой целостности, доставкой и прочее) и второй (он обеспечивает некую осознаную функциональность, а именно передача файла).
Telnet - это поток. Что в него засунешь, то вылезет с другой стороны. Но поток через сети, а именно он использует TCP протокол. То есть он уровнем ниже. Можно смело на Telnet натянуть XModem, и ты сможешь передавать файлы по сети. А можешь натянуть XModem на свой виртуальный компорт, и передавать файлы по USB.

Как я понял задачу, тебе не нужен Xmodem, а тебе нужно нечто, что я описал выше.

_________________
elisey.su


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация утилиты для заливки конфигов файлов и прошивки МК
СообщениеДобавлено: 21 авг 2015, 14:49 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2533
Не надо никакой утилиты на ПК
Все уже сделано.

Armada. Setting using the ini-file.
http://www.youtube.com/watch?v=ek5hUZ6xgBQ

Armada. Set bluetooth from ini-file
http://www.youtube.com/watch?v=X49ddlxmaQg

ARMada. USB mass storage+SD card
http://www.youtube.com/watch?v=69mH1rcADbs

Lasertag device Armada. USB mass storage and bootload
http://www.youtube.com/watch?v=TQTxgvxeS2Q


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация утилиты для заливки конфигов файлов и прошивки МК
СообщениеДобавлено: 24 авг 2015, 01:09 
Только пришел

Зарегистрирован: 15 дек 2014, 01:18
Сообщения: 11
elisey писал(а):
2Geryhold, у вас путаница в уровнях протоколов.
Есть у вас виртуальный Компорт, что по сути является потоком: что в него засунешь, то с другой стороны вылезет. Это базовый уровень связи, который широко используется. Но использовать его в таком сыром виде проблематично: поток не позволяет отлавливать начало и конец пакета. Поэтому нужно пойти дальше и наложить на это поточное соединение какой-нибудь протокол, который бы позволил нам передавать осознанные данные. К примеру изобразим пакетную передачу данных. Пакет - набор данных фиксированной известной величины, полученной от передающего устройства. Рисуем примерный состав пакета: стартовый байт, длина пакета, данные, crc. Ну или чуть-чуть по другому. На этом уровне нам нужно решить следующие задачи
1. Детектировать начало и конец пакета.
2. Определить длину полученного пакета.
3. Удостовериться в корректности и целостности полученных данных (опционально, если поток не проверяется на нижнем уровне).
В итоге с этим уровнем протокола мы имеем возможность отправить и получить массив байт любой длины, не больше максимальной. Так же этот уровень можно озадачить заниматься контролем доставки пакетов, повторной отправкой, в случае их утери, отброса дубликатов. Программа должна сама искать начало и конец пакета, проверять контрольную сумму и т.д. Со стороны пользователя вся работа на этом уровне должна заключаться грубо говоря в двух функциях: отправить массив и получить массив.

Дальше на это накладываем еще один уровень протокола, который позволит непосредственно передавать осознанные данные. Для этого создадим шаблон сообщений, которые будем передавать как массив байт: номер команды, данные команды. Допустим, чтобы записать ID в устройство, отправим ему такую команду: "1 678999", где 1 - это номер команды, которая означает "записать ID". И так далее. На этом уровне программа должна сама формировать буферы данных, которые она будет отправлять с помощью протокола низкого уровня. А со стороны пользователя будут функции только: записать ID, прочитать ID, записать адресс и т.д.

Это я описал простейшее взаимодействие с малым количеством уровней.
На примере сказанного выше, поясняю, что XModem, YModem и ZModem это протокол, которому нужен только поток, и он обеспечит передачу файлов. Тоесть он выполнит первый уровень описанного мной (он передает пакеты данных методом запроса ответа с проверкой целостности, доставкой и прочее) и второй (он обеспечивает некую осознаную функциональность, а именно передача файла).
Telnet - это поток. Что в него засунешь, то вылезет с другой стороны. Но поток через сети, а именно он использует TCP протокол. То есть он уровнем ниже. Можно смело на Telnet натянуть XModem, и ты сможешь передавать файлы по сети. А можешь натянуть XModem на свой виртуальный компорт, и передавать файлы по USB.

Как я понял задачу, тебе не нужен Xmodem, а тебе нужно нечто, что я описал выше.


Спасибо за достаточно понятный и хороший ответ. Думаю для меня будет приемлемый вариант - остановиться на Виртуальный COM-порт STM32F103 с натянутым сверху XModem`ым протоколам. Но вот тут хотел посоветоваться - смотрите Virtual Com port по USB может принимать до 64 байта(это значение может быть меньше), а исходя из протокола XModem идет SOH(спец символ 0x01) + 01FE (номер пакета) + 128 байт(данные) + 0xXX(crc проверка) итого имеем 132 байта, ну и как это правильно разделить в пачках виртуального COM порта, или модифицировать XModem протокол, скажем уменьшить размер данных до 60?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация утилиты для заливки конфигов файлов и прошивки МК
СообщениеДобавлено: 24 авг 2015, 12:13 
Старожил
Аватара пользователя

Зарегистрирован: 23 янв 2012, 00:31
Сообщения: 1797
Откуда: Новокузнецк
Geryhold писал(а):
Спасибо за достаточно понятный и хороший ответ. Думаю для меня будет приемлемый вариант - остановиться на Виртуальный COM-порт STM32F103 с натянутым сверху XModem`ым протоколам. Но вот тут хотел посоветоваться - смотрите Virtual Com port по USB может принимать до 64 байта(это значение может быть меньше), а исходя из протокола XModem идет SOH(спец символ 0x01) + 01FE (номер пакета) + 128 байт(данные) + 0xXX(crc проверка) итого имеем 132 байта, ну и как это правильно разделить в пачках виртуального COM порта, или модифицировать XModem протокол, скажем уменьшить размер данных до 60?

64 байта которыми оперирует виртуальный компорт, это его внутреннее устройство, которое не нужно принимать в рассмотрение. С точки зрения использования, нужно воспринимать его как поточное устройство, которое не оперирует пакетами: байт засунули - байт вылез с другой стороны. Единственное, что будет некоторая буферизация в эти 64 байта, а следовательно байты будут приходить пачками, но протокол более высокого уровня (XModem) все равно должен относиться к своему каналу, как к поточному интерфейсу.
Кстати у ST есть аппноут - реализация бутлоадера. Там заливка прошивки производится как раз по протоколу YModem. Вот тут можно исходники скачать. Там файлы ymodem.h и ymodem.c.
Для заливки файла со стороны компа можно пользоваться утилитой hyperterminal, которая встроена в винду. Она умеет работать с этими протоколами. Если под линуксом, то там выбор еще больше.

_________________
elisey.su


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация утилиты для заливки конфигов файлов и прошивки МК
СообщениеДобавлено: 24 авг 2015, 18:54 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2533
Чего вы паритесь с этими XYZ-модемами?
Шлите сразу hex-файл, он имеет текстовый формат, с символами окончания строки и контрольными суммами каждой строки.
Мой бутлоадер считывает его с SD карты, проверяет CRC и шьёт.
Банально все.

Уж коли на то пошло - есть готовые бутлоадеры (есть статья на этом ресурсе), использующие mass storage.
Кидаете файл как на обычную флешку.
Зачем велосипеды изобретать?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация утилиты для заливки конфигов файлов и прошивки МК
СообщениеДобавлено: 24 авг 2015, 19:38 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2533
Как бы сделал я?
Реализовал бы консольные команды
на присвоение
ID=678999
SERV0IP=139.74.71.223
SERV0PORT=8000
DrvInput=I
AD1=voltP

на чтение

ID?
SERV0IP?
SERV0PORT?
DrvInput?
AD1?

То есть, чтобы задать ID набираем в терминале
ID=XXXXXX\r\n
в ответ либо
OK \r\n
либо, если ошибка
ERROR: описание ошибки\r\n

Чтобы посмотреть параметр
ID?\r\n
В ответ
XXXXXX\r\n
OK\r\n

Описал бы структуру со всеми нужными полями
При выполнении команд заполнял бы эту структуру значениями.
Выделил бы в конце флеша страницу памяти для хранения этой структуры и по команде
save\r\n
Копировал бы структуру с параметрами из оперативки во флеш.
При старте заполнял бы структуру в опретивке из флеша.
Тут работы на день-другой.

Какой файл?
У Вас будет файловая система во флеше?
Какие модемы?!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация утилиты для заливки конфигов файлов и прошивки МК
СообщениеДобавлено: 24 авг 2015, 23:14 
Старожил
Аватара пользователя

Зарегистрирован: 23 янв 2012, 00:31
Сообщения: 1797
Откуда: Новокузнецк
Pingvin писал(а):
Как бы сделал я?

да я вот тоже самое предлагал первым постом.
Pingvin писал(а):
Какие модемы?!
xmodem к модему имеет отношение только в том, что протокол такой старый, что с его помощью файлы кидали, когда модемы были. А по сути тот же самый механизм, описанный вами выше: стартовый байт, блок файла с CRC, подтверждение, блок файла с CRC, подтверждение, стоповый байт.

_________________
elisey.su


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация утилиты для заливки конфигов файлов и прошивки МК
СообщениеДобавлено: 26 авг 2015, 14:22 
Только пришел

Зарегистрирован: 15 дек 2014, 01:18
Сообщения: 11
Pingvin писал(а):
Чего вы паритесь с этими XYZ-модемами?
Шлите сразу hex-файл, он имеет текстовый формат, с символами окончания строки и контрольными суммами каждой строки.
Мой бутлоадер считывает его с SD карты, проверяет CRC и шьёт.
Банально все.

Уж коли на то пошло - есть готовые бутлоадеры (есть статья на этом ресурсе), использующие mass storage.
Кидаете файл как на обычную флешку.
Зачем велосипеды изобретать?


И что мне тхт файл преобразовывать в hex? и потом со стороны контроллера все равно нужно организовывать прием файлов, проверку CRC.
Тут задача привязаться к чему-то стандартному.

elisey писал(а):
Geryhold писал(а):
Спасибо за достаточно понятный и хороший ответ. Думаю для меня будет приемлемый вариант - остановиться на Виртуальный COM-порт STM32F103 с натянутым сверху XModem`ым протоколам. Но вот тут хотел посоветоваться - смотрите Virtual Com port по USB может принимать до 64 байта(это значение может быть меньше), а исходя из протокола XModem идет SOH(спец символ 0x01) + 01FE (номер пакета) + 128 байт(данные) + 0xXX(crc проверка) итого имеем 132 байта, ну и как это правильно разделить в пачках виртуального COM порта, или модифицировать XModem протокол, скажем уменьшить размер данных до 60?

64 байта которыми оперирует виртуальный компорт, это его внутреннее устройство, которое не нужно принимать в рассмотрение. С точки зрения использования, нужно воспринимать его как поточное устройство, которое не оперирует пакетами: байт засунули - байт вылез с другой стороны. Единственное, что будет некоторая буферизация в эти 64 байта, а следовательно байты будут приходить пачками, но протокол более высокого уровня (XModem) все равно должен относиться к своему каналу, как к поточному интерфейсу.
Кстати у ST есть аппноут - реализация бутлоадера. Там заливка прошивки производится как раз по протоколу YModem. Вот тут можно исходники скачать. Там файлы ymodem.h и ymodem.c.
Для заливки файла со стороны компа можно пользоваться утилитой hyperterminal, которая встроена в винду. Она умеет работать с этими протоколами. Если под линуксом, то там выбор еще больше.


Спасибо за подсказку нашел пример от ST STM32F10xxx in-application programming using the USART (AN2557) заливка прошивки по протоколу YModem вот как раз и возьму за основу, для прошивки контроллеров и для конфигов.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация утилиты для заливки конфигов файлов и прошивки МК
СообщениеДобавлено: 26 авг 2015, 14:31 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2533
Цитата:
И что мне тхт файл преобразовывать в hex? и потом со стороны контроллера все равно нужно организовывать прием файлов, проверку CRC.
Тут задача привязаться к чему-то стандартному.


Шутку не оценил.
Он (hex - файл) уже в текстовом формате!

Попробуйте через Y-модем.

COM-порты вышли из моды, кстати...

А где исходники этой хрени?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация утилиты для заливки конфигов файлов и прошивки МК
СообщениеДобавлено: 26 авг 2015, 14:45 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2533
Так, Господи - по COM порту и встроенный загрузчик может прошить!
Уж куда стандартней то!
Что Вы мне голову морочите?! :-))


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация утилиты для заливки конфигов файлов и прошивки МК
СообщениеДобавлено: 26 авг 2015, 20:41 
Старожил
Аватара пользователя

Зарегистрирован: 23 янв 2012, 00:31
Сообщения: 1797
Откуда: Новокузнецк
Pingvin писал(а):
COM-порты вышли из моды, кстати...
Компорты да, последовательные интерфейсы нет. Вся пачка в том, что без разницы, через какой интерфейс гнать поток. Можно по радиоканалу это делать, можно по rs485, можно в TCP сокет даже завернуть. И на любом интерфейсе нужно просто реализовать передачу потока, а высокоуровневый протокол будет один и тот же.

Я вообще считаю, что автору не нужно передавать файлы. Я применял ymodem для передачи файлов по сети. Причем физика сети разная: rs422 и радио на nrf24. Для общения между собой устройства использовали аналог сокетов. Вот с помощью этого заливаются прошивки, обновляется музыка и конфиги.

Pingvin писал(а):
Так, Господи - по COM порту и встроенный загрузчик может прошить!
Уж куда стандартней то!
Что Вы мне голову морочите?! :-))
через встроенный не поконфигурируешь нормально.

_________________
elisey.su


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация утилиты для заливки конфигов файлов и прошивки МК
СообщениеДобавлено: 26 авг 2015, 20:47 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2533
Ну удачи ТС!
Любопытно будет посмотреть на результаты.
И трудозатраты интересны...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация утилиты для заливки конфигов файлов и прошивки МК
СообщениеДобавлено: 26 авг 2015, 20:48 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2533
В чем проблема конфигурить консольными командами?
Где будет храниться ini-файл?

И где всё же исходники Y-модема найти?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация утилиты для заливки конфигов файлов и прошивки МК
СообщениеДобавлено: 26 авг 2015, 21:13 
Старожил
Аватара пользователя

Зарегистрирован: 23 янв 2012, 00:31
Сообщения: 1797
Откуда: Новокузнецк
Pingvin писал(а):
В чем проблема конфигурить консольными командами?
Где будет храниться ini-файл?

И где всё же исходники Y-модема найти?

А нет проблем. Это просто чуть другой способ. из удобств - легко накатить новый конфиг, снять текущий конфиг с устройства. Юзерфрендли. Файл хранить в памяти. Необязательно даже хранить именно ini файл. Входящий можно парсить на ходу по строчкам. Исходящий - генерировать на ходу. Если даже посмотреть шире, то ini файл и не отличается от консоли. Тот же самый текст:
Код:
параметр значение\r\n
параметр значение\r\n
параметр значение\r\n

Даже при консольном конфигурировании, вместо набивания команд ручками, сувать туда файл.
исходники тут есть. Там ничего интересного: отправили запрос, получили ответ, отправили блок, получили подтверждение. И так далее.

_________________
elisey.su


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Реализация утилиты для заливки конфигов файлов и прошивки МК
СообщениеДобавлено: 26 авг 2015, 23:04 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2533
elisey писал(а):
Pingvin писал(а):
В чем проблема конфигурить консольными командами?
Где будет храниться ini-файл?

И где всё же исходники Y-модема найти?

А нет проблем. Это просто чуть другой способ. из удобств - легко накатить новый конфиг, снять текущий конфиг с устройства. Юзерфрендли. Файл хранить в памяти. Необязательно даже хранить именно ini файл. Входящий можно парсить на ходу по строчкам. Исходящий - генерировать на ходу. Если даже посмотреть шире, то ini файл и не отличается от консоли. Тот же самый текст:
Код:
параметр значение\r\n
параметр значение\r\n
параметр значение\r\n

Даже при консольном конфигурировании, вместо набивания команд ручками, сувать туда файл.
исходники тут есть. Там ничего интересного: отправили запрос, получили ответ, отправили блок, получили подтверждение. И так далее.

так у меня то же самое
Armada. Set bluetooth from ini-file
http://www.youtube.com/watch?v=X49ddlxmaQg

Но у меня SD карта и режим mass storage, нет нужды консоль мучить

Спасибо за исходники!
Вдруг пригодятся.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 16 ] 


Часовой пояс: UTC + 5 часов


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB