Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: modbus поверх bluetooth
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Программирование
Zelepuk
Собираюсь организовать передачу данных по каналу bluetooth. Встал выбор реализации уровня приложения. Modbus подойдет?
_Pasha
Цитата(Zelepuk @ Feb 16 2014, 10:18) *
Modbus подойдет?

Привет.
Вопрос сферический, потому что неизвестно важное свойство сети - одномастерная или мульти-
Zelepuk
Цитата(_Pasha @ Feb 16 2014, 12:11) *
Привет.
Вопрос сферический, потому что неизвестно важное свойство сети - одномастерная или мульти-

Предполагается передача данных от устройства к телефону. Одно устройстово - один телефон
umup
будет работать конечно, только придется выбросить байтовые тайм-ауты и прочую хр"нь.
Dog Pawlowa
Цитата(umup @ Feb 16 2014, 12:16) *
только придется выбросить байтовые тайм-ауты

если применить MODBUS ASCII, не придется ничего выбрасывать
umup
Цитата
если применить MODBUS ASCII, не придется ничего выбрасывать
RTU тоже работает, проверено с разными мастерами, в т.ч. с сайта разработчика протокола.
тайм-ауты 1.5 и 3.5 байта давно нигде не учитываются, тем более на ПК это невозможно, все рекомендуют контролировать общий тайм-аут приемника 10..100мс.
Dog Pawlowa
Цитата(umup @ Feb 16 2014, 16:33) *
RTU тоже работает...
общий тайм-аут приемника 10..100мс.

Только это уже человек, похожий на генерального прокурора протокол, похожий на RTU, но не MODBUS RTU wink.gif
umup
ну да, расскажите это Lantronix, Siemens, 3S-Smart, Simatic
_Pasha
Цитата(umup @ Feb 16 2014, 18:05) *
ну да, расскажите это Lantronix, Siemens, 3S-Smart, Simatic

Дык они исторически - убийцы модбаса, чего их спрашивать? sm.gif
Я вот считаю ASCII самое то, RTU фтопку. Честное пионэрское.
Можете еще pc-host попробовать или SLIP, есичо
umup
Цитата
Дык они исторически - убийцы модбаса, чего их спрашивать?
просто в некоторых даташитах прямо рекомендуют во избежание проблем использовать тайм-аут приема 50..100мс, на другие условия типа 3.5byte забить т.к. на обычных ПК между байтами могут быть разрывы в несколько мс.
Цитата
Я вот считаю ASCII самое то
кмк LRC слабоват, особенно для длинных пакетов.
и оверхед 100%, для мелких контроллеров может мешать.
_Pasha
Цитата(umup @ Feb 17 2014, 00:58) *
кмк LRC слабоват, особенно для длинных пакетов.
и оверхед 100%, для мелких контроллеров может мешать.

Хехе sm.gif
Контроль четности + избыточность по символам как раз LRC оправдывают.
А оверхед по памяти? Нафига, если можно прямо в прерывании переводить в байты и обратно? Как раз-таки чем мне импонирует - что не надо ресурсы цеплять на относительно быстрые таймауты.
Вообще-то SLIP конечно круче, но над ним надо свой пакетный уровень делать. И RTU туда не завернешь, помешает CRC16, потому что стаффинг там и будет болтаться без сигнатуры.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.