is it possible to disable the Uart FIFO on p24 ?

[jpc]

this starts to be real challenge ! And this is only the simple situation of NOT using the FIFO , next step might be using it at what moment it is a MUST to know what is returning from the FIFO , empty field or valid data containing 0.

[anton]

Nothing special there:

Code: Select all

function Uart1_Read_Char : word;
begin
   result := U1RXREG;
end;

Thank you zoran,

This is very weird then. Jpc, what happens when you declare ik1 as a word? I'll also quickly try it.

Anton

[jpc]

we seem to have identical thoughts , already tryed to make ik1 a word , no difference. When i start typing on my connected terminal 1234etc only on the 4 i get out of the fifo the first 1, if i continue typing the received hcaracters appear all ( except of coarse the last 3 )

[jpc]

still unresolved but i can add to this the fact that there seems to be a similar issue on P30 , the uart_isr occasionally gets out of synch with the send characters. After replacing the direct acces to UxRXREG by a call of Uartx_Read_Char the issue seems to have disappeared.

[anton]

Hi,

I have no idea why this happens, but as jpc also noted. The following code doesn't work on a PIC24. Only every 3rd character will interrupt.

Code: Select all

var k : word;

procedure IRQ_Uart1_Int; org $2A;
begin
  k := U1RXREG;
end;

Changing the code to call an external function, makes the code fully functional.

Code: Select all

function IRQ_Uart1_Read_Char : word;
begin
   result := U1RXREG;
end;

procedure IRQ_Uart1_Int; org $2A;
begin
  k := IRQ_Uart1_Read_Char;
end;

I'll post the asm listing of both the examples in a while.

Anton

[jpc]

Anton, are you sure only the 3rd character interrupt's ? I have been in contact with Microchip on this issue, finally started debugging by simply using Uast_Write_Text() inside the ISR ( this works very well on the 16 bit PICS's ) and found that i get interrupt but somehow get 3 empty characters in my buffer. The mystery remeined unresolved, the workaround is very simple but Microchip seemed anxious about this issue. I can reopen that ticket if we find something more solid, after all we work in another compiler than their engineers.