падает скорость на rs232 Опции

[borischi]

здравствуйте!
Такая проблема-использую АТ89S52 для чтения информации с мобильника (эрик т28).На коротких посылках всё нормально а свыше 13-15 байт-не успеваю вычитывать похоже.Допустим посылка из 30 байт-меня в ней интересует 25-й для проверки и я в него не попадаю.Если чуть опережаю события(на один вызов getch меньше)-удается попасть в нужный байт-но это ж не дело.
В терминальной программе эрик выдает всё как надо.Уровни его на интерфейсе до 5 вольт подтянул.
Может кто сталкивался с подобным-буду очень благодарен за совет

[x736C]

SasaVitebsk, человек вообще-то мне оппонировал.

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

И потом, по моему мнению, вы сильно усложнили. Проверять одно, второе, прогнозировать третье. В погоне за этим первым байтом что ли?

Сообщение отредактировал x736C - Aug 25 2009, 13:57

[SasaVitebsk]

«Восстанавливается инфа включая первый байт с вероятностью 98%».
Странно, что вы указываете вероятность успешного приема первого байта, хотя не известна вероятность получения конкретных байт.
Вероятность успешного приема первого байта, имхо, сильно зависит от того, какой это будет байт. Поэтому откуда взята цифра 98% ?

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

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

Наоборот. Немного упростил. Поленился. Посмотрел, что US Robotics Courier даёт примерно аналогичный результат и успокоился. Но проанализировал, что можно лучше. Зато получил P&P / диагностику под виндой. А народ даже и не догадывается что работает не аппаратный UART. Сбоев никогда не наблюдал. Выпускали несколько лет.