Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Pavel

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. Please send the compiler output along with your license name and key to support@sourceboost.com Regards, Pavel
  8. 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
  9. EOF stands for End Of File. This error means that a comment starts (with /*) but never ends (there is no matching */). Regards, Pavel
  10. The problem with the code is that it assumes that 4 is same as '4'. Regards, Pavel
  11. W can't be accessed from C on PIC16. On PIC18 this can be done using a variable mapped to WREG register. Regards, Pavel
  12. 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
  13. The problem has been fixed. Fix will be available in the next release. thanks for reporting. Regards, Pavel
  14. 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
  15. 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
  16. 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
  17. No this problem is not fixed yet Regards, Pavel
  18. SourceBoost v7.10 is now available from official download page http://www.sourceboost.com/CommonDownload.html Regards, Pavel
  19. 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
  20. 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
  21. STATUS and C are defined as integer constants so after preprocessing compiler will see "asm bcf 0x0003,0x0000" which is not valid assembly. Take a look at the BoostC help as the "Inline Assembly" chapter. Pavel
  22. Sorry still no good. Eeprom header already checks this but it doesn't help linker that can't find 'eeadrh' variable. Regards, Pavel
  23. Any idea how to fix this without creating a new lib file for PIC18 that don't have EEADRH? Regards, Pavel I would have thought that was more your job rather than mine but since you ask how about adding the dummy EEADRH definition to all of the appropriate PIC18 header files. That would stop the linker from complaining and the user would not have to waste a day scratching his head wondering why the code doesnt compile. Not sure I understand your suggestion. Can't see how a dummy EEADRH definition can help. Linker wants a variable called 'eeadrh' when links to eeprom library. Regards, Pavel
  24. Any idea how to fix this without creating a new lib file for PIC18 that don't have EEADRH? Regards, Pavel
  25. SourceBoost v7.10 release candidate is available to download from: http://www.sourceboost.com/CommonDownload/Binaries/SourceBoostV7.10RC/sourceboostv710.exe What's new: MplabX plugin updated to work with Mplab X 1.20 BoostBuild is now installed as a service Added support for new targets PIC16f1508, PIC16lf1508, PIC16f1509, PIC16lf1509, PIC16f1782, PIC16lf1782, PIC16f1783, PIC16lf1783, PIC16F720, PIC16F721, PIC16F722A, PIC16F723A Fixed several issues in compiler, simulator and ide reported on the forum Let us know if you find any problems. Regards, Pavel
  • Create New...