Jump to content

Pavel

Administrators
  • Content Count

    1,466
  • Joined

  • Last visited

Posts posted by Pavel


  1. Here are some notes how rom objects work in BoostC:

    - a rom object is always identified by one byte (that's why in the code above gbl_sw_id is 1 byte long)

    - when linker processes all its input files it makes a list of all rom objects and allocates IDs to them

    - linker generates code for all these rom objects that it puts into the code memory

    - linker generates a function that can extract any byte of any rom object using its ID and position/index

    - when compiler needs to generate code to access character in a rom object it uses an placeholder ID and character position/index and calls function that linker generates in the prev bullet. Later linker replaces this placeholder ID with an actual object ID.

     

    Chameleon does not yet support rom objects. Support for rom objects will be added to Chameleon in the upcoming 7.43 release.

     

    Regards,

    Pavel


  2. When compiling a file the first thing the compiler does it splitting preprocessed source file into lines. If it fails it spits out the error that you quoted. Normally this process is very straightforward and there shouldn't be any errors (hence the error is so brief) but looks like we missed something in this parser (Chameleon is still in beta stage). Can you email your source file along with the compiler command line to support@sourceboost.com so we can investigate.

     

    Regards,

    Pavel


  3. Well spotted. This error affects several other recently added targets as well. The fix you provided is correct too. Affected files:

     

    PIC18F24K40.TDF
    PIC18F25K40.TDF
    PIC18F26K40.TDF
    PIC18F27K40.TDF
    PIC18F45K40.TDF
    PIC18F46K40.TDF
    PIC18F47K40.TDF
    PIC18F65K40.TDF
    PIC18F66K40.TDF
    PIC18F67K40.TDF
    PIC18LF24K40.TDF
    PIC18LF25K40.TDF
    PIC18LF26K40.TDF
    PIC18LF27K40.TDF
    PIC18LF45K40.TDF
    PIC18LF46K40.TDF
    PIC18LF47K40.TDF
    PIC18LF65K40.TDF
    PIC18LF66K40.TDF
    PIC18LF67K40.TDF

     


  4. Chameleon has a number of advantages over BoostC.

     

    Some technical differences:

    - faster compilation

    - native floating point support

    - native bitfield support

     

    Current release of Chameleon does not have any license limitations and is free.

     

    Another important difference is in the way how compiler generates code. In BoostC user can't control this while in Chameleon almost all aspects of code generation can be customised by editing system headers located in include\sys directory.

     

    Regards,

    Pavel


  5. Sorry about the confusion and let's try to sort this out. What product is the key for? Based on the screenshot that you provided it seems that the product is BoostC Pro but you try to register either plugins or IDE. Keys are valid only for products they were issued for and will not work with other products.

    Please email details to support@sourceboost.com and we'll sort this out.

     

    Regards,

    Pavel

     


  6. ...What exactly means "limited support" in the version log?...

    Limited support means that only core information that is necessary to compile and debug for this target is included into system headers and TDF files:
    • - only core registers are defined in the system header files, if you need other registers you need to add your own defines to either your code or system header
    • - full config data is added to the system headers (PIC16) or TDF(PIC18) files
    • - target architecture is fully described in the TDF files but non-core registers and register groups are not.
    You are welcome to add missing information. To compile it's only necessary to add it to system header files. Missing information in the TDF files is used in debugging under SourceBoost IDE and if you use Mplab or Mplab X you don't need it.

     

    For example look at the Port B support that is not defined in the limited support targets but is fully supported in PIC18F8722. This target has the following information in its system header file PIC18F8722.h (used in compilation):

    ...
    #define PORTB                  0x00000F81 
    ...
    volatile char portb            @PORTB;
    ..
    
    and in PIC18F8722.tdf file (used for debugging):

     

     

    Configure PORTB
    {
        // create
        PinNames = "RB0|INT0","RB1|INT1","RB2|INT2","RB3|INT3|ECCP2|P2A","RB4|KBI0","RB5|KBI1|PGM","RB6|KBI2|PGC","RB7|KBI3|PGD";
    }
    
    
    RegisterSF PORTB
    {
        Description = "PORTB","";
        Address = F81h;
        BitNames = "RB7","RB6","RB5","RB4","RB3","RB2","RB1","RB0";
    }
×
×
  • Create New...