По-рано свързвах PC с PIC по COMM порт, като можех да пращам данни в двете посоки едновременно (duplex). Сега обаче, правя интерфейс през virtual comm port чрез FTDI FT232RL и USB iнтерфейс и забива. (Когато правя последователно предаване на данни в двете посоки, не едновременно, няма проблем). Предполагам, че това се дължи на USB интерфейса, но има ли начин това да се преодолее?

USB интерфейса е еднопосочен (тоест не е full duplex). Ама понеже по-бърз, би трябвало да може да си го буферира и да изглежда като постоянен трансфер в двете посоки. Лично не съм пробвал, обаче, но предполагам че е софтуерен, а не хардуерен проблем.

Не би трябвало да имаш проблем - фт-то поддържа фулл дуплекс на доста по-големи скорости отколкото старите хардуерни комове - имаш някъв проблем със софтуера на компютъра.

По-скоро с идеологията на протокола може да имам проблем.
Протокола ми е:
PC->PIC: Команда, параметри, контролна сума
PIC->PC: Отговор, данни, контролна сума

с това проблем няма.

Но имам и така наречения асинхронно предаване на данни от PIC към PC в момент, когато PIC реши (примерно всеки 10ms, за всеки полупериод на мрежовото напрежение). И ако тогава PC изпраща команда към PIC следва колизия.

Тая идеология с двупосочния RS232 си беше добре, но явно тук не става.

Хъ - не би трябвало да имаш проблеми - пробвай да си поиграеш с буферите в настройките на компорта.

За FTDI не знам, но ползвам доста серийни конвертори и нямат никакъв проблем с дуплекса, това е по скоро въпрос на драйвер и настройка на драйвера, няма логика да не става.

Преди няколко месеца правих нещо с конвертори на FTDI и забелязах това за което говориш. Става дума конкретно за VCP. При определени обстоятелства шанса да забие се увеличава. И понеже това е FTDI звучи странно.
Същия проблем имах преди доста повече време, а тогава още не бяха произвели FT232R серията и се наложи приложението което беше за РС да се направи да ползва DLL-а за директно управление на чипа Проблема повече не се появи.
И наскоро много се учудих като установих стария симптом и на новите чипове. Конкретно ползвах FT231X. Затова си тествах крайното устройство с FT232R и FT232B в режим на VCP. Всяко малко се различаваше кога точно да забие, но рано или късно се случваше. Да кажем след около 5-6 часа. На друг комп след около 10 часа. А може и след 10 мин, но по-рядко.
Трансфера на данни е постоянен през около 20 ms в двете посоки.
Реално забива нещо между Windows-а и софтуерния драйвер който емулира VCP-то. Тоест не чипа, той не забива, поне аз не съм успявал да го забия.
Тогава се разрових за програмки за стрес тест на СОМ портове и да ти кажа попаднах на нещо което много добре се връзваше към моите условия на установката. Пробвай ако ти се занимава.
http://www.aggsoft.com/com-port-stress-test.htm
По мои наблюдения когато трафика е "много" интензивен и двупосочен 24/7 почти всеки VCP драйвер умира. Минеш ли на DLL комуникация всичко спи При готови софтуери няма как да минеш на DLL разбира се. Навярно ако му се дават "малки" почивки на Windows-а нещата също са оптимистично стабилни. Така работи устройството в момента.
Като казах по-горе - почти всеки VCP драйвер - имам предвид на всеки производител понеже просто Windows-a си е същия.