реклама на сайте
подробности

 
 
5 страниц V  « < 2 3 4 5 >  
Reply to this topicStart new topic
> падает скорость на rs232
zltigo
сообщение Aug 25 2009, 14:01
Сообщение #46


Гуру
******

Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244



Цитата(@Ark @ Aug 25 2009, 15:46) *
P.S. Попробуйте на некалиброванном RC-генераторе UART реализовать, в целях экономии...

Не валите в кучу две разных задачи. Подстройка под RC генератор может вообще осуществляться периодически по длительности специально передаваемого Break и соответственно совершенно не быть завязаным на какие-либо протокольные вещи.


--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post
x736C
сообщение Aug 25 2009, 14:09
Сообщение #47


Профессионал
*****

Группа: Участник
Сообщений: 1 273
Регистрация: 3-03-06
Пользователь №: 14 942



Цитата(zltigo @ Aug 25 2009, 18:01) *
Не валите в кучу две разных задачи. Подстройка под RC генератор может вообще осуществляться периодически по длительности специально передаваемого Break и соответственно совершенно не быть завязаным на какие-либо протокольные вещи.

А может быть осуществлена гораздо проще, в рамках процедуры обмена, как и было сделано.

P. S. Попытка с менторским тоном придумать эту разницу уважения к вашему профессионализму, в котором лично у меня не возникает никаких сомнений, не добавляет.
Go to the top of the page
 
+Quote Post
zltigo
сообщение Aug 25 2009, 14:19
Сообщение #48


Гуру
******

Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244



Цитата(x736C @ Aug 25 2009, 16:09) *
А может быть осуществлена гораздо проще, в рамках процедуры обмена, как и было сделано.

При этом налагая ДОПОЛНИТЕЛЬНЫЕ НЕНУЖНЫЕ ограничения на эту самую процедуру, вместо того, что-бы процедура только выбрасывала битые фреймы в ней начинают наворачивать поиск пауз, подсчет фронтов в байте следущим после паузы, протокольные ограничения....
Цитата
Попытка с менторским тоном придумать эту разницу...

Эта разница, простите, совершенно не придумана sad.gif, она объективно есть. Любую задачу можно решить максимально извращенным способом - тут спору нет, но лучше проще. Предки, например, заложили тот-же Break совсем не зря.


--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post
rezident
сообщение Aug 25 2009, 15:07
Сообщение #49


Гуру
******

Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882



Цитата(aaarrr @ Aug 24 2009, 21:56) *
Может, с autobaud'ом перепутали, а?
Скорее уж асинхронный приемопередатчик (UART) с самосинхронизирующимся, использующего что-то типа манчестерского кода.
Go to the top of the page
 
+Quote Post
x736C
сообщение Aug 25 2009, 15:17
Сообщение #50


Профессионал
*****

Группа: Участник
Сообщений: 1 273
Регистрация: 3-03-06
Пользователь №: 14 942



Вы тоже налагаете ограничение в виде постоянной посылки break. Шило на мыло.
Замена одного априорно известного байта, на другой «байт», который надо:
1. отделить от других данный (в том числе на стороне передатчика);
2. измерить тем же счетчиком.
Ну и третье. Так как скорость передачи неизвестна, то как этот break не спутать с нулевым БИ или их комбинацией, следующей на пониженной скорости, мне не ясно.
Опять-таки, в кучу свалено две задачи, калибровка и автоподстройка.

Калибровка RC-генератора при известной скорости передачи не представляется настолько простецкой, чтобы в данном контексте ей пренебрегать.
http://www.atmel.com/dyn/resources/prod_do...nts/doc2563.pdf

Добавить сюда еще autobaud rate — вообще сомнительное предприятие для случая @Ark.

Добавлю: что в предложенном appNote от Atmel к сигналу break добавлен еще байт синхронизации. Разве ж это проще. smile.gif

Так что где изврат — это еще вопрос. smile.gif
С уважением.

Сообщение отредактировал x736C - Aug 25 2009, 15:30
Go to the top of the page
 
+Quote Post
zltigo
сообщение Aug 25 2009, 16:13
Сообщение #51


Гуру
******

Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244



Цитата(x736C @ Aug 25 2009, 17:17) *
Вы тоже налагаете ограничение в виде постоянной посылки break. Шило на мыло.

Это НЕ ограничение на протокол - протокол совершенно ничего не знает о калибровках. Совсем ничего.
Цитата
1. отделить от других данный (в том числе на стороне передатчика);

Это вообще-то не байт совсем. Это с точки зрения приемника битый фрейм, который отделяется, даже если у чипа нет поддержки детектирования break по ошибке фрейма
и выбрасывается.
Цитата
2. измерить тем же счетчиком.

Ну поскольку именно Вы а не я свалили в кучу две задачи и получали уравнение с двумя неизвестными, то для данного случая, да, надо менять.
Цитата
Ну и третье. Так как скорость передачи неизвестна, то как этот break не спутать с нулевым БИ или их комбинацией, следующей на пониженной скорости, мне не ясно.

Все очень просто - break по определению должен быть длиннее самого длинного байта
Цитата
Опять-таки, в кучу свалено две задачи, калибровка и автоподстройка.

Это не я так задачу за уши притянул. Для решения одной из двух задач никакие дополнительные таймера и почие извращения не нужны.


--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post
x736C
сообщение Aug 25 2009, 17:06
Сообщение #52


Профессионал
*****

Группа: Участник
Сообщений: 1 273
Регистрация: 3-03-06
Пользователь №: 14 942



«Break должен быть длиннее самого длинного байта».. Это ли не ограничение на протокол передачи? Длинный break, перекрывающий все возможное, решает проблему калибровки. Но остается необходимость реализовывать отдельно autobaud rate.
(То, что это существует аппаратно где-то и в чем-то отношения к теме не имеет).
Я ничего не сваливал в кучу, вы что-то напутали по ходу наших рассуждений, все было свалено до меня. smile.gif
«Для решения одной из двух задач..» Да кто ж с этим спорит? Только зачем навязывать «простое» решение для задачи, которая перед человеком не стояла. smile.gif
В общем бессмысленный спор, думаю, вы со мной согласитесь хотя бы в этом.
Go to the top of the page
 
+Quote Post
zltigo
сообщение Aug 25 2009, 17:59
Сообщение #53


Гуру
******

Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244



Цитата(x736C @ Aug 25 2009, 19:06) *
«Break должен быть длиннее самого длинного байта».. Это ли не ограничение на протокол передачи?

Повторяю третий и последний раз - протокол передачи НИКАК при этом не ограничивается - ему по барабану есть там break, нет его, и что он там делает или не делает. Break отрабатывает таймер c обработчиком - это исключительно его епархия.
Цитата
Длинный break, перекрывающий все возможное, решает проблему калибровки. Но остается необходимость реализовывать отдельно autobaud rate.

Длинна break и кроме всего прочего и задает baud - получили break, откалибровались по его длительности и вычислили по нему baud на которой с нами хочет общаться master.


--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post
x736C
сообщение Aug 25 2009, 18:55
Сообщение #54


Профессионал
*****

Группа: Участник
Сообщений: 1 273
Регистрация: 3-03-06
Пользователь №: 14 942



Мы уже пошли по кругу.
Если вам надо в линию что-то передавать кроме данных, то это уже ограничение.
Если нужно передавать брейк, который длиннее одного байта (300 бод), то это почти в 400 раза длиннее байта минимально возможной длинны.
То есть протокол должен учитывать тот факт, что на 3,3 мс передача ему будет недоступна.
Передавать брейк на той же скорости, на которой вы планируете передачу, занятие бессмысленное, если приемник не будет ее (эту скорость) знать.
Я вроде понятно излагаю.

«Длинна break и кроме всего прочего и задает baud - получили break, откалибровались по его длительности и вычислили по нему baud на которой с нами хочет общаться master».
Тут я вижу ошибку.
См. выше. Если брейк передается на скорости передатчика, а именно это вы имеете в виду, раз предлагаете по нему подстраивать скорость, то не получится так просто отличить его от данных. Ваша схема может не отличить комбинацию нулей на одной скорости, от сигнала брейк на другой.

Например break на скорости 115200 просто удивительно точно совпадает с 1 нулем на скорости 9600.
То есть байт синхронизации или брейк делиметер тут необходим со всем вытекающим.
Я же говорю, это шило на мыло.
Go to the top of the page
 
+Quote Post
zltigo
сообщение Aug 25 2009, 19:20
Сообщение #55


Гуру
******

Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244



Цитата(x736C @ Aug 25 2009, 20:55) *
Я вроде понятно излагаю.

Разумеется нет - ведомое устройство просто должно изначально ожидать соединения на МАКСИМАЛЬНОЙ скорости. Соответсвенно брейк должен только длиннее предлагаемой "новой" скорости. Посему все Ваши последующие рассуждения ложны.


--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post
Guest_@Ark_*
сообщение Aug 25 2009, 19:28
Сообщение #56





Guests






Во, дискуссия развернулась... smile.gif
Цитата
Не валите в кучу две разных задачи...

Да, я бы рад не валить, но реале они, часто, уже находятся в одной куче... И почему бы это не использовать?
Связать процедуры автоопределения скорости и протокол обмена. Например, предложенная мною методика, достаточно просто и логично вписывается в общеизвестный протокол MODBUS (правда, пока устройство одно на линии). После определения скорости, проверяем контрольную сумму запроса. Если все совпало, то с очень хорошей достоверностью скорость определена правильно. Иначе - не отвечаем и ждем следующего запроса...
Аналогично поступаем в случае сбоев (возможно из-за "ухода" текущего значения частоты RC)...
Самое главное, что абсолютно никаких дополнительных "усилий" со стороны Мастера для реализации автокалибровки в этом случае не требуется. Он даже "не знает" об этом...
Go to the top of the page
 
+Quote Post
SasaVitebsk
сообщение Aug 25 2009, 19:33
Сообщение #57


Гуру
******

Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521



Цитата(x736C @ Aug 25 2009, 16:55) *
«Восстанавливается инфа включая первый байт с вероятностью 98%».
Странно, что вы указываете вероятность успешного приема первого байта, хотя не известна вероятность получения конкретных байт.
Вероятность успешного приема первого байта, имхо, сильно зависит от того, какой это будет байт. Поэтому откуда взята цифра 98% ? smile.gif

Честно говоря так по памяти выдал. Немного ошибся. Сейчас посчитал примерно 95% получается.
Нельзя по первому байту (моим алгоритмом) восстановить следующие байты ff,fe,fc,f8,..,80,00. Короче байты с одним перепадом после старта. Ну и ещё наверное пару байт с 2 перепадами равноширинными. Если модифицировать алгоритм, то можно уменьшить число "неверно детектируемых" байт ещё вдвое. Останутся только ff,fe,f8,80. Если обрабатывать поток непрерывно, либо анализировать возможность ошибки, то можно гарантированно востанавливать поток полностью.

Цитата
Вероятность появления неблагоприятного байта при «случайном» обмене, конечно, можно посчитать, но не думаю, что вы это делали.
@Ark этот вопрос решил просто, сделал её единицей (около того), пожертвовав первым байтом.
И потом, по моему мнению, вы сильно усложнили. Проверять одно, второе, прогнозировать третье. В погоне за этим первым байтом что ли?

Наоборот. Немного упростил. Поленился. Посмотрел, что US Robotics Courier даёт примерно аналогичный результат и успокоился. Но проанализировал, что можно лучше. Зато получил P&P / диагностику под виндой. А народ даже и не догадывается что работает не аппаратный UART. Сбоев никогда не наблюдал. Выпускали несколько лет. smile.gif
Go to the top of the page
 
+Quote Post
x736C
сообщение Aug 25 2009, 19:52
Сообщение #58


Профессионал
*****

Группа: Участник
Сообщений: 1 273
Регистрация: 3-03-06
Пользователь №: 14 942



Как правило наименьший БИ двигает скорость в сторону увеличения, а у вас специальный символ брейк двигает скорость в сторону уменьшения. Это конечно «проще», это конечно «эффективнее».
Обратно как собираетесь скорость возвращать, если она изменится?
Вы с таким упорством пытаетесь доказать, что предложили нечто лучшее, чем реализовал @Ark для тех элементарных требований, которые у него были.
Проще вы это не сделаете так, как описываете. Я вам попытался доказать, но у меня не получилось.

SasaVitebsk, сложно, не значит плохо и я лишь предположил. Я рад за вас, что все работает успешно.
У вас, опять же, видимо была своя задача. Немного не понимаю, почему вы говорите о восстановлении потока. Что-то связано с модем.
95% это очень мало. Скорее всего мы о разном тут говорим.
Если скорость определяется верно, а петля автоподстройки охватывает вероятность появления «неудачных» байт в случайном потоке, то схема автоподстройки должна гарантировать попадание близкое к единице.
Go to the top of the page
 
+Quote Post
zltigo
сообщение Aug 25 2009, 20:03
Сообщение #59


Гуру
******

Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244



Цитата(x736C @ Aug 25 2009, 21:40) *
реализовал @Ark для тех элементарных требований, которые у него были.

Элементарные частные требования были озвучены только в прошлом посте. Я рассуждал и рассуждаю о максимально универсальном независимом и отвязанном от протокола варианте. Частные случаи на то они и частные, что бы позволять применять частные заточенные решения.
Цитата
Проще вы это не сделаете так, как описываете.

Сделаю, легко и просто, ибо максимально тупой алгоритм. Проблем нет и даже из пальца они не высасываются smile.gif.
Цитата
Обратно как собираетесь скорость возвращать, если она изменится?

Что значит "она изменится"? Сама smile.gif Вы вдуг зачем-то захотите прыгнуть по бодовым скоростям вверх процессе работы? Неведомо зачем, но для этого можно, например, подать брейк многократно превыщающий текущюю байтовую длительность и по этом признаку уйти на максимальную, или использовать длительности break не в сетке бодовых скоростей.


--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post
x736C
сообщение Aug 25 2009, 20:04
Сообщение #60


Профессионал
*****

Группа: Участник
Сообщений: 1 273
Регистрация: 3-03-06
Пользователь №: 14 942



Ой, да, мы о разном. smile.gif
Вы о первом байте, а я вообще.
Все понял, пересчитывать за вами не буду. smile.gif
Go to the top of the page
 
+Quote Post

5 страниц V  « < 2 3 4 5 >
Reply to this topicStart new topic
3 чел. читают эту тему (гостей: 3, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 19th July 2025 - 01:11
Рейтинг@Mail.ru


Страница сгенерированна за 0.01502 секунд с 7
ELECTRONIX ©2004-2016