Jump to content

Pavel

Administrators
  • Posts

    1,471
  • Joined

  • Last visited

Posts posted by Pavel

  1. There is no BoostBuild used with the compiler command line you posted. If you compile from SourceBoost IDE the delay may be when IDE looks for dependencies before build (as suggested in one of the posts). Compiler start also take a bit of time that depends on you computer power. So seems you do everything right.

     

    Regards,

    Pavel

  2. I found the examples. However, why aren't any of these examples (or the location of these examples) not in the PDF documentation? There should be at lease one example of the BoostBasic & Novo in the Novo PDF document.

     

    Yes there should be. We'll add this into our todo list.

     

    I search the program installation folder and the PDF for examples. I didn't know they were put in "My Documents" folder. If I had known about these examples to begin with it would have made a big difference.

     

    Location for the examples is specified during SourceBoost installation and you can change it to any place on your computer. Maybe you just missed this.

     

    Regards,

    Pavel

  3. There are a few problems with your code:

     

    - don't use the 'call' keyword with Novo calls

    - incorrect way to create Novo task (check examples from SourceBoost installation for the correct usage)

    - incorrect task function signature (check examples from SourceBoost installation for the correct usage)

     

    The best way to start is to use examples from SourceBoost installation as starting point.

     

    Regards,

    Pavel

  4. I dont have that set, but there is still a 3sec delay after i click compile.

     

    When i click link, it starts at once, no delay.

     

    Please post your build log. Than it will be clearer what's happening.

     

    This is a bit of a long-shot, but could it be that the delay you are refering to is the processing of "make"?

    I've also noticed this delay but allways assumed that it was "make" verifying dependencies and deciding what needs to be compiled and what doesn't.

     

    Yes that's correct. Every time the 'build' command is issued a makefile is generated and this included building all include dependencies.

     

    Regards,

    Pavel

  5. From the build output that you emailed us it looks that it is the linker who restricts the output. This happens not because the registration failed (it looks that it was successful indeed) but because you try to link files that were compiled with unregistered compiler. You need to do just what linker output suggests: recompile source files from your project using registered compiler.

     

    Regards,

    Pavel

  6. One way to do it using the built-in delay function would be to compile 2 copies of the code (one at each clock speed) into separate obj files (with different names), and then link both of them in using the linker.

     

    This particular approach won't work. The delay functions are so special that it's the linker, not compiler who generates code for them. Things are done this way to make sure that bank and code page switches (the compiler doesn't know anything about) won't affect the timing of these functions.

     

    Regards,

    Pavel

  7. There are couple of issues in your code. The source of the errors you see is in the backslashes you left in the macros:

     

    #define uart1Init \ rs232Init<PIE1,TX1IE,PIE1,RC1IE,RCSTA,CREN,RCSTA,SPEN>

    _________________^^^________ what is this one for?

     

    Another problem that won't let you compile after you fix the backslashes is that the system include is not the first include in your code. This will cause all kind of problems as the code from uart_driver.h that you include before system.h uses all kind of information from this system header.

     

    Regards,

    Pavel

  8. May I ask if the MOVIW and MOVWI assembly language instructions for the enhanced mid-range devices, like the 16F1828, are implemented in BoostC v7.05 please? So far I can't get it working...

     

    Both MOVIW and MOVWI instructions are supported (as well as all other instructions in mid-range device instruction set). The syntax is same as in datasheet:

     

     

    asm MOVIW ++0
    asm MOVIW --0
    asm MOVIW 0++
    asm MOVIW 0--
    asm MOVIW -17[0]
    

     

    same as

     

     

    asm MOVIW ++FSR0
    asm MOVIW --FSR0
    asm MOVIW FSR0++
    asm MOVIW FSR0--
    asm MOVIW -17[FSR0]

     

    Note that FSR here is not the name of a register (as these instructions work only with fsr registers) but part of the instruction literal.

     

    Regards,

    Pavel

  9. ...Not sure what is happening...

     

    OK lets break our thinking process into steps:

     

    1. assembly instructions operate on PIC registers

    2. in BoostC registers are mapped to variables with fixed addresses (see Register mapped variables in BoostC help)

    3. variable that is mapped to STATUS register is called status (see PORTB vs portb or notes about naming convention in BoostC help)

    4. when referencing to a C variable from built-in assembly variable name must be prefixed with underscore (see Variable Referencing in asm in BoostC help)

    5. all together gives us asm bcf _status,C

     

    Pavel

×
×
  • Create New...