Is this an issue?

[shantanu@india]

Maybe not... Les can clarify.
If MyBuff contains all zeroes then the compiled code latches up...
Print At 1,1, Str MyBuff\16
I guess before using Print I should validate the contents of the buffer.

[top204]

What device are you using? Also, what display code are you using for the Print command?

I have tested the Str modifier with an empty array and it works as expected, and looking at its library assembler code, it will exit as soon as it sees a zero value because the Str modifier was placed in the compiler so that byte arrays could act as Strings, many years before I added String variables to the compiler. Hence the modifier's name of "Str"

A test program I created is listed below:

Code Select Expand

    Device = 18F25K20                               ' Tell the compiler what device to compile for
    Declare Xtal = 16                               ' Tell the compiler what frequency the device will be operating at
'
' Setup an Alphanumeric LCD
'
    Declare LCD_DTPin = PORTB.4
    Declare LCD_RSPin = PORTB.0
    Declare LCD_ENPin = PORTB.1
    Declare LCD_Interface = 4
    Declare LCD_Lines = 2
    Declare LCD_Type = 0
    Declare LCD_CommandUs = 2000
    Declare LCD_DataUs = 50
'
' Create a variable for the demo
'
    Dim bMyArray[20] As Byte
                
'--------------------------------------------------------------------
' The main program starts here
'
Main:
    Cls
    Clear bMyArray                      ' Make sure the array is empty
    Print At 1, 1, Str bMyArray\16
    Print At 2, 1, "Finished"

The text "Finished" is displayed on the LCD, so the program has not latched up.

Below is the assembler code the compiler uses for an 18F device while performing the Str modifier. I have commented the code so you can see what is happening within it:

Code Select Expand

__singlebank_strout__
    movwf PP2               ' Transfer WREG to PP2 (low byte of array's address). PP2H contains the high byte
__sb_strout_loop__
    movf GEN4,W             ' \
    btfsc STATUS,2          ' | Exit if no elements left to read, or there were no elements to initially read
    return                  ' /
    movff PP2,FSR0L         ' \
    movff PP2H,FSR0H        ' / Transfer the array's address to FSR0L\H
    movf INDF0,W            ' Read the element into WREG
    btfsc STATUS,2          ' \
    return                  ' / Exit if the element contains a zero value (a null terminator)
    rcall __byte_send__     ' Send the byte read from the array to the command's library routine that called it
    infsnz PP2,F            ' \
    incf PP2H,F             ' / Increment up the array's address
    decf GEN4,F             ' \
    bra __sb_strout_loop__  ' / Loop until all elements of the array are read


[shantanu@india]

Thanks Les.
Apparently I wasn't doing anything wrong , it should have worked exactly as you say.
I'm messaging you my code.

[shantanu@india]

Mailed you.
For some reason "Messaging" is forbidden(Error 404) in the server

[top204]

The forum does not like the percentage character that precedes some binary values. This has been posted on the forum a few times, and there is very little I can do about it, because I did report it to the domain and it went away after they made some "white listing" changes, but it came back for some reason a month or so ago.

I cannot examine large code listings in any detail because there is so much in them and the assembler code produced by large listings is very large and complex, so it would take many hours of examination for a "possible anomaly" somewhere inside it. :-) And is a piece of code is talking to an external peripheral it cannot easily be simulated, so its funtionality cannot be tested. Or if the code is using a third party library, it cannot be fully tested because it may be somewhere in the library code that is at fault and does not like exiting early or seeing nothing at all etc...

The Str modifier cannot lock a program up, because it has infalible escape mechanisms built into it that will exit early, but nothing will be printed or transmitted, and this may cause locking if a receiver is expecting something, or look like a lock if the LCD is not displaying things and timings are disrupted etc...

The only thing that could cause problems is if an interrupt is being used that is also interfering with the compiler's system variables. i.e. If used as assignments or temporary variables within the interrupt handler etc, in which case they will not be recognised by the Context directive.

Create a code snippet that reproduces your problem, and move variables around so they are in higher RAM banks to make sure that is not the cause, which is easily done by adding large dummy arrays before them. If using an 18F device, there is no need for the Str or StrN modifiers because they were placed in the compiler to simulate String variables to a certain degree, but String variables are available with 18F devices and enhanced 14-bit core devices, so they are no longer required. If transmitting the contents of a Byte array, the Str modifier will not work because it will terminate as soon as an array's element has the value of 0 in it. Which is the null terminator in a String variable.

[shantanu@india]

The Str modifier cannot lock a program up, because it has infalible escape mechanisms built into it that will exit early, but nothing will be printed or transmitted, and this may cause locking if a receiver is expecting something, or look like a lock if the LCD is not displaying things and timings are disrupted etc...

Exactly whats happening in my case.
I'll try to decode by writing a barebone code.
Thanks.