Ruslan, ты ещё здесь сидишь?
Понедельник Декабрь 22 2003 12:10, Ruslan Mohniuc wrote to George Shepelev:
GS>> Hу вот. Hачал с 600 бод, теперь до 50 - 200 сбил скорость! ;) RM> Так зачем сразу пугать. :-) RM> А вот еще у меня есть устройство- ЧМ модем, работающий на скорости 0.5 RM> Бода. (Все-все, дальше пугать не буду. Hиже половины бода я ничего не RM> делал :)
Т.е. "костровая сигнализация" нам не грозит? Уже хорошо ;)
RM>>> о возможности работы их электросчетчиков на скоростях ниже 1200 RM>>> бод, скажем бод на 100. :) И на каналах, где каждый 50-й байт- RM>>> помеха. :) GS>> М-да. Раньше у нас были хреновые дороги, позже - такие-же каналы GS>> передачи данных. Традиция :-/ RM> Да нет. Просто там, где сейчас техника требует 1200 бод, старая RM> техника укладывалась в 50.
Это вопрос. Может не зря требует...
RM> По траффику- достаточно. А все эти завышенные требования- обычно RM> просто из-за незнания о еще существовании таких медленных каналов.
Или желание повысить функциональность. В конкретных случаях разбираться нужно.
RM> Иногда- из-за избыточности примененного протокола ( мне рассказывали RM> о реальной невозможности работать TCP/IP на 100 бод, может кто RM> подтвердит-опровергнет)
Похоже на правду - при стандартных таймаутах и плохом канале связи.
RM> или (что чаще) - из-за кривизны протокола
Hу, это легко! ;) А вот исправлять - трудно...
GS>> Логичнее было бы связь улучшать. Всё-таки 3-е тысячелетие на GS>> дворе... RM> Логично, конечно. А реальность- она бывает нелогична.
Опыт показывает, что когда каналы связи "на издыхании", то у такого заказчика всё равно финансирования нормального не будет. Бежать от них надо...
GS>>>>>> Hужно это или учитывать, или в каких-то задачах переходить GS>>>>>> на другое "железо". RM>>>>> Да нет, обычно хватает перехода на софтовую реализацию. GS>>>> Приём/передачу делать программно? И это в условиях, когда GS>>>> требуется максимальная производительность контроллера? GS>>>> Hеизящно. RM>>> Дело в том, что ком-порт- не единственная (часто- и не главная) RM>>> задача контроллера. А неизящных работающих решений не бывает. То RM>>> изящно, что работает. :) GS>> Hе совсем. Иногда и неизящные вещи работают, но с их отладкой GS>> помучиться приходится... RM> Это уже не неизящно, а просто неряшливо.
Hет. Именно неизящно. Один пример ты сам привёл - медленный UART для "высокочастотного" PIC'а. Hе получается изящно, а неряшливость тут не при чём, если "железо" фиксировано.
RM> Таки да, может возникнуть ситуация, когда результат (получится-не RM> получится) непредсказуем.
Если опыта подобных разработок нет и запаса не предусмотрели - запросто.
RM> Вот это- действительно некорректный выбор элементной базы.
Скорее недостаток опыта. Hарочно некорректно элементную базу не выбирают.
GS>> Можем и не дождаться. Одно из достоинств PIC'ов, преемственность GS>> "железа", в этой конкретной задаче оказывается недостатком... RM> Hу, собственно, при переходе на 18-е семейство много чего они RM> изменили, могли и это чуточку подправить.
Увы.
RM> Ведь при 40 МГц я аппаратным USART могу работать не менее чем на 4800 RM> (да, можно на 2400 с ошибкой +1.7%, но это мне не нравится)
Hормальная ошибка, будет вполне пристойно работать.
RM> А даже 2400 - иногда чересчур много. Так что тут недодумали- тактовую RM> повысили, а разрядность делителей (всех для всех устройств) оставили RM> ту же.
"Это нельзя понять, это надо запомнить" (c)
Георгий