Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Pavel

  1. Sorry no progress. More critical and urgent issues keep coming up. Regards, Pavel
  2. Support for complex constant expressions in built-in assembly has been added and will be available in the next release. Regards, Pavel
  3. We investigated the problem and found bug in the IDE where filters that were supposed to force IDE to open files with pre-defined extensions (like .c or .h) were broken. This problem has been fixed and fix will be available in the next SourceBoost release. Meanwhile please download IDE patch from the link below and place it into your SourceBoost installation directory (it will overwrite the original IDE.exe file). Let us know if it works for you. (This link will become invalid when the next release after v7.0 is out) http://www.sourceboost.com/CommonDownload/Fixes/IDE.exe Regards, Pavel
  4. Multiplication and division will generate an error. Only addition and subtraction will be accepted. We'll put support for more operations into our todo list. Regards, Pavel
  5. Does this happen when you double click on a file that is in the project panel? When this happens IDE checks if there is a program associated with the extension of this file. If there is one it will be used to open this file. For example one can have a pdf file to be included into a project and if user double clicks on this file IDE will launch file associated with the pdf extension (that is usually Adobe PDF Reader) Some of extensions like *.c or *.h should not be handled in this way and should be opened inside the IDE but it sounds like it does not happen in your case. We'll investigate. Meanwhile either use File->Open menu to open files or temporarily delete your current *.c and *.h associations. Regards, Pavel
  6. From BoostC++ help... Predefined macros _BOOSTC always defined _PIC16 defined for all supported PIC12 and PIC16 targets _PIC16x defined if PIC16 extended instruction set is used (PIC16F193x and alike) _PIC18 defined for all supported PIC18 targets Regards, Pavel
  7. Please send a simple project that demonstrates the problem to support@sourceboost.com Regards, Pavel
  8. Unlimited number of constant offsets with + and - operations can be used in assembly operands. What kind of expressions are you looking for? Regards, Pavel
  9. We still need to compile all the changes. From the top of my head here are some: Support for multiple projects in a workspace Much better debugger (it can evaluate much more complex expression) Support for multiple plugin instances (minimal changes to plugin API) Optional parallel compilation Build server Optional support for big arrays and data objects(bigger that 256 bytes) Support for bit and bool return types Support for PIC16F1x architecture and instruction set Code generation and compile time are mostly unchanged. We work on a new compiler core that will change those. Regards, Pavel
  10. Should be. This code was designed to work with 20x4 displays. Regards, Pavel
  11. Here is link to some code that shows how to use 2 UARTs with template based UART driver. The SPI driver code uses almost identical API and should be user in similar fashion. The idea is that you use same template calls but with different arguments. For example spiInit for SPI1 will use registers related to SPI1 and same spiInit used for SPI2 will use SPI2 related registers for its template arguments. #define spi1Init spiInit<PIE1,SSP1IE,SSP1CON1,SSPEN> #define spi2Init spiInit<PIE3,SSP2IE,SSP2CON1,SSPEN> Now one can use code like spi1Init(); to initialise SPI1 and spi2Init() to initialize SPI2. The beauty of template based approach is that it can handle any number of SPI/UART/LCD/etc. connections without any code bloat. If there was a PIC that had 10 SPI ports or 100 UARTs these drivers could handle all of them. The scalability is just phenomenal. Look at templates as a kind of code generation tool. You have to supply some arguments (things inside the angle braces) and compiler will generate some code out of it. For every set of arguments different code will get generated. This will be done behind the scenes so you won't see the actual generated code but it will be there. Regards, Pavel
  12. ldc_driver.h should be included after the LCD_ARGS define (just like in the lcd.c sample from SourceBoost installation). This is important because this define is used by the code from lcd_driver file. Regards, Pavel
  13. We started working on SPI driver that has almost identical interface and code structure as UART driver publisher earlier on this forum. Because both drivers are template based they let as many UART/SPI connections as needed to be used in the code and still produce very efficient code. This SPI driver code is still untested but it is a good place to start with. Regards, Pavel spi_driver.h
  14. FYI: SourceBoost v7 has its plugin API changed to allow multiple plugin instances. The API changes are minimal (one extra argument in API calls that can be ignored if plugins are not interested in multiple instances). We do some final tuning and hope that v7 pre-release will be available really soon. Regards, Pavel
  15. Please describe what kind of activation problems you have in an email and send it to support@sourceboost.com Regards, Pavel
  16. Fixed. Thanks for reporting. Regards, Pavel
  17. High Priority interrupt is PIC18 specific. PIC18 has 2 interrupts, PIC16 just one. UART driver doesn't care from which it is used. Code that uses port D Data Latch is not related to UART driver functionality. It's used in the code to illustrate how to implement a heart beat led. Regards, Pavel
  18. For PIC16 helper macros for UART driver will look like: #define uart1Init rs232Init<PIE1,TXIE,PIE1,RCIE,RCSTA,CREN,RCSTA,SPEN> #define uart1TxInterruptHandler rs232TxInterruptHandler<PIR1,TXIF,TXREG,sizeof(txBuffer),TXSTA,TXEN,TXSTA,TRMT> #define uart1RxInterruptHandler rs232RxInterruptHandler<PIR1,RCIF,RCREG,sizeof(rxBuffer),RCSTA,CREN,RCSTA,OERR,RCSTA,FERR> #define uart1Rx rs232Rx<sizeof(rxBuffer)> #define uart1Tx rs232Tx<sizeof(txBuffer),TXSTA,TXEN> Regards, Pavel
  19. The best approach would be to re-think the algorithm of the code so that it won't need and rely on such non standard tricks. If different algorithm is not an option place the code you want to execute at interrupt end into a function with fixed address and use this address to return to. Regards, Pavel
  20. C language does not support label addresses. Some compilers like GCC use non standard language extensions to support this feature but BoostC does not. You are the first person who asked about it. Regards, Pavel
  21. Try to add this line into your sources: volatile char eeadrh; //dummy variable that is needed to link to eeprom library for PIC18s that don't have EEARDH register Regards, Pavel
  22. Starting from 6.97 support for both 8 and 16 bit addressing for eeprom library was added. For PIC18 that don't have EEADRH use: unsigned char eeprom_read( unsigned char address ); void eeprom_write( unsigned char address, unsigned char data ); and for PIC18 that do have EEADRH use: unsigned char eeprom_read( unsigned short address ); void eeprom_write( unsigned short address, unsigned char data ); Regards, Pavel
  23. Take a look at this topic. It includes latest UART driver and sample code for it. Regards, Pavel
  24. Compiler code generation isn't difference for different PIC18 targets. Can you send a simple project that demonstrates the problem to support@sourceboost.com. Regards, Pavel
  25. Similar story happens with general variable declaration. In C all declarations have to be at the start of a scope. C does not let you declare a new variable in an arbitrary place. C++ on the other hand allows this. BoostC compiler allows this as well but HiTech does not (what is often quite inconvenient to HiTech users). Regards, Pavel
  • Create New...