здравствуйте.
задача связать данные mcu с PC через ком порт
тип передачи -полудуплекс
поделитесь пожалуйста опытом использования протоколов.
Полная версия этой страницы: протоколы передачи данных через Uart
А что за данные, скорость и т.д? Раз ничего не указано предложу текстовый. Отлично воспринимается человеком и удобен при отладке/сопряжении скриптов на PC с железом.
Цитата(Kabdim @ Jul 8 2016, 12:03) 
А что за данные, скорость и т.д? Раз ничего не указано предложу текстовый. Отлично воспринимается человеком и удобен при отладке/сопряжении скриптов на PC с железом.
скорости стандартные для com порта, данные необходимо передавать частями по 64 -128 бит тип данных не текстовый а данны АЦП
Цитата(winniethepooh @ Jul 8 2016, 08:10)
скорости стандартные для com порта, данные необходимо передавать частями по 64 -128 бит тип данных не текстовый а данны АЦП
Modbus, например.
Цитата(Aleksandr Baranov @ Jul 8 2016, 15:14)
Modbus, например.
Да-да, отлично подходит для 128 бит данных и конфигурации точка-точка.
ТС, придумайте свой протокол, заверните в SLIP - и будет счастье.
Контроль целостности данных сделать по NMEA - подбному принципу:
$GPMDS,1,0,4245454630303239200000000015002B3F4D761B000010000303040042555242*
6C
$GPMDS,1,0,555200ABCDEF*60
$GPMDS,2,0*4F
$GPMDS,1,0,4245454630303239200000000015002B3F4D761B000010000303040042555242*
6C
$GPMDS,1,0,555200ABCDEF*60
$GPMDS,2,0*4F
Цитата(aaarrr @ Jul 8 2016, 12:19)
Да-да, отлично подходит для 128 бит данных и конфигурации точка-точка.
ТС, придумайте свой протокол, заверните в SLIP - и будет счастье.
ТС, придумайте свой протокол, заверните в SLIP - и будет счастье.
Придумать свой здорово, но лучше готовый код найти и для PC- ки тоже...
Цитата(winniethepooh @ Jul 8 2016, 15:01)
задача связать данные mcu с PC через ком порт
Так все таки , COM порт или Virtual COM port?
Цитата(winniethepooh @ Jul 8 2016, 16:01)
поделитесь пожалуйста опытом использования протоколов.
Почитайте форум. Это кладезь опыта.
Цитата(AlexandrY @ Jul 8 2016, 12:42)
Так все таки , COM порт или Virtual COM port?
com портом
Цитата(mcheb @ Jul 8 2016, 12:53)
Почитайте форум. Это кладезь опыта.
да конечно кладезь. дочитал до 40 страницы, но пока без результата.., ну спасибо! буду искать дальше. и хорошего настроения!
Цитата(AlexandrY @ Jul 8 2016, 08:42)
Так все таки , COM порт или Virtual COM port?
А какая разница-то?
Детали реализации USB задают оптимальный способ использования VCOMа.
Цитата(pitt @ Jul 8 2016, 16:17)
А какая разница-то?
Задержки при 2х стороннем обмене, фрагментация в усб драйвере и еще мелкие нюансы, которых нет в реальном уарте...
По теме - в таких простейших случаях использую hex-передачу, т.е. код 0 передаю как 00 (в ASCII коде) 255 - как FF.
прием аналогичен, все символы, кроме диапазона 0-F - ошибка. Конец строки - 0x0A или 0D.
Цитата(mantech @ Jul 8 2016, 18:28)
Задержки при 2х стороннем обмене, фрагментация в усб драйвере и еще мелкие нюансы, которых нет в реальном уарте...
По теме - в таких простейших случаях использую hex-передачу, т.е. код 0 передаю как 00 (в ASCII коде) 255 - как FF.
прием аналогичен, все символы, кроме диапазона 0-F - ошибка. Конец строки - 0x0A или 0D.
По теме - в таких простейших случаях использую hex-передачу, т.е. код 0 передаю как 00 (в ASCII коде) 255 - как FF.
прием аналогичен, все символы, кроме диапазона 0-F - ошибка. Конец строки - 0x0A или 0D.
Вы пишите о мелких нюансах реализации виртуального COM-порта, а с другой стороны считаете возможным передавать данные простейшим потоком, который и протоколом то назвать язык не поворачивается.
Считаю обязательным и по крайней мере очень желательным:
1. Забыть о передаче данных без защиты хотя бы двухбайтной CRC.
2. Не заморачиваться с отдельными реализациями протоколов для Fullduplex и Halfduplex. Всегда есть большая вероятность, что понадобится использовать RS485 или другой полудуплексный интерфейс.
3. Если нет опыта в реализации, то лучше сразу смотрите в сторону стандартного протокола, например Modbus RTU. Избежите детских проблем при разработке своего протокола и не понадобится клиентам/партнерам/коллегам объяснять преимущества своего уникального протокола.
4. Ну а если всё же решите пройти по пути создания своего протокола, рекомендую прочитать про SLIP (как уже советовали), а также поиметь хотя бы малейшее представление о уровнях взаимодействия открытых систем, классификации, которая лежит в основе любых обменов данными.
Цитата(amiller @ Jul 8 2016, 14:58)
Вы пишите о мелких нюансах реализации виртуального COM-порта, а с другой стороны считаете возможным передавать данные простейшим потоком, который и протоколом то назвать язык не поворачивается.
Считаю обязательным и по крайней мере очень желательным:
1. Забыть о передаче данных без защиты хотя бы двухбайтной CRC.
2. Не заморачиваться с отдельными реализациями протоколов для Fullduplex и Halfduplex. Всегда есть большая вероятность, что понадобится использовать RS485 или другой полудуплексный интерфейс.
3. Если нет опыта в реализации, то лучше сразу смотрите в сторону стандартного протокола, например Modbus RTU. Избежите детских проблем при разработке своего протокола и не понадобится клиентам/партнерам/коллегам объяснять преимущества своего уникального протокола.
4. Ну а если всё же решите пройти по пути создания своего протокола, рекомендую прочитать про SLIP (как уже советовали), а также поиметь хотя бы малейшее представление о уровнях взаимодействия открытых систем, классификации, которая лежит в основе любых обменов данными.
Считаю обязательным и по крайней мере очень желательным:
1. Забыть о передаче данных без защиты хотя бы двухбайтной CRC.
2. Не заморачиваться с отдельными реализациями протоколов для Fullduplex и Halfduplex. Всегда есть большая вероятность, что понадобится использовать RS485 или другой полудуплексный интерфейс.
3. Если нет опыта в реализации, то лучше сразу смотрите в сторону стандартного протокола, например Modbus RTU. Избежите детских проблем при разработке своего протокола и не понадобится клиентам/партнерам/коллегам объяснять преимущества своего уникального протокола.
4. Ну а если всё же решите пройти по пути создания своего протокола, рекомендую прочитать про SLIP (как уже советовали), а также поиметь хотя бы малейшее представление о уровнях взаимодействия открытых систем, классификации, которая лежит в основе любых обменов данными.
спасибо
Цитата(mantech @ Jul 8 2016, 14:28)
Задержки при 2х стороннем обмене, фрагментация в усб драйвере и еще мелкие нюансы, которых нет в реальном уарте...
По теме - в таких простейших случаях использую hex-передачу, т.е. код 0 передаю как 00 (в ASCII коде) 255 - как FF.
прием аналогичен, все символы, кроме диапазона 0-F - ошибка. Конец строки - 0x0A или 0D.
По теме - в таких простейших случаях использую hex-передачу, т.е. код 0 передаю как 00 (в ASCII коде) 255 - как FF.
прием аналогичен, все символы, кроме диапазона 0-F - ошибка. Конец строки - 0x0A или 0D.
в случае "hex-передачи" есть ли разница с программным flow control X-ON / X-OFF ?
Overengineering как он есть.
Уже были подобные обсуждения, посмотрите эти темы:
http://electronix.ru/forum/index.php?showtopic=132660
http://electronix.ru/forum/index.php?showtopic=130550
http://electronix.ru/forum/index.php?showtopic=132660
http://electronix.ru/forum/index.php?showtopic=130550
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.