Jump to content

Loreto

EstablishedMember
  • Content Count

    7
  • Joined

  • Last visited

Everything posted by Loreto

  1. Hi Reynard, I don't insist to use extended instruction set. I just reported them because I got error running a project using SourceBoost under MPLAB env (see attached DOC). My goal is to have a working code using BoostC and nothing more. Regards Loreto
  2. 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: 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
  3. 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
  4. A zipped project was sent to support last Saturday. I don't know if a forum update is required. This is just it.
  5. To fix this problem we need to be able to reproduce it. A zipped project and instructions of steps to reproduce the problem sent to support@sourceboost.com will help. Regards, Pavel I'm going to prepare the package and I'll send it you. Thanks
  6. 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
  7. 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...