UART2 / Interaction with String Conversion?

[JackOfVA]

Working on a program that requires input/output via UART2 - where I have an XBee 900 MHz transceiver. No problem sending and receiving with the Xbee and UART2 until I try a numeric to string conversion.

Problem I see is that using Hex() or Str() to convert a number to string and then outputting the number interacts with the UART2 code and freezes the UART2 write functionality.

The program at the bottom of this post illustrates the problem. (This is a small version of what I am working on, but it fails the same way as the larger program)

I've marked the problem area with '### symbols in the program.

If the lines within the ### highlight are:

Code: Select all

TByte = 44
  //TempStr = Hex(tByte)
  TempStr = "99"
  UART2.Write("Fields: ",TempStr,13,10)   

The program executes fine and the terminal screen looks like:

OK
<A,D,C,P>?
Rcvd test 123
Fields: 99
<A,D,C,P>?

I have entered the response test 123 after the ? symbol and the program has echoed it back. The code within the ### executes
and displays Fields: 99 and the main prompt returns for the next data entry sequence.

However .... if I change the code within the ### to:

Code: Select all

TByte = 44
  TempStr = Hex(tByte)
  //TempStr = "99"
  UART2.Write("Fields: ",TempStr,13,10)         

None of the prompt is displayed and entering test via the terminal results in no prompt.

This looks to me like the compiler generates bad code with this sequence that somehow mangles the UART2 functionality as if there was just a problem with the conversion into a string representing the hex display the prompt would appear for the initial data entry.

Here's the full program demonstrating the problem.

Code: Select all

' Imports section...
Imports Strings
imports Uart
imports Uart2 

' Declarations...
'Const
'-----

'Var
'---



Sub Main()
   Dim TByte as Byte
   Dim TempStr as String
   Dim Rstr as String

   UART2.ReadTerminator = 13
 
   Uart.SetBaudrate(Uart.Baudrate.Is38400)
   Uart2.SetBaudrate(Uart2.Baudrate.Is9600)
 
   Delayms(100)
   UART2.Write("OK",13,10)
 
 While True
 
 Delayms(500)
 
  UART2.Write("<A,D,C,P>? ",13,10)
     
  Uart2.Read(RStr)
  Uart2.Write("Rcvd ",RStr,13,10)
   
  Delayms(5)   
 
  '#################################################
  'Problem is in lines below.
  'Program executs as expected with TempStr = 99
  'Fails with TempStr = Hex(tByte)
  '#################################################
  TByte = 44
  //TempStr = Hex(tByte)
  TempStr = "99"
  UART2.Write("Fields: ",TempStr,13,10)         
     
  End While
End Sub


[JackOfVA]

OK - I found the problem.

I have been running with compiler optimization = none.

Switching to compiler optimization for size and speed solves the problem.

However, it seems to me that this is still a concern as regardless of the degree of optimization selected, there should be no difference in whether the program will successfully execute or not.

[David John Barker]

I have just tried your code with the latest compiler BETA. The only changes made are

Code: Select all

Uart2.SetBaudrate(Uart2.Baudrate.Is38400)

as my xbee module is configured for 38400 operation. I used the same shield and explorer board as described here

http://www.firewing.info/pmwiki.php?n=FirewingUser.XBEEBootloader

the output generated here looks correct

Code: Select all

OK
<A,D,C,P>?
Rcvd a
Fields: 2C
<A,D,C,P>?

and the generated intermediate code also looks correct.

[JackOfVA]

It's 100% reproducible here by selecting compiler optimization. (Firewing 16 compiler)

Same thing if I use Microchip 16 compiler- with no optimization selected execution fails, but with optimization for size it works as expected.

As long as it works with optimization for size selected I can continue on the project, but it seems odd that optimization switched off generates code that fails.

When I have time, will look at higher data rates with other Xbee devices. Have the 2.4 GHz as well as 900 MHz available.

[David John Barker]

I tested here without optimisation. If you are compiling with optimisation and it works, I'm pretty sure it might my some timing issue. That is, without optimisation it fails (code takes longer to execute) with optimisation, the code succeeds (generally less time to execute). This is very unusual, code normally fails the other way around (fail on optimisation). Remember, I was running my xbee at 38400 without optimisation.

[JackOfVA]

I reset the Xbee 900 MHz modules for 38400 and see the same behavior as at 9600. Failure with no optimization, works as expected with optimization for size.

It's an odd one to say the least.