Оказалось, что до значения 128($80) все работает как часы, а вот выше 128 и выше приходят вопросы, что делать???? Тут явно visual basic троит, дальше то русские символы должны быть, если учесть ascii. Товарищи знатоки, подскажите в чем соль?!

Когда основной код не большой, скажем просто вывести на LCD 2 строки(смотрю что прилетело в порт), то тут происходит самое интересное. То данные не все прилетают, то часть теряется, то не могу отправить в порт обратно (Hserout или TXREG = ни то ни то не работает), пока не поставлю задержку в 15-100 мс сек в основном коде.

но Xtal = 48

В 18f2550 есть такая фишка! Стоит кварц на 20 МГц, и настройки такие:

Но это не физический кварц (с PLL естественно), а только число для расчета таймингов в компиляторе.

Господа! Еще вопрос назрел. Как правильно принят данные с компорта? Я делал это 2-мя способами и все-равно не нравится. Первый способ: посылаю запрос (modbus), затем жду Application.DoEvents() Threading.Thread.Sleep(30) После читаю что пришло. Потом решил использовать событие по приему данных SerialPort1.ReceivedBytesThreshold = 12 указываю кол-во байт для появления события SerialPort1_DataReceived Оба способа работают, но иногда сбоят. Приходится делать много повторов с запросами. Кто как принимает данные с компа? Спасибо!
Тут вопрос не в железе, так как я мониторил порт. И при запросах ответы летят правильные и вовремя. Я даже использовал заводские модули модбас, результат тот же. Т.е. все работает, но иногда не с первого раза. Объясню, понять все ли пришло помогает двухбайтная контрольная сумма.Когда она совпадает, тогда все ок, если она не совпадает, идет повторный запрос до тех пор пока либо не выйдет максимальное кол–во запросов, либо пока не примет, а счетчик отображает кол–во попыток. Так вот, бывает 1 попытка=1 успешный прием, а бывает и за 3 попытки не может принять, хотя монитор порта говорит, что железка отправила все верно. Создается такое впечатление, что виндовое приложение не все байты хватает.

Читаем мануал anatol

Com port, в операционных системах выше Милениума физически недоступен

а соответственно и передача идет кусками. В соответствии с распределением времени заданном операционкой. Для нас - по случайному закону.

Для правильной работы выставляются флаги ожидания (дополнительные пины порта). Линий у порта (в урезанном варианте) = 9.

А вот в плане "железячники" против программистов - экономия на ногах контроллера приводит к непредсказуемым последствиям. И не надо путать возможность работать по двум линиям, с надежностью и достоверностью передачи данных. Тем более что софт на одной стороне писан не нами, а примочки в виде подпрограмм обработки не совсем адекватно работают в системах реального времени. (Никто не наблюдал зависания указателя мышки? А ведь практически тот же последовательный порт.)

DAlexV, я тоже извиняюсь, но какая длина буфера ФИФО у приемопередатчика RS-232 современного компьютера, и какая максимальная длина "послания" отправляемого вашими поделками. И не стоит ли в применяемом контроллере похожий "железный" порт. Некоторые источники говорят что в среднем 64 байта (было время что и 4 радость). И если не превышаете длину есть вероятность все получить правильно.  Я не против кастрированных портов, однако надо соображать надо, а не сразу в омут головой.