Jump to content

Pavel

Administrators
  • Content Count

    1,466
  • Joined

  • Last visited

Everything posted by Pavel

  1. Change log: fixed ide problem when words TODO or FIXME in the sources caused file safe problems fixed BoostC++ integration into ide that was broken in 7.10 release fixed settings and build problems in several examples supplied in the installation fixed watch window for very big values for unsigned long type fixed problem when debug session wasn't closed correctly when another workspace was opened during debugging boostlink.exe renamed into boostlink_picmicro.exe installation modified to check DEP settings only if wmic.exe is present installation updated to include vc2008 redistributives removed -swcs linker option prom proj file (this option is stored in config file and is auto-generated if missing in novo projects) re-built lcd_helper.lib library from BoostBasic examples using latest tools open workspace now lets user select from both workspace and project files ide changed to store extra options in config file updated ide check for novo based projects that have missing -swcs linker option fixed random ide crash fixed bug when ide did not enclose prebuild.bat and postbuild.bat commands into double quotes if their path contained spaces fixed (disabled?) crash under Windows 7 64bit "The activation context being deactivated is not the most recently activated one" fixed bug in error reporting when target config file was not found PIC18 eeprom library split into 2: 8 and 16 bit addressing fixed Novo bug: tasks executed when not expected. Caused by incorrect capture to maximum task priority. added #ifndef and #endif into system headers to prevent multiple inclusion of header files. added sorting for files in the workspace tree updated mplabx plugin fixed problem when compiler was reported an error for function pointer declaration when one extern and another not extern were used fixed problem in IDE when wizard didn't work if there was no active project (i.e. in empty workspace) fixed problem when release build didn't parse empty bit names in config file correctly (i.e. BitNames = "","","","NOT_TO","NOT_PD","Z","DC","C" fixed problem when optimisation (dead code removal) was being applied when it shouldn't. fixed linker bug when code page switch lost in some functions containing asm code fixed problem when setup didn't stop build service and this caused error later when service file was supposed to be overwritten fixed problems with expressions enclosed into parentheses increased various preprocessor limits like macros size or include depth
  2. SourceBoost V7.11 release candidate 1 is available to download from http://www.sourceboost.com/CommonDownload.html Regards, Pavel
  3. Look at the bright side. Now you are an LCD expert. Regards, Pavel
  4. ccpr1 is defined as char for backward compatibility with other PIC types that have this register one byte long. Same approach is used for all other registers in system headers. To access 16 bit register two other variables are defined just after ccpr1. These are ccpr1l and ccpr1h that are mapped to low and high byte of the register and these are the ones you need to use. Regards, Pavel
  5. We do this everywhere but must have forgotten this case. Will investigate and try to fix in the coming release (which was due by Christmas but we ran into some problems that need to get fixed before the release, sorry about the delay) Regards, Pavel
  6. We were able to reproduce this problem. Now fixed. Fix will be available in the coming release. Regards, Pavel
  7. I could not reproduce the problem. Here is what I did: 1. add file to an existing project 2. open it inside SourceBoost IDE 3. add some text 4. save 5. check if the changes appear in the file using an outside editor (ok) 6. do more changes in the file from inside SourceBoost IDE 7. close the file (this will make IDE ask if the changes need to be saved, answer yes) 8. check if the changes appear in the file using an outside editor (ok) Any suggestions how to reproduce the problem? Regards, Pavel
  8. Currently it's not possible to disable .tree file generation by linker but you can try to delete this file from postbuild.bat (see the 'Build' chapter in users manual). Let us know if this works. Regards, Pavel
  9. There was a bug in MplabX related to full re-build (in the MplabX generated makefiles it added dependency to a .mk file into nbproject/Makefile-default.mk file and re-generated this .mk file at every build) but it was fixed several months ago. Apart from that we are not aware of any other problems. Maybe you can check the makefiles generated for your project and if timestamp of the dependency file changes after every build? Can anybody else report about their MplabX build experience? Regards, Pavel
  10. We decided to split the eeprom library for PIC18 into 2: one that uses 8 bit addressing and another that uses 16. Both will be part of 7.11 release and are attached to this post. The header file hasn't changed. Regards, Pavel eeprom.zip
  11. We investigated this issue and it looks like there is some build problem in the eeprom library included into the 7.10 release If the same library is re-built it works as expected. I will attach an updated library from the coming 7.11 release to this thread later today when I get access to my development system. To call eeprom_write with 16 bit address just make the call with 16 bit long first call argument like: #include <system.h> #include <eeprom.h> ... //this will call eeprom_write( unsigned short, unsigned char ) eeprom_write(0x100, 0x55); //this will call eeprom_write( unsigned char, unsigned char ) eeprom_write(0x10, 0xAA); Regards, Pavel
  12. Yes you can. The library takes advantage of the function overloading. The lib file contains both functions: one that uses 8 bit address and another that uses the 16 bit one but the header file only declares one of those based on the EEARDH definition. This way all external to the library code can use only one of these functions. Regards, Pavel
  13. Me neither but I guess some do and compilers should allow this (i.e. gcc) Regards, Pavel
  14. Yes as you correctly noted in a following post it's the linker who will report an error if a variable is defined in more than one place. This might look a bit strange but the rationale for this kind of behaviour is that the code may be structured so that an 'extern' statement will be inside a header file that is included into all source files and one of these source files will have the actual variable definition: common.h extern int n; source1.c #include "common.h" ... source2.c #include "common.h" ... source3.c #include "common.h" int n; ... We plan to have a new release within next 2 weeks (sometimes before Christmas) Regards, Pavel
  15. Function pointer is just another kind of a variable and should behave as other variables do. So if code like this: extern int n; int n; compiles, similar code that uses function pointers should compile too: extern void (*foo)(void); void (*foo)(void); This issue will be fixed in the coming release. Regards, Pavel
  16. The cause of this problem is in the way how IDE decides if wizard is supported by the toolsuite used for the active project. In an empty workspace there is no active project and because of this IDE disables the wizard. We have fixed this behaviour so that id there is no active project IDE will still call the BoostC wizard. The fix will be available in the coming release. Regards, Pavel
  17. Division (as well as multiplication and remainder) is based on one of the division function defined in boostc.h and extended internally by the compiler for signed types. Regards, Pavel
  18. We were able to reproduce the problem. Seems to be a bug. We will investigate. Regards, Pavel
  19. 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
  20. 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
  21. 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
  22. Of course there are. Look into <Your SourceBoost Samples folder>\Basic\novo. There are 5 sample Novo projects in Basic there. Regards, Pavel
  23. 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
×
×
  • Create New...