Uart1_Write_Text command in v5 of the compiler

[DaveLong]

Are there any known issues with use of the serial ports (dsPIC30 - P30F6014)?
I recently upgraded to v5 of the compiler (from v4) and am having trouble with uart1_write_text. I wanted to merely change the baud rate from 38400 to 9600, but a working application now fails to send data to the host program, though it continues to be able to read data sent to it by the host. (The same is true if I revert to 38400 baud.)
After trying just about everything else, I decided to find an old copy of the compiler and send exactly the same code to my project... Everything worked again.

In both cases I initialize the port using:
[code]Uart1_Init_Advanced(9600,_UART_8BIT_NOPARITY,_UART_ONE_STOPBIT)[/code]
A typical send looks like:
[code]AKresponse = chr(2) + " CLSC,0 " + chr(3)
Uart_Write_Text(AKresponse)[/code]
This line simply does nothing when compiled with v5, but is fine under v4.

[DaveLong]

Excuse me for replying to my own post but I thought it important to confirm that there is indeed a bug associated with v5 compiler. Previously there were other variables that might have accounted for the problem I reported. However, with excellent service from mikroElektronika, I have been able to reinstall v4 compiler on the same laptop as was running v5.

If I send the code to my project using v5, UART1_WRITE_TEXT fails whilst otherwise UART1 operates correctly.
If I switch back to v4 and re-compile the same code, the UART1 is able to send as well as to receive.

If I need to provide more information about the particulars of my project, please ask.

[yo2lio]

I use Uart1_Write_Text with successfully but to other MCU : PIC24FJ128GA010.

Try this like an work around :

Code: Select all

dim AKresponse as string[100]
dim count as word

main:
  Uart1_Init_Advanced(9600,_UART_8BIT_NOPARITY,_UART_ONE_STOPBIT)
  AKresponse = chr(2) + " CLSC,0 " + chr(3)
  count = 0
  while AKresponse[count] <> 0
    Uart1_Write_Char(AKresponse[count])
    inc(count)
  wend
end.

[DaveLong]

Thanks for the suggestion. Since I have a working solution (using the old compiler) and an impatient customer (!) I will not be trying this workaround immediately. However, for the sake of this forum I will try to find time later to test it with my MCU and report back.