Jump to content

Loreto

EstablishedMember
  • Content Count

    7
  • Joined

  • Last visited

Posts posted by Loreto


  1. Ciao Dave,

    I have a little news and I need your help to understand if this news is important or not!

     

    I tried to compile the same project, I sent you, with MPLAB (using SourceBoost as toolsuite) and I got a MsgBox error which states as follow:

    "The Extended CPU Mode configuration bit is enabled, but the program that was loaded was not built using extended CPU instructions. Therefore, your code may not work properly."

    PIC18F2525 technical reference states:

    Extended Instruction Set: The PIC18F2525 family introduces an optional extension to the PIC18 instruction set, which adds 8 new instructions and an Indexed Addressing mode. This extension, enabled as a device configuration option, has been specifically designed to optimize re-entrant application code originally developed in high-level languages, such as C. .... The mapping of the Access Bank is slightly different when the extended instruction set is enabled (XINST configuration bit = 1).

     

    I modified my #PRAGMA data to include _XINST_ON_4L bit but I was not able to remove the MSGBox Error.

    I attached the MsgBox error (.DOC) and chapter regarding the Data Addressing modes (.PDF) for PIC18F2525.

     

    Do you think that this error could address my problem??

    What about SourceBoost Extended Instruction set???

    Why SourceBoost IDE doesn't issue Extended Instruction Set Error???

     

    I'm exausting the tests so I'll appreciate any your suggestions..

     

    P.S. I noted that MPLAB C18 have two library called 18f2525_e.lkr (extended Instruction Set) and 18f2525.lkr.

    Could be I missed the BoostC extended library???

     

    Ciao

    Loreto

    LoretoDOC2.zip


  2. Ciao Dave,

    thank you for your answer and for your time.

    I'm sure that you are right.

    Using the LCD plugin you can see the code working properly. In fact using the simulator I don't see any problem.

    The problem arises after writing the code into PIC memory.

     

    To have a better understand about the problem, I inserted two displays (4 bits to 7 segments) on PortC to capture the output bytes. I inserted a 1 sec sleep before sending out characters on PortC.

     

    I see the output bytes related to LCD initialization and to the following line :

    	LCD_printRom(1,0, "Line2");			// LineROM 1

     

     

    but I don't see the bytes related to the following lines:

    	LCD_print(0,0,	"Line1");			// lineRAM 1
    LCD_printf(0,7,   ":%03d ", 54);	   // lineRAM 2

     

    This is discordant to the simulator view (where all the characters are displayed).

    For this reasons my feel is that, probably, the simulator doesn't correctly map PIC Hardware behaviour.

     

    It seems that the pointer passed to the function LCD_print(..., *text):

    void LCD_print(unsigned char LcdLine, unsigned char LcdColumn, unsigned char *text) {
    LCD_gotoRC( LcdLine, LcdColumn);
    LCD_print( text );
    }
    
    void LCD_print( const unsigned char *text) {
    unsigned char pi = 0, c;
    
    LCD_MODE = Mode_DATA;		  // Set LCD Data MODE
    while( 1 )  {
    	c = text[pi++]; 
    	if ( !c ) return;		  // EXITING line
    	LCD_sendByte( c );		 // Display on LCD
    }
    }

     

    is pointing to a NULL area and NO bytes are sent to PortC (see <if ( !c ) return;>).

     

    If the problem was due to a LCD timing, I would expect to see all the characters and not only the ROMs.

     

    What wrote jknichel is another aspect of RAM mulfunctions (garbage characters) I encountered too, but I'm focalized on this problem just because I was able to re-create it.

     

    If you have a time I would invite you to prepare a simple HW circuit with PIC and LCD/LEDs (LED display could be better to avoid LCD timing) and varify the PIC behaviour.

     

    Anyway I'm available to perform any tests and to pickup any suggestion.

     

    I don't know if my thinking is clear, and I apologize for my english.

     

    Thank you again for your time.

     

    Regards

    Loreto


  3. I just downloaded version 6.85 and the problem is the same.

    The file.hex is exactly the same as version 6.84.

    I tried also to remove the optimization (-O0 on both assembling and linkedit steps) without positive results.

    It seems that the string pointer passed to the RAM routine is pointing to a 0x0 filled area. Rarely a garbage character appears just to indicate that it's pointing wrong area.

    I don't know why but the debugger shows the correct strings.

     

    Do you have any other suggestion??

    Regards

    Ciao

    Loreto


  4. I'm encountering a strange problem using BoostC.

    I'm going to create a project using several devices and I'll need several variables and a large use of RAM.

    I'm going to use uP PIC18F2525.

     

    The first routine I realized were the LCD routines and I think that they works properly now.

    I can select 2 wires or 6 wires to control LCD. In the attached file you see the 2 wire using the shift register.

    All along I noticed a strange behaviour on the strings/data located in RAM memory.

    Some variables that were correctly displayed at one time, were garbaged after adding other variables.

    To solve the problem I tried to move as soon as all data to ROM memory. But now I cannot go ahead anymore.

    To understand the problem I cut a lot of code and now I'm goig to ask for any support or suggestion.

    This is my main()

    /***************************************************
    * M A I N 
    *************************************************** */
    #include 	"TMR0.h"
    void main() {
    Init_Registers();
    initPorts();
    LCD_initialize();
    LCD_Clear();
    
    while (1) {
    	TMR0_GATE_LINE  = 0;				//Turn OFF LED
    	LCD_print(0,0,	"Line1");							// line 10
    	LCD_printf(0,7,   ":%03d ", 54);				   // line 11
    	LCD_printRom(1,0, "Line2");   
    	delay_s(1);
    	TMR0_GATE_LINE  = 1;				//Turn ON  LED
    	delay_s(1);	}}
    
    
    /**********************************
    * Print ROM String to LCD		*
    **********************************/
    void LCD_printRom(unsigned char LcdLine, unsigned char LcdColumn, rom unsigned char *text) {
    LCD_gotoRC( LcdLine, LcdColumn);
    LCD_printRom( text );
    }
    
    /***************************************************
    * Print ROM String to LCD at current Cursor position 
    *************************************************** */
    void LCD_printRom( rom unsigned char *string ) {
    char pi = 0, c;
    LCD_MODE = Mode_DATA;		  // Set LCD Data MODE
    while( 1 )  {
    	c = string[pi++]; 
    	if ( !c ) return;
    	LCD_sendByte( c );  // Display on LCD
    }}
    
    
    /***************************************************
    * Print String to LCD at Row, Column *
    *************************************************** */
    void LCD_print(unsigned char LcdLine, unsigned char LcdColumn, unsigned char *text) {
    LCD_gotoRC( LcdLine, LcdColumn);
    LCD_print( text );
    }
    
    /***************************************************
    * Print String to LCD at current Cursor position 
    *************************************************** */
    void LCD_print( const unsigned char *string ) {
    char pi = 0, c;
    LCD_MODE = Mode_DATA;		  // Set LCD Data MODE
    while( 1 )  {
    	c = string[pi++]; 
    	if ( !c ) return;
    	LCD_sendByte( c );  // Display on LCD
    }
    }
    
    
    /**********************************
    * SET LCD Cursor Position		*
    **********************************/
    void LCD_gotoRC( unsigned char LcdLine, unsigned char LcdColumn) {
    LCD_MODE = Mode_CMD;		   // Set LCD Command MODE
    LCD_sendByte(0x80 + LcdLine*0x40 + LcdColumn);}
    
    -----------------------------------------------------------------------

    Note: The file "TMR0.h" contains definitions regarding variables NOT used by program.

     

    The program works fine but if I remove the <#include "TMR0.h">

    the first line of LCD is BLANK (seems that lines 10 and 11 don't work anymore).

     

    Tracing the program with BoostC I see that all the right characters are sent to the LCD_sendByte() with or without #include.

    My feel is that inside the PIC LCD_printRom() see the right string and LCD_print() see a NULL string and the routine exits on line

    <if ( !c ) return;>

     

    Analysing the compilation output fileGOOD.casm fileERR.casm, the main differences consists to use BANK switch on fileGOOD.casm.

     

    I attached the main routines used for the LCD output. I didn't insert <LCD_sendByte()> because it's the same for LCD_print and LCD_printRom

    My question is: Why adding or removing UNUSED variables on program, the PIC behaviour changes??

    Can anywone help me to understand where is my mistake ????

    I attached the fileGood.casm and fileERR.casm.

    Thank You

     

    Loreto

    Loreto.zip

×
×
  • Create New...