Jump to content

All Activity

This stream auto-updates

  1. Earlier
  2. I need to store a large amount of (read-only) data (~2k) so I cant really use RAM (I would use most of the available RAM this way!). What I have done is: 1) Created several rom char* strings, eg, rom char* my_data_0, my_data_1, my_data_2, etc, and initialised them at declaration with 256 byte chunks of my data 2) created an access routine which says: unsigned char get_my_data(unsigned int addr) { unsigned char val; if (addr < 256) val = my_data_0[addr]; else if (addr < 512) val = my_data_1[addr-256]; else if (addr <
  3. 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.
  4. 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
  5. 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
  6. 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).
  7. 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> /
  8. 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
  9. Hi AFAIK CoostC/C++ never supported 16bit or 32bit devices, only 8bit ones. Best regards Jorge
  10. 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.
  11. 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
  12. hello i am new here boost compiler support dspic 33 MCU ?
  13. 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
  14. Oh, silly me!! The clue is in the message "inline". Doh! "Problem" solved...
  15. 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?
  1. Load more activity
  • Create New...