Help with Compiler error

Discussion in 'Embedded Systems and Microcontrollers' started by Vulcan27, Feb 5, 2015.

  1. Vulcan27

    Thread Starter New Member

    Apr 9, 2014
    5
    0
    Hi. I'm using MPLAB X IDE and XC8. This code was originally written for MPLAB 8 and C18. Fairly new to PICs so I wanted to learn the latest software but I keep encountering problems with legacy coding not being compatible. In this caes it is for a PIC18F452 to a LCD.

    The header file (part) gives this error when I clean and build project:

    /* prototypes */
    void delay_ms(unsigned char);
    void lcd_busy(void);
    void lcd_i_write(unsigned char);
    void lcd_d_write(unsigned char);
    void lcd_init(void);
    void putrs_lcd(const rom char *);
    ../lcd.h:28: error: (372) "," expected
    void puts_lcd(char *);
    char ntox(unsigned char);
    char *btox(unsigned char, char *);
    char *itox(unsigned int, char *);
    char *ltox(unsigned long, char *);


    and the .c file (part) gives this error:

    void putrs_lcd(const rom char *buffer) ../lcd.c:222: error: (372) "," expected
    {
    while (*buffer) {
    lcd_d_write(*buffer);
    buffer++;
    }
    }

    Any suggestions as to where I'm going wrong?

    Steve
     
  2. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,386
    1,605
    I'm still dedicated to C18 and have only done a few experiments with XC8.

    Looks like XC8 does not like the rom keyword we so love in C18. Keyword "rom" was necessary to let the compiler know to use a different method to retrive a variable from program memory or data registers.

    My guess is the compiler authors recognized a "const" variable should always be places in program memory and thus dropped the "rom" keyword.

    Again my guess is just drop the "rom" in these statements. Note you would still need two forms of functions when supplying either data or program ("const") variables.
     
  3. MrChips

    Moderator

    Oct 2, 2009
    12,415
    3,354
    Just drop the const rom altogether:

    Code (Text):
    1.  
    2. void putrs_lcd(char *buffer)
    3. {
    4.    while (*buffer)
    5.       lcd_d_write(*buffer++);
    6. }
    7.  
     
  4. Vulcan27

    Thread Starter New Member

    Apr 9, 2014
    5
    0
    Thanks that does solve this error. Unfortunately other errors now come up when compiling. I will try going back to MPLAB 8 and C18 as it does seem too time consuming to try and rewrite code, especially with my limited knowledge.
     
  5. spinnaker

    AAC Fanatic!

    Oct 29, 2009
    4,866
    988
    It really is not that difficult. What is the new error?
     
  6. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,386
    1,605
    The C18 is a fine compiler, and it will now be eternally stable; such is the blessing of obsolescence. I have bad memories of one major upgrade that broke some difficult code I had involving a boot loader: code and the link script needed rewrites.

    I’m keeping several projects written for C18 in C18. No need to modify good code just because there is a new bright and shiny toy to play with.
     
    JohnInTX likes this.
  7. JohnInTX

    Moderator

    Jun 26, 2012
    2,339
    1,022
    That should be engraved on a plaque somewhere important.

    Its correct that you don't need 'rom' to specify program memory like HiTechC (progenitor of XC8) wanted. Any non-auto 'consts' will go into ROM.

    I don't think you need separate functions to deal with const in ROM vs. variables of the same type or defined type. In HiTechC (PICC18 at least), if the compiler detects variables in ROM and RAM will be used by a function, it generates code that executes at run-time to examine the address of the variable to determine whether its in RAM or ROM then jumps to a direct read from RAM or table reads from ROM as required. I've ported some routines from HiTech to XC8 that accept pointers to struct in either ROM or RAM and they work OK - though I haven't looked at the assembler output to see exactly what's going on...

    My .02
     
    Last edited: Feb 5, 2015
  8. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,386
    1,605
    That is very good to know. Discovering pointers were different depending on where the variable was located was a stumbling block getting C18 to dance for me.

    Some lessons are easier learned then unlearned. Good to know there may actually be a reason to use XC8.
     
  9. JohnInTX

    Moderator

    Jun 26, 2012
    2,339
    1,022
    Maybe. The way HiTech did it was to use unused bits in the pointer variable to specify ROM or RAM. Unfortunately, we found that the pointer calculation did not work correctly for some big pointers >64K. HiTech sent a patch that solved our problem. Unfortunately again, later we found that there were other types of big pointers that weren't fixed. By that time, they had updated to OCG which didn't compile the RTOS at all so that was that. When XC8 arrived, I queried uCHIP to see if the big pointer issues were fully resolved and got ??? in return.

    If I were to start a real project with XC8 (or any other compiler, I guess now) I'd throw some complex/big stuff at it and see what it did in the dusty corners of C that I always seem to find. Or just stick with 'eternally stable' as you suggest.
     
Loading...