Кто нибудь писал в CCS интерфейс со скоростью 230400? Это вообще реально?

Тип компилятора тут вообще ни причём. Главное кварц подобрать, чтобы делитель целым был.

Да, писал, реально. На PIC18F4520. Вместо COM-порта использовал кабель USB-to-COM.

А если кварц 9216 кГц с PLL 18F252 хватит скорости? а то только 57600 MODBUS RTU завелся. На 115200 то есть то нет связи. Интерфейс кстати 485.

Должен, а почему бы и нет. (если PLL это типа HS PLL)

Ну да. Ощущение что нехватает времени в 4 байта для подготовки ответа. Какие команды для организации меню более оптимальны? Я использую switch. Может стоит пользоваться старым добрым if?

зависит от кол-ва пунктов, для себя как-то считал, на маленьком числе (до 10) быстрее будет IF

и на 230400 без проблем должно заводиться?

По поводу времени формирования ответа, вопрос сложный. Надо смотреть ассемблерный код, который сформировал компилятор. Кстати, сразу же отмечу, что если обработка буфера USART'а происходит в прерываниях (а оно скорее всего именно так), то внимательно посмотрите, чего там добавит компилятор. Зачастую, если задача позволяет, лучше написать такую программу на ассемблере, тогда можно выжать максимум из МК (и 230400). Навскидку, для приёма потока 230400 бит/сек потребуется 230400/8 (если в посылке 8 бит, а не 9) раз обработать принятую информацию. МК работает на 10 МГц (максимум от HSPLL). Значит на обработку одного байта потребуется 10000000/(230400/8)=347 тактов. Обработка принятых данных скорее всего будет осуществляться в прерываниях. Процесс обработки одного байта пусть будет порядка 250 тактов (для проги, написанной на С). Тогда у Вас на процесс приёма будет тратиться порядка 70 % ресурсов проца. А что дальше делать с этимим данными и отправлять ли ответ на комп - я не знаю, зависит от задачи, но у Вас остаётся на это только 30%. Данное соотношение можно легко изменить в сторону 30/70, т.е. на приём тратить только 30%, но тогда всю прогу надо писать на асме. Решение на чём писать принимать Вам.