Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Pavel

  1. We always wanted to improve the existing rs232 driver that is included into SourceBoost installation. And here it is. A new driver created from scratch. Please try it and let us know. If all looks good it will be added to SourceBoost installation: SourceBoost UART driver documentation and Sample project including the driver code Pavel
  2. We are in process of rewriting the uart driver that is included into SourceBoost. Will make it available soon. Anybody wants to beta test it? Regards, Pavel
  3. There are no built-in 24 bit data types. As far as we know there are no PIC compilers that have 24 bit data types. SourceBoost IDE does not reopen files that we open in previous session. We plan to add this feature eventually but this is a low priority item and it won't happen soon. Regards, Pavel
  4. We now have a release candidate we are very pleased with. We do some final testing and plan to release it later this week if no problems are found. This release candidate does include PIC16F1x support. Regards, Pavel
  5. Eeprom on PIC operates with 8 bit long data. To store 16 bits in eeprom one must manually split it into 2 8-bit numbers. Boost compilers v6 are somewhat limited in data argument computation and don't allow expressions in pragma DATA arguments. v7 will behave better in this area. Regards,. Pavel
  6. Yes PIC16F1827 will be supported starting from soon to be released 6.97. Regards, Pavel
  7. Exit SourceBoost IDE, start registry and navigate to HKCU/Software/SourceBoostIDE/IDE and delete all Debug/Edit Bar sections. Start IDE and it should use its default window layout. Regards, Pavel
  8. From Novo RTOS manual "The lower the task priority value, the higher the task priority. A task with a priority value of 0 (zero) has the highest priority. Only the highest priority tasks in the run queue are executed when another task yields." If that's not the case than either the document is wrong or there is a bug in Novo software. Regards, Pabel
  9. I could not reproduce the problem. I renamed lcd_driver.h into lcd_driver2.h and changed include in the lcd example from SourceBoost installation to include lcd_driver2.h instead of lcd_driver.h. Project still compiles and links without any problems. Includes are handled by preprocessor that follows certain rules and doesn't care about any particular files. I'm pretty sure the problem you describe is caused by something else. Can you try to do the same on the lcd sample project and let us know the results. We can also take a look at your project if you send it along with lcd_river2.h file to support@sourceboost.com. Regards, Pavel
  10. Editing a file and compiler not being able to find it sound like completely unrelated things. If you place the edited file into the include folder in the SourceBoost installation directory and use the angle braces include statement to include it into your sources compiler should find it. Or alternatively you can save edited file anywhere and use double quote include and full path to the file. This should work too. Regards, Pavel
  11. I'd blame some background task that runs on the computer and that upsets the SourceBoost protection system. The way to test this is to try to stop or kill processes running on the computer one by one and keep checking if access violations still happen. Regards, Pavel
  12. This is a problem in MPLAB API for third party plugins. We discussed it with Microchip and it looks like it will be fixed by June 2010. Meanwhile you can build outside of MPLAB using make generated by SourceBoost IDE (either from IDE or command line). Regards, Pavel
  13. Yes this is exactly what makes it fail. Without quotes MPLAB thinks that the library directory is "C:\Program" and whatever goes ater it (in this case "Files\SourceBoost\Lib") is an input file that should be linked to the resulting code. Regards, Pavel
  14. What do you mean by "instructions extensions"? Regards, Pavel
  15. Probably because of a bug in BoostC. I don't know yet. Will investigate. Regards, Pavel
  16. Something like this will do: #include "system.h" char myArray[15][6]; void myFunc(char*); void main(void) { myFunc(myArray); } void myFunc(char *arry) { unsigned char i; for( i = 0; i < 15; i++ ) SsTxt(&arry[i*6]); } or #include "system.h" char myArray[15][6]; void myFunc(char*); void main(void) { unsigned char i; for( i = 0; i < 15; i++ ) myFunc(myArray[i]); } void myFunc(char *text) { SsTxt(text); } Regards, Pavel
  17. This sounds rather serious. I do run SourceBoost on several computers (XP and Vista) and don't have any access violation problems. Can you check if you can launch the following programs from command line (open the command prompt window, navigate to SourceBoost installation directory and launch the programs from there from command line): boostc_pic16.exe, boostlink_pic.exe, pp.exe, ide.exe, preg.exe. Please send your results to support@sourceboost.com Regards, Pavel
  18. That's because the identifiers you call "register names" are in fact defines located in system header files (try to comment out system.h include and this line will compile just fine). When you declare a variable like: char GPIO @ 5 ; C preprocessor will transform it into: char 0x0005 @ 5 ; and when this transformed line gets to the compiler it will report an error because it doesn't make sense from C language point of view. The convention used in BoostC system headers is: variable names in small and defines in capital letters. This is just a convention that could have been done differently but because most of C and C++ programmers outside of PIC world use it we decided to use it as well when we were creating system headers for BoostC. Regards, Pavel
  19. Starting from February 1st 2010 all customers who bought a 6.x compiler are entitled for a free upgrade to 7.x release of similar product. Regards, Pavel
  20. IDE version should match the compiler (you'll see compiler version printed in your output window when you compile your code). The version you use is far too old. We suggest to try latest 6.96 Regards, Pavel
  21. What compiler of what version and which PIC do you use? Pavel
  22. Only marked (red) items are relevant to the API changes. Others were already present in the plugin template project for v6 available from SourceBoost web site. The order of the functions in .def file is not important. IDE dynamically loads necessary functions. It's important for the numbers to be consecutive though (this is MS Windows requirement). The HWND function argument acts as plugin instance ID for plugins that allow multiple copies. The intended usage model is to create a map of plugin data that is unique to a particular plugin instance and use HWND argument that is passed to the plugin creation function as a key. This way when any other function that has the HWND argument is called plugin data can be found using the value of HWND. Plugins that allow only one copy can ignore the HWND argument. This was one of the goals. To make new API close to the existing one as much as possible. If IDE v6 tries to use plugin v7 it will not load. Same happens if IDE v7 will try to use plugin v6. Nothing should crash. Maybe it was something else in your case? This is a bit tricky and maybe not worth the troubles. We plan to look at this before 6.97 goes from beta to final. Regards, Pavel
  23. We changed plugin API in SourceBoost v7 to support multiple plugin instances. You'll need to update your plugin when v7 is out. A template project that uses the updated plugin API can be downloaded from here. Regards, Pavel
  24. The plan is to make 7.0 pre-release available and go for 7.0 release when the pre-release looks good. It may happen that pre-release will look good right from the start but it may also happen that several pre-releases will be required. Pavel
  • Create New...