Jump to content


  • Content Count

  • Joined

  • Last visited

Everything 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. Yes there should be. We'll add this into our todo list. 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. What is the filename for the buildlog? There is no log file unless you redirect it to a file yourself. Just post the content of the output window with the build log. Regards, Pavel
  4. Of course there are. Look into <Your SourceBoost Samples folder>\Basic\novo. There are 5 sample Novo projects in Basic there. Regards, Pavel
  5. 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
  6. Please post your build log. Than it will be clearer what's happening. Yes that's correct. Every time the 'build' command is issued a makefile is generated and this included building all include dependencies. Regards, Pavel
  7. Compilation on a remote server is activated by using the -pp compiler command line argument. Don't use -pp in compiler command line if you don't need remote build. Regards, Pavel
  8. BoostC++ is not a full blown C++ compiler and supports only a subset of the C++ language. This particular error that you reported was caused by the operator overloading that is not supported by BoostC++. Regards, Pavel
  9. The boostbuild software was developed for remote compilation. Link is always local. And if you always build locally you don't need to use boostbuild. So I don't quite understand what's the problem is. Regards, Pavel
  10. Please check that the i2c_bitbang.c is not linked into more than one library (i.e. into i2c_bitbang.lib and another) Regards, Pavel
  11. 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
  12. Please send the compiler output along with your license name and key to support@sourceboost.com Regards, Pavel
  13. 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
  14. EOF stands for End Of File. This error means that a comment starts (with /*) but never ends (there is no matching */). Regards, Pavel
  15. The problem with the code is that it assumes that 4 is same as '4'. Regards, Pavel
  16. W can't be accessed from C on PIC16. On PIC18 this can be done using a variable mapped to WREG register. Regards, Pavel
  17. 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
  18. The problem has been fixed. Fix will be available in the next release. thanks for reporting. Regards, Pavel
  19. Output of almost every compiler release will be slightly different so if you want to get identical hex file I see no other choice than to go the exactly the same release number that was originally used. And from that point you may upgrade to the latest version. Regards, Pavel
  20. Mplab X SDK doesn't mention how to do this. We contacted Microchip and hopefully will be able to resolve this issue. Thanks for reporting. Regards, Pavel
  21. 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
  22. No this problem is not fixed yet Regards, Pavel
  23. SourceBoost v7.10 is now available from official download page http://www.sourceboost.com/CommonDownload.html Regards, Pavel
  24. OK for now problem with eeprom code is fixed in the documentation. We added a note into eeprom API chapter into compiler help about library use with PIC18 that don't have EEADDRH. Pavel
  25. 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...