Jump to content

All Activity

This stream auto-updates

  1. Earlier
  2. Well, I think I may have fixed this. Secret is to use a MOVFF instruction to load data into the RTCCFG register // Unlock the RTCCFG register rtccfg_tmp = rtccfg; set_bit(rtccfg_tmp, RTCWREN); asm { movlw 0x55 movwf _eecon2 movlw 0xAA movwf _eecon2 movff _rtccfg_tmp, _rtccfg } rtccfg_tmp is a global unsigned char and because the MOVFF instruction doesn't need a bank switching register the compiler doesn't put a MOVLB instruction into the middle of the load sequence.
  3. I'm getting this exact problem when trying to enable the RTC on the PIC18F27J53. This requires an eeprom2 = 0x55; eeprom2=0xAA; set_bit(rtccfg, RTCWREN); sequence and whatever I do I get the spurious movlb 0x0f instruction in the middle of the sequence, which breaks the operation. I've even tried asm { movlw 0x55 movwf _eecon2 movlw 0xAA movwf _eecon2 bsf _rtccfg,RTCWREN } Which generates 2834 0E55 MOVLW 0x55 2836 6EA7 MOVWF gbl_eecon2 2838 0EAA MOVLW 0xA
  4. Hi It shouldn't be a problem, AFAIK it can be done with any toolchain and/or IDE out there. For header (.h) files you just need to put the path in the #include statement. For source files (.c) you have to provide those extra paths to the makefile. Besides this universal steps, In MPLABX, specifically, you can include extra folders in your project tree. Best regards Jorge
  5. This subject as discussed many years ago before the times of MPLAB X, and as far as I understand did not work properly. But now sourceboost compiler is an "approved" MPLAB x compiler, so before I try experimenting maybe someone already did this and can comment: If I have several projects -each in its own directory I have several c and h files which are common to al projects and I want them to be located in their own directory (and maintain only one copy of them, as opposed to have them in each of the projects directory and copy-paste files each time I make a change in them).
  6. Hi there. I'm reasonably aufait with pic devices, but I seem to have hit a wall doing basic a to d conversion. I'm using a 18F4520, and using the AN0 input. I include the code here. I've broken the adcon0-2 registers to individual bits, hopefully making things more readable (or maybe not)! The problem is, the the display doesn't reflect the position of the variable resistor I have on AN0 (which obviously has the ends tied to Vdd and Vss respectively. Nothing changes when I move the vr too! I'm missing something obvious here. #include <system.h> #include <stdio.h> /
  7. Yes, for whatever reason Chameleon removes the high byte of the configuration word. (e.g. If the config word should be 0x3F30 the resulting Chameleon hex file will show it as 0x0030.) I did not discover this until I started flashing my MCUs and found that none of the configuration fuses were correct. And a second point: On the average Chameleon will produce a hex file about 1.5 times larger than one produced by BoostC. Again, I don't know why it does this. (It's supposed to be an optimizing compiler.) This is only my experience from using it. Needless to say I use BoostC as my toolsui
  8. Hi AFAIK CoostC/C++ never supported 16bit or 32bit devices, only 8bit ones. Best regards Jorge
  9. I wold like to use this for C++ for a PIC18F66J94 I have - and possibly the PIC18F87J94 device. Just wondering how often they update support.
  10. I've just found your compiler and was playing with it to see if it was any good. And I found something strange in Chameleon compiler. I was testing very basic code to set and reset bits, chars and structs (targetting PIC16F1825). When the code is compiled with Chameleon, it uses 85 words, in BoostC i takes 47 to 49 words (depending on optimization options). Chameleon size does not change with optimization and code is very bad for some bit manipulation code: PORTIO |= 1; 0026 3001 MOVLW 0x01 0027 048C IORWF gbl_LATA, F PORTIO &= ~1; 0028 30FE
  11. hello i am new here boost compiler support dspic 33 MCU ?
  12. Hi, since using BoostC 8.01 I have come across the message "Can't fit avoid code boundary code....". I have followed a couple of (Novo RTOS) posts about this (or similar) message and it seems that this incarnation of the compiler now builds a table (of return addresses?)for each call of a function. Because the table is only 256 entries long it effectively limits the number of times the function can be called (to 256). Is my understanding correct so far? 256 calls may seem to be "a number unlikely to be exceeded" - but in my code and on bigger processors I use a lot of serial
  13. Oh, silly me!! The clue is in the message "inline". Doh! "Problem" solved...
  14. I have never used the PIC "sleep" instruction until now. But in BoostC Ver. 6.97 I get the error message 'can't get address of inline function sleep' I'm at a loss to understand what this means. Hopefully someone may be able to point me in the direction of an answer?
  15. What's new about 8.01 version besides being free ? I have boostc++ pro licence.
  16. Delayed reply, even thus maybe helpfull for others As Reynard said, why not... #include <system.h> // zero at the end, to end of string detection rom char *test_txt = "\n\rMatrix Controller Test mode\n\r\0"; void puts( rom char* c ) { for( unsigned char i=0;;i++ ) { while( !txsta.TRMT ) clear_wdt(); if( c[i] != 0 ) { txreg = c[i]; } else break; } } void main( void ) { puts( test_txt ); while(1); } regards
  17. Hi For sure I would like to have a linux version of BoostC. I have a licenced V7 and its one of the few things that makes me keep a Windows partition on my laptop. If possible, fully integrated in MplabX Best regards Jorge
  18. Hi Rob, You don't have any test for the end of string null when it comes along. Cheers Reynard
  19. Hi I am trying to print a rom string to the serial port, the strings are defined thus: rom char *test_txt = "\n\rMatrix Controller Test mode\n\r"; rom char *txt1 = "Connect an 80R 10W resistor across pins 11 and 19\n\r"; rom char *txt2 = "Press Enter when ready\n\r"; i use the following call: puts (test_txt); where puts() is: void puts(rom char* c) { char cc; char i; for( i = 0; cc = c[ i ]; i++ ) putc( cc ); } void putc(char c) { txsta.TXEN = 1; txreg = c; while (txsta.TRMT == 0) clear_wdt(); } But all of the strings are pri
  20. PC date and time (of compiling) can be used, using the following: rom char *build_date = __DATE__ ; // 11 chars. Eg: "Aug 01 2018" rom char *build_time = __TIME__ ; // 8 chars. Eg: "12:45:30" You can access build_date and build_time using [ ]
  21. Just wondered if there is any method by which PC real time may be imported into BoostC?
  1. Load more activity
  • Create New...