Проблема се състои в това, че когато сигнала CTS е лог.”0” (на пина на контролера) изпращането не започва. Tx си стои в лог.1.
Постановката е следната. UART се използва с прекъсване при свободен transmit buffer (UTXISEL<1:0>=10). Тоест се използва четирите нива на хардуерният FIFO буфер. Хардуерният буфер е съчетан със софтуерен. При изпразване на хардуерния буфер настъпва прекъсване. В прекъсването се изчитат 4 байта данни от софтуерния буфер и се записват в хардуерният. След което се излиза от приакзването. При изпращане на трите байта и прехвърляне на четвъртият байт в изместващият предавателен регистър се генерира ново прекъсване и всичко се повтаря докато има данни в софтуерния буфер.
Ако не се използва Flow Control(UEN<1:0>=00) това работи нормално. Ако се пробва да се използва Flow Control(UEN<1:0>=10) се наблюдава следното при CTS в лог. “0 “ тоест при разрешено предаване. Попълва се хардуерния буфер с данни, но същинско изпращане не започва. Флаговете за статус са съответно TRMT=0 и UTXBF=1. Пина за CTS е коректно конфигуриран, ако се пробва да се реализира софтуерен Flow Control със същият този пин нещата се получават.Тоест се задава UEN<1:0>=00 и в прекъсването от празен буфер се чете пина CTS. Ако той е в лог.0 се продължава с изпращането, а ако не се забранява прекъсването за празен буфер. Обратното разрешаване на изпращането когато CTS стане отново нула, е повече играчка, защото става чрез прекъсване при промяна на нивото на CTS. При този софтуерният подход има два недостатъка Първият е, че нещата са малко по-тромави, но това не е кой знае какъв проблем, преживява се няколко us повече не са от такова значение. По големия недостатък е, че при този подход спирането на изпращането не е след завършването на изпращането на текущия байт както би трябвало да е, а е след до четири байта тези които се намират в хардуерния FIFO буфер. Ако не се използва този хардуерен буфер това би премахнало проблема(тоест ако се използва прекъсване не по празен буфер, а по завършило предаване на байт), но тогава пък се появява друг недостатък. При високи скорости на комуникация времето между отделните прекъсвания е малко и се губи много време за влизане и излизане от прекъсване след всеки предаден байт.
Забравех да спомена, че когато се опитвам да използвам хардуерния Flow Control си задавам коректно PR функцията за съответния пин.
Пълната конфигурация на UART с която се опитвам да подкарам хардуерния Flow Control е следната:
UARTEN=1
UFRZ=0
USIDL=0
IREN=0
RTSMD=0
UEN1:UEN0=10
WAKE=0
LPBACK=0
ABAUD=0
RXINV=0
BRGH=1
PDSEL<1:0>=00
STSEL=0

UTXISEL<1:0>=10
UTXINV=0
UTXBRK=0
UTXEN=1
URXISEL=10
ADDEN=0

Някой използвал ли е хардуерния Flow Control на PIC24FJxxxx и имал ли е подобни проблеми? Бих се радвал да сподели своя опит и наблюдения. Предварително благодаря на всички.

Никога не ми е трябвал.

Имаше някаква врътка; пробвай Simplex Mode (RTSMD=1).

ANSEL-a цъкнал ли си го?

Не съм цъкал ANSEL.
То в PIC24 няма такъв регистър. Той съществува в PIC16 и PIC18.
В PIC24 негов функционален аналог е AD1PCFGL AD1PCFGH. По принцип това е сред първите неща за които се сетих да не съм сетнал пина като цифров, но не е това. Пина който използвам изобщо няма аналогова функция даже. Освен това съм напълно убеден, че кракът си е правилно конфигуриран, защото го чета правилно и даже с него съм си реализирал софтуерният варният на Flow Control. Благодаря за насоката все пак много често проблемите са свързани с не конфигуриране на пина като цифров.

RTSMD би трябвало да определя функцията на RTS дали е за Flow Control или за управление на предавателя при полу дуплекс. Въпреки това ще пробвам и ако има положителен резултат ще споделя. Благодаря за това предложение това не съм го пробвал до сега.

един линк, в който казват че реда на инициализацията на пина
има значение ( последния пост )

http://www.microchip.com/forums/m489270.aspx

Съжалявам, че не мога да бъда по-конкретен; беше отдавна. Имам само смътен спомен за недобре документирана особеност – в Simplex Mode изводите работят като RTS/CTS, а във Flow Control Mode работят като DTR/DTS.

Точно с това се оказа свързан проблема.
Благодаря на всички.