Jump to content

Dave

Administrators
  • Content Count

    2,046
  • Joined

  • Last visited

Posts posted by Dave


  1. djulien,

    If I have some asm code that jumps to a label, and the C code containing that label is removed (because the linker thinks it is dead code), an error like the following will be reported by the linker:

     

    Internal Error: Unable to resolve label ID:268440099 - 0x10001223

    Is there an easy way to figure out which label is causing the problem? The map and other output files are empty, so there is nothing to tell me which label is the problem. I have been using a "trial & error binary search" on the labels to try to find the bad one(s), but that is very tedious. I was hoping there was a quicker way.

    Sadly no.

    Internal errors are ones that end users should never get to see - assuming that compiler and linker are perfect.

     

    It would be good to have a simple example of such bad code so we can improve compiler and linker.

     

    Regards

    Dave


  2. I guess it comes down to how ugly I want to make the code. No worse than using MPASM at this point, I guess - but not much better either (:

    Hopefully other language aspects make it seem worthwhile

     

    Is there any equivalent of "$" in BoostC? (ie, is there a way to embed the current address into the final instructions generated by the linker, like for example, "goto $+1" or "movlw $" in MPASM?). That could help avoid a lot of hard-coded addresses defined in the code.

    No.

     

    Regards

    Dave


  3. djulien,

    I also started to try building the "gotos" manually (ie, "#pragma data 0x2800 + adrs") but something (linker?) would not perform the addition - I just got "2800" ("goto 0") instead of the correct destination address. I'm thinking there might still be a way to force it, but I don't know enough about the limitations of the linker (or maybe second pass of the compiler itself). Do you think there is a possibility there?

    Compile doesn't know anything about addresses as they are determined by linker when the program is linked.

     

    The only way to have knowledge about code (or variable) addresses prior to the linking stage to to make them fixed.

     

    I suggest the following:

    
    
    #define FOO1_ADDR 0x200
    #define FOO2_ADDR 0x210
    #define FOO3_ADDR 0x220
    #define GOTO_OPCODE 0x2800
    
    // build jump table
    #pragma DATA 0x100, GOTO_OPCODE + FOO1_ADDR, GOTO_OPCODE + FOO2_ADDR, GOTO_OPCODE + FOO3_ADDR
    
    
    void foo1()@FOO1_ADDR
    {
    ...
    }
    
    
    void foo2()@FOO2_ADDR
    {
    ...
    }
    
    
    
    void foo3()@FOO3_ADDR
    {
    ...
    }
    

    I hope you get the idea. Its all a bit on the manual side

     

    Regards

    Dave


  4. How can I implement a very efficient "jump table" using BoostC?

    ...

    Any other suggestions of how to solve this?

     

     

    This is indeed a bit of a problem, no nice way to do it at the moment.

     

    Here is a workaround; a bit ugly, and wastes memory, but should be fast.

    Note that I also use a fixed address function to make sure that linker doesn't move this code to a location where the jump table crosses a page boundry that would then break the code.

     

    #include<system.h>
    
    void foo();
    
    void main()
    {
       foo();
       while( 1 );
    }
    
    #define LEAVE_CODE_BELOW asm btfsc _x, 0
    
    #pragma OPTIMIZE "0"
    void foo() @0x100
    {
       unsigned char value = 1;
       bool x = 0;
    
       value <<= 2;
       value += 2;
    
       pcl += value;
    
       LEAVE_CODE_BELOW
       goto label0;
       LEAVE_CODE_BELOW
       goto label1;
       LEAVE_CODE_BELOW
       goto label2;
    
       LEAVE_CODE_BELOW
       label0: porta = 1; return;
    
       LEAVE_CODE_BELOW
       label1: porta = 2; return;
    
       LEAVE_CODE_BELOW
       label2: porta = 3; return;
    }
    

     

    I hope that helps.


  5. trossin,

    Is there a way to register a call back which is called every time a register is written? If not, I don't see a way to make this plug in work. Thanks for any help.

    I understand your problem. The interface only exposes register changes (this was done for efficiency) which is a real shame as you always seem to be doing such interesting things.

     

    Internally the simulator does have this functionality, such that hooks into register writes and register reads are available, and it is used by the simulated peripherals to enable them to respond to just the sort of events you describe. Also there are functions to allow reading and writing of registers without triggering read and write events. To get exposure of this functionality would require changes to IDE, debugger and simulator. So its not a couple of key presses away.

     

    So at the moment your project can't be completed.

    We need to take a more detailed look at things to decide if we want expand the interface and will let you know when we have made that decision.

     

    Regards

    Dave


  6. minitech,

    This question may have been asked in the past, but being new to boost I will ask anyway.

    At the start of my programs ( programmed in BloC previously ) I reset the banks of registers I will be using.

    The following code clears Bank 0 & 1 OK. It sets most of Bank 2 OK, but doesn't use indirection. I know I could embed the asm

    to cure but is there a trick I am missing to get boost to do it for me?

     

    /*******************************/

    /* Clear bottom bank of memory */

    /*******************************/

    fsr = (unsigned char)&Light_Timer;

    do

    {

    indf = 0;

    fsr++;

    }

    while ( fsr <= &Daily_Count );

     

    /**************************/

    /* Clear bank 2 of memory */

    /**************************/

    same as Bank 0 different registers

     

    /**************************/

    /* Clear bank 3 of memory */

    /**************************/

    fsr = (unsigned char)&HeatCtr;

    do

    {

    indf = 0;

    fsr++;

    }

    while ( fsr <= &B2_Unused );

    This method of zeroing registers is certainly not recommended for the following reasons:

    1) It assumes the variables refenced are in specific banks. It is normal practice to leav linker to decide where to put variables in the memory space.

    2) It assumes that the loop uses no data that may be destroyed as it clears the memory.

    3) It is non-portable, should you ever use some of your code on another device it may not work.

     

    The recommended method is:

     

    int myGlobalVar = 0;

    etc.

     

    Regards

    Dave


  7. Lecalou60,

    Hello,

    I'm new to the forum. I use Flowcode V5.2 and am having a trouble to compile my little program. A generation of C file, everything goes well. As soon as I want my generated assembly file, I receive an error message:

    D1> error: Failure

    Can you help me?

    Looks like the preprocessor may be terminating with an error. The preprocessor works on the code before the compiler in response to preprocessor directives such as #ifdef, #endif, #define.

     

    To find the cause I would do the following:

    1) Take a copy of the project.

    2) Keep removing chunks of the code until the preprocessor is successful,

    3) Slowerly add code back in again until the error occurs again.

    Then you will hopefully know what is causing a problem with the preprocessor and then be able to avoid or correct it.

     

    I hope that helps

    Regards

    Dave


  8. Micmar,

    Hello

     

    I have tested the simulator with the 7.10 release but it fail again :( :( :(

    Can youn fix this? I work strong with this family

    What exactly is not working?

    I ran the program you posted at the beginning of this thread and it seemed to work - well PA5 is working.

    Does this work for you?

     

     

    Regards

     

     

    Dave


  9. Kwooda,

    If I have some existing libray code written in MPLAB assembly, is there a way I can include it or link it into a BoostC program? I tried using the asm directive and cutting+pasting some code in there, but the compiler didn't like that. I really just want to include it as part of the build, primarily during the process of incrementally rewriting some of the code in C.

    No it can't be done.

    The best method is to wrap the assembly code in a C functions using inline assembly and call the newly created C function.

     

    Regards

    Dave


  10. art590,

    Hello.

    Are there issues with file paths in mplabX and current SourceBoost C ?

    After compiling I keep getting this with SourceBoost but not with HiTec Pic C:

     

    success

    make[2]: Leaving directory `C:/projects/tst1.X'

    make[1]: Leaving directory `C:/projects/tst1.X'

    BUILD SUCCESSFUL (total time: 1s)

    Loading code from C:/projects/tst1.X/dist/default/production/tst1.X.production.cof...

    Loading symbols from C:/projects/tst1.X/dist/default/production/tst1.X.production....

    The program file could not be loaded: java.lang.NullPointerException

     

    And when attempting debug, a dialog pops up with:

    "C:/projects/tst1.X/dist/default/debug/tst.X.debug. does not exist or is not an executable"

     

    It looks as if the file extensions are being truncated. I'm using MplabX 1.2 and SourceBoost 7.10

     

    Any help appreciated.

    -Art

    Try using folder names that don't have a dot ('.') in them.

    Let us know how you get on.

     

    Regards

    Dave


  11. JorgeF,

    Hi

     

    I know that Dave.

     

    I never tested the code generated for any differences, but when in doubt, I tend to use the approach...

    "if they botter to create this, they must have had good reasons for it"

    ... thats why I didn't recommend any other alternatives.

    Sorry I misread your post and thought you where asking for a neater smater way - whoops.

     

    The set_bit() and clear_bit() functions are there because they existed before the method I described.

     

    Regards

    Dave


  12. JorgeF,

    Hi

     

    There is allways the BoostC/easy/smart way of doing it:

     

    set_bit(status,C);
    

     

    By the way don't forget also

    clear_bit(status,C);
    

    and

    if(test_bit(status,C)) .......................
    

     

    status.C = 1;
    ...
    status.C = 0;
    ...
    if( status.c )
    ...
    

     

    This works because of support for individual bit addressing in the form "var.bitNumb", where bitNumb is a constant.

    And C is declared as the appropriate bit number in the target header files.

     

    Regards

    Dave


  13. GordonS,

    An oddity I note in that data is that the 0xCFF9 appears at 0x4200 but, if the 4200 gets divided by two to get the reall addres, then one half of that number goes to address 0x4100.5, which clearly isn't going to happen.

     

    Are you able to explain what _does_ happen?

    I think you mean that half the number will get written to 0x2100.5, and you are right. Location 0x2100 conists of 16bits, which map to EEPROM locations 0 and 1 when written to during the programming process.

     

    Regards

    Dave


  14. JorgeF,

     

    I noticed that the ICD3.h include file has the following warning for the reserved range of program memory for use by the ICD3 debugger.

     

    #pragma message "Warning: ICD3 Reserved ROM address range:0x1FD80-0x1FFFF (use linker -rt option)"

     

    But the MPLAB 8.83 help file for the ICD3 states that the reserved range should be 0x1FD2F-0x1FFFE.

    Which target device is this for (as the reservered space chances between devices) ?

     

     

    Regards

    Dave


  15. Reynard,

     

    For those who need an un-official fix and with source code for libc, modify the code for strstr with sub-string in rom to:
     for( ; ( ptr1 = strchr( ptr1, ptr2[0] ) ) != NULL; ptr1++ ) { for( i=0, j=0 ; ; ) 

    Both for loops modified. Cheers Reynard

     

    Nice simple fix.

    I didn't quite see all your changes so thought it was still broken.

    I ended up with a completely new version that uses less code and executes faster - see below:

     

    char* strstr( const char *ptr1, rom char *ptr2 )
    {
    char *uPtr1;
    char c1, c2_1st, c2;
    
    // to save constant lookup of first character of string we are trying
    // to find take a copy of it
    c2_1st = ptr2[ 0 ];
    
    // Nothing to find
    if( c2_1st == '\0' )
     return (char *)ptr1; // casting constness away - not really a good idea!
    
    for( ; c1 = *ptr1, c1 != '\0'; ptr1++ )
    {
     // when first character matches, we need to examine further to check all match
     if( c1 == c2_1st )
     {  
      uPtr1 = ptr1; // take copy of pointer, so search can continue from this point if needed
    
      // rom char idexes are only 8 bit
      unsigned char romCharIdx = 0;
      while( 1 )
      {
    // get next character of string to find
    c2 = ptr2[ ++romCharIdx ];
    
    // see if match completed successfully,
    // ie no more characters left string we are trying to match
    if( c2 == '\0' )  return (char* )ptr1; // casting constness away - not really a good idea!
    
    // get next character of we are searching in
    uPtr1++;
    c1 = *uPtr1;
    
    // if characters are not the same, matching has failed.
    if( c1 != c2 ) break;
    
      }
     }
    }
    
    // finding string failed
    return NULL;
    }
    

     

    Regards

    Dave


  16. zzjoki,

    Since the RTOS is controlling program flow, would the code flow jump around in the simulator?

    Yes.

     

    Am I suppose to be able to trace into library function though I don't have source code?

    You can, but only at assembly language level if you don't have the source code.

    If the code window is active, code stepping is on assmembly language instructions. If the code window is not the active window code stepping is on source code lines.

     

    Regards

    Dave


  17. TomF,

     

    The cursor can be displayed on the first and second line, but when i try the third or forth lines, it doesn't show.

     

    Using a 20x4 display.

     

     

     

    You are quite right.

    This source code has been gathering dust as we have had no bug reports for years, but now you find an issue.

    I'll add it to our bugs list.

     

    Best I can suggest as a work around for now so you can see the cursor is to use the plugin in 40 x 2 character mode, because in this mode the memory is mapped just the same but line 3 is on the end of line 1 and line 4 on the end of line 2.

     

     

    Regards

    Dave


  18. The best option is to use the -rb option, this allows offseting of all the BoostC generated code.

    All the interrupt and reset code areas can then be use to intercept restarts and interrupts before the BoostC code is called.

    Once your own code is done call the BoostC code at its new offset address.

     

    I'm not sure I've made that very clear, but I hope that helps.

     

    Regards

    Dave


  19. Micmar,

    Micmar,

    I have wrote a little program to test the comparator and change two output

    Report: of simulation

    PA2 work well

    PA5 not work

    Still looking into this one, it's not straight forward.

    The problems here are two:

    1) Error in the PIC16 Ext simulator that does not allow connection to the correct pin.

    2) Errors in .TDF that list the names associated with each pin.

     

    These will be fixed in the next release,

     

    Regards

    Dave


  20. JorgeF,

     

    1 - Why doesn't I got those options under MPLAB, they are there for other toolsuites.

    Is it a limitation of the integration of the Sourceboost toolchain in MPLAB, or the feature reserved for Microchip and some "special" partners?

    I don't know the detail. This is one for Pavel to answer.

     

    2 - By what I could understand from the docs, the use of "ICDx.h" and BoostLink switch "-rt", do reserve the necessary resources for the ICDx debuggers.

    And what about debugging, can it be done from the Sourceboost IDE or do I have to use MPLAB?

    Including the ICD2.h or ICD3.h in a source file in the project reserves all the required RAM locations needed by ICD2 or ICD3. The -rt linker option prevents linker from using the code spaced that ICD2/ICD3 needs to use for the code it installs on the target device.

     

    PS: By the way, I'm having a really good time with SB and Novo, even without doing any In Circuit Debugging.

    Nice to hear :-)

  21. JorgeF,

    When using BoostC integrated in MPLAB, the build configurations BUILD / RELEASE are not available and I couldn't find a way to activate/configure this functionality.

     

    Do I have a problem with my instalation?

     

    I'm afraid I wouldn't be able to use ICD tools (Pickit3 or ICD3) without this feature.

    The build configurations Debug/Release are a function of the SourceBoost IDE.

    These simplify the addition of code used in a debug build by allowing use of #ifdef _DEBUG and #ifndef _DEBUG to conditionally compile code.

     

    They do not affect use of ICD2 or ICD3 header files.

     

     

    Regards

    Dave

×
×
  • Create New...