Pavel

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

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

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

Of course there are. Look into <Your SourceBoost Samples folder>\Basic\novo. There are 5 sample Novo projects in Basic there. Regards, Pavel

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

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

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

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

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

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

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

Please send the compiler output along with your license name and key to support@sourceboost.com Regards, Pavel

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

EOF stands for End Of File. This error means that a comment starts (with /*) but never ends (there is no matching */). Regards, Pavel

The problem with the code is that it assumes that 4 is same as '4'. Regards, Pavel

W can't be accessed from C on PIC16. On PIC18 this can be done using a variable mapped to WREG register. Regards, Pavel

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

The problem has been fixed. Fix will be available in the next release. thanks for reporting. Regards, Pavel

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

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

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

No this problem is not fixed yet Regards, Pavel

SourceBoost v7.10 is now available from official download page http://www.sourceboost.com/CommonDownload.html Regards, Pavel

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

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