Jump to content
The search index is currently processing. Activity stream results may not be complete.

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 < 768) val = my_data_1[addr-512]; .. etc return val; } (I would post my actual code but I'm a pro user and it's deemed "customer confidential"...) However, I find that when the value of addr causes the PIC ROM data address to cross the 0x0800 program memory boundary, the routine returns 0x00 for all values accessed above that boundary.... An example; my rom char strings start at 0x065C in PIC ROM - so the first string 256 bytes reads ok. However, the second string is only readable up to addr = 0x1A4 (ie, the bytes in my+_data_1[0xA4). This value is on the PIC ROM address boundary of 0x800. Any reads above there return 0x00.... If I had to guess, I would think that the compiler _rom_get routine was broken ??? Has anyone else seen this problem? Or am I doing something wrong ?!?! (I would like to write my own rom_get routine, to avoid the 256 byte restriction for arrays Program ROM. However, I then can't find a way to access the base address of the my_data_0, _1, _2, etc arrays. I could use #pragma to store the data in the first place, (or use @0xabcd to fix the base addresses at a know location) I I suppose, but it doesn't really answer the question why rom_get appears to be acting strangely...
  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 0xAA 283A 6EA7 MOVWF gbl_eecon2 283C 010F MOVLB 0x0F <----- 283E 8B3F BSF gbl_rtccfg,5, 1 This bank switch instruction isn't necessary and it breaks the RTCCFG sequence which consequently fails. Is there *any* way of getting the compiler to not generate this bank switch? I'm using Sourceboost IDE version 7.30 with C compiler 7.30 and linker 7.30 under Windows 7
  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). Is it possible by simply adding this common directory to the search path of each project in MPLAB X(File->project properties->general->source folders)
  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> //Those pesky config bits! #pragma config OSC = HS #pragma config WDT = OFF #pragma config PWRT = ON #pragma config PBADEN = OFF #pragma config BOREN = OFF #pragma config LVP = OFF #pragma CLOCK_FREQ 20000000 extern void init_display(void); extern void cls(void); extern void lprint(char*); extern void gotoxy(char,char); void main() { trisa = 255; trisb = 0; //Used by display char disp[80]; unsigned short value; //Value returned by conversion init_display(); clear_bit(portb,7); clear_bit (adcon0, CHS0); //AN0 clear_bit (adcon0, CHS1); // clear_bit (adcon0, CHS2); // clear_bit (adcon0, CHS3); // clear_bit (adcon1, PCFG0); //Just AN0 a to d set_bit (adcon1, PCFG1); // set_bit (adcon1, PCFG2); // set_bit (adcon1, PCFG3); // clear_bit (adcon1, VCFG0); //+ve ref clear_bit (adcon1, VCFG1); //0v ref set_bit (adcon2, ACQT0); //Aquisition time clear_bit (adcon2, ACQT1); // set_bit (adcon2, ACQT2); // set_bit (adcon2, ADCS0); //Clock clear_bit(adcon2, ADCS1); // set_bit (adcon2, ADCS2); // set_bit (adcon2, ADFM); //Justification set_bit(adcon0,ADON); //Turn on next: set_bit(adcon0, GO); wait: if(test_bit(adcon0, GO != 0)) goto wait; value = (ADRESH << 😎 | ADRESL; //The emoji should read << 8, followed by a right bracket! gotoxy(1,1); sprintf(disp, "Value is: %u.", value); lprint(disp); goto next; }
  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 toolsuite. It's probably not being updated or improved but it is free (well, donation-ware anyway) and is adequate for my (amateur) electronic projects.
  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 MOVLW 0xFE 0029 058C ANDWF gbl_LATA, F PORTIO.0 = 1; 002A 0020 MOVLB 0x00 002B 142A BSF CompTempVar614,0 002C 182A BTFSC CompTempVar614,0 002D 2830 GOTO label3 002E 0022 MOVLB 0x02 002F 100C BCF gbl_LATA,0 0030 label3 0030 0020 MOVLB 0x00 0031 1C2A BTFSS CompTempVar614,0 0032 2835 GOTO label4 0033 0022 MOVLB 0x02 0034 140C BSF gbl_LATA,0 0035 label4 Same code compiled with BoostC: PORTIO |= 1; 001C 140C BSF gbl_LATA,0 PORTIO &= ~1; 001D 100C BCF gbl_LATA,0 PORTIO.0 = 1; 001E 140C BSF gbl_LATA,0 Even with optimization to set to 0, BoostC gives: PORTIO |= 1; 001D 140C BSF gbl_LATA,0 PORTIO &= ~1; 001E 30FE MOVLW 0xFE 001F 058C ANDWF gbl_LATA, F PORTIO.0 = 1; 0020 140C BSF gbl_LATA,0 Note: this code is nothing more than a test. Attached you have the test file. newmain.c
  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 communication and my send_uart_char() , send_uart_str(), etc functions are used <a lot>. If this is a new limitation, then it is going to cause me a deal of pain with my existing libraries and programs - as a "pro user" I have to maintain these for a customer base.... Anyone else experiencing this problem? Pavel, any comments on this? Could a compile switch be created to allow bigger call tables to be used? Migration to Chameleon - ok, a possibility - but from what I have seen on the forum it is by no means "straightforward" - again this is going to cost me significant work time...
  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...