Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Aegis-tec

  1. From section 12.0 of the datasheet: "The inputs to the comparators are multiplexed with I/O port pins RA0 through RA3, while the outputs are multiplexed to pins RA4 and RA5." Did you turn off the comparators?
  2. The "A" version of the part has new feature which adds a hardware comparator (like an op-amp). The comparators default to enabled which overrides the ADC converter. The capture/compare you're referring to is part of the PWM peripheral on PORTC. Don't forget the differences in the ADCONx bits also.
  3. You don't need to touch the enable bits either. It appears that you're getting into the interrupt on either RBIF or TMR1IF. Just make sure you clear the flag bit before you leave the interrupt routine which you already are. In main() you're turning off the tmr1 interrupt before you sleep but this is not the case in the interrupt routine. Was this intentional?
  4. Boostc compiler and linker has never generated a map file. The best option is to look in the *.lst file to find where everything is. Regards Dave Yikes! Thanks Dave. What changed was my memory. The list files were there all along. I've been bouncing back and forth between BoostC and another tool for which I usually refer to the map file. The files didn't get lost, only my mind.
  5. I have a mystery. After using BoostC for some time all of a sudden there's no *.map file generated when my project compiles. I'm using MPLab 7.62, just as I have for a long time. I found a cryptic reference to a -m command line option to generate a "dependencies" file but there's no mention of what that is or how to use it. I've tried -m, -m1, -m On, all without success. I've never used this option anyway. What would cause the map file to not be generated? I liked my map file. I want it back.
  6. When you "upgraded" from the 16F876 to the 16F877A did you change the setup of the peripherals on PORTA to accomodate the differences between these parts? Theses two platforms are similar but there are many differences, most of which pertain to PORTA. For example, the 877A has a divisor bit for the ADC clock. The 877A also has a comparator module which defaults to enabled which overrides the ADC converter. There are other differences. Try setting up a watch window for the all of the peripheral control SFRs on PortA and post them. It's probably something simple like that. If the ADC input is fried it's far more likely to read 0x3FF or 0x000.
  7. Dave, Actually I do have a "newbie" problem on this very point. I'm having a problem under MPLAB. if I use system.h to bring in the PICmicro defines then I can't get my projects to compile because the following conditional within system.h doesn't work: #ifdef _PIC18LF24J10 #include <PIC18LF24J10.h> #endif //_PIC18LF24J10 Does BoostC evaluate #ifdef _PIC18LF24J10 as true if an 18LF24J10 is selected within MPLAB? i don't have to do anything else? Or do I have to setup a define of my own to signal the selection of 18LF24J10 to system.h? Something like : #define PIC18LF24J10 or #define _PIC18LF24J10 I'm still having a miserable time INCLUDEing system.h. Until I can get this working I'm using the following defines instead of system.h in my source code: #include <PIC18LF24J10.h> #include <BoostCPic18.h> #include <boostc.h> Will this work? What am I doing wrong? Sincerely, Steve
  8. How can this be done without including system.h? I have to be very careful about what I include. I've now got the touchy ICD2 to display my variables correctly. I hand-edited my own include file for the 18LF24J10 which system.h does not bring in automatically. What does system.h bring in to support the rom array syntax? Sincerely, Steve
  9. [font=Courier] Please let me know why the following simple example won't compile: rom char *temptbl = {0,1,2,3,4,5,6,7,8,9}; unsigned char i,j; j=0; i=temptbl[j]; error: failed to generate expression error: invalid operand 'temptbl[j]' error: failed to generate expression
  10. Sorry, my previous post posted too soon. Here's the code for the workaround using global variables: char apples; //these byte vraiables are declared globally char oranges; void foo (char); //function prototype for foo() main { foo (apples); //foo is called here, apples is passed by value } void foo (char apples) { oranges = apples; //when a watch window displays apples and oranges here } //oranges will have the correct value passed in apples //apples will display as garbage
  11. It is indeed a problem in Mplab but I found a workaround. It's a bit clumsy, but it works. You have to declare your variables globally then copy from one variable to another. For example: char apples; char oranges void foo (char); main { foo(apples); } void foo (apples) { oranges = apples;
  12. If you use a Microchip 18FxxJxx part you'll need to edit the .h file for the part you're using. The SourceBoost files are incorrect. The revised section is as follows: // The following is an assignment of address values for all of the // configuration registers for the purpose of table reads #define _CONFIG1L 0x00003FF8 #define _CONFIG1H 0x00003FF9 #define _CONFIG2L 0x00003FFA #define _CONFIG2H 0x00003FFB #define _CONFIG3H 0x00003FFD /////// CONFIG2L Options ////////////////////////////////////////////////// #define _IESO_OFF_2L 0x0000007F // Oscillator Switchover mode disabled #define _IESO_ON_2L 0x000000FF // Oscillator Switchover mode enabled #define _FCMEN_OFF_2L 0x000000BF // Fail-Safe Clock Monitor disabled #define _FCMEN_ON_2L 0x000000FF // Fail-Safe Clock Monitor enabled #define _FOSC2_INT_2L 0x000000FB // Default osc on POR is INTRC #define _FOSC2_FOSC_2L 0x000000FF // Default osc on POR is INTRC #define _OSC_HS_2L 0x000000FC // HS oscillator #define _OSC_HSPLL_2L 0x000000FD // HS oscillator, PLL enabled (Clock Frequency = 4 x FOSC1) #define _OSC_EC_2L 0x000000FE // EC oscillator, CLKO function on RA6 #define _OSC_ECPLL_2L 0x000000FF // EC oscillator, CLKO function on RA6 It's Microchip's fault, not Sourceboost. This cost me some time. I hope this saves you the trouble. Steve
  13. I've run into a huge problem when using BoostC under MPLAB IDE and ICD2. The code runs fine if I use the simulator. When I run the same code on the ICD2 "ptr1" gets trashed with a random value. I've tried working around this by passing an argument directly to the dummy routine instead of a pointer. No luck, the argument gets trashed. I wrote this sample code as a simplified version of my project. BTW, I'm monitoring x and ptr1 in an MPLAB watch window. I'm in a bind here, I've got a big project and no way to run it under ICD2! Am I doing something wrong? #include <system.h> //The target micro is an 18F2450 #include <icd2.h> //Configuration Fuses #pragma DATA _CONFIG1L,_PLLDIV_2_1L&_CPUDIV_OSC1_PLL2_1L //Config1L options #pragma DATA _CONFIG1H,_FOSC_HS_1H&_FCMEM_OFF_1H&_IESO_OFF_1H //Config1H options #pragma DATA _CONFIG2L,_PWRT_ON_2L&_BOR_OFF_2L&_BORV_21_2L //Config2L options #pragma DATA _CONFIG2H,_WDT_OFF_2H&_WDTPS_1_2H //Config2H options #pragma DATA _CONFIG3H,_MCLRE_ON_3H&_LPT1OSC_OFF_3H&_PBADEN_OFF_3H //Config3H options #pragma DATA _CONFIG4L,_STVREN_OFF_4L&_LVP_OFF_4L&_BBSIZ_BB1K_4L&_ICPRT_OFF_4L&_XINST_OFF_4L&_DEBUG_ON_4L #pragma DATA _CONFIG5L,_CP0_OFF_5L&_CP1_OFF_5L //Config5L options #pragma DATA _CONFIG5H,_CPB_OFF_5H //Config5H options #pragma DATA _CONFIG6L,_WRT0_OFF_6L&_WRT1_OFF_6L //Config6L options #pragma DATA _CONFIG6H,_WRTB_OFF_6H&_WRTC_OFF_6H //Config6H options #pragma DATA _CONFIG7L,_EBTR0_OFF_7L&_EBTR1_OFF_7L //Config7L options #pragma DATA _CONFIG7H,_EBTRB_OFF_7H //Config7H options #pragma DATA 0xF00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF #pragma DATA 0xF08, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF #pragma DATA 0xFF0, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF #pragma DATA 0xFF8, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF void dummy(char *ptr1); //function prototype for dummy routine char x; //demo variable char *ptr1; //General purpose pointer //Begin executable code void main(void) { x=2; ptr1=&x; x=x+1; while (1) { dummy(ptr1); } } void dummy(char *ptr1) //when execution jumps here ptr1 gets trashed { *ptr1=*ptr1+1; //change x by indirect reference }
  14. The following code has an error: switch(variable) { case (CONSTANT1): temp = quick; break; case (CONSTANT1): temp = brown; break; case (CONSTANT3): temp = fox; break; default: break; } When BoostC (under MPLAB) compiles the error is correctly reported as a duplicate case condition. When this error occurs BoostC halts, the compile session does not finish (with either a success or failure). If I then exit out of MPLAB I can fix the problem and compile again but the compile proceeds VERY slowly. The only way to stop this slow compile behavior is to reboot windows! Has anyone else run into this? On my system I can duplicate this 100% of the time. Steve
  15. Not currently, but is could be added. Regards Dave <{POST_SNAPBACK}> Dave, This might be better posted in a different section, but please do consider this. Implementing a CRC in a PIC16 often invloves a large table lookup and the table handler is much easier to work with if it can be placed in a specific location. Please let me know if you would like asm code samples. Sincerely, Steve
  16. Does anyone know if there's an equivalent of an ORG statement in BoostC or a workaround to get there? I use large, fast lookup tables quite often and putting a routine at a specific address is handy to avoid dealing with rollover of a page when jumping into the table. Is there a way to direct a the linker to compile to a specific physical address? Sincerely, Steve
  17. I'm collecting notes on unexpected behavior of BoostC to use as a reference. I'll post it in a public place as others contribute. For example, here's a snippet of BoostC code: void interrupt(void) { nop ;any user code goes here } I would have expected the above snippet to compile to something like this: ; ; nop ;user code here retfie ;all done, return ; ; Here's what actually happens: movwf 0x7F ;store the contents of W in RAM address 7F swapf status,w ;save the status reg, movf not used so Z bit is not changed bcf status,rp0 ;the status byte to save is in W make sure we're on page0 bcf status,rp1 ; movwf 0x20 ;save status reg in RAM swapf pclath,w ;get PCL hi byte, use swapf used to avoid stepping on value movwf 0x21 ;save PCLATH in RAM swapf fsr,w ;save FSR movwf 0x22 ;save FSR in RAM bcf pclath,3 ;make sure that GOTO and CALLs jump to first 2048 words bcf pclath,4 goto anyaddr ;now jump to user code ; ;the user code executes at <anyaddr> nop ;here's the user code ; bcf status,rp0 ;the page bits are cleared again, not sure why?? bcf status,rp1 ; swapf 0x22,w ;restore FSR movwf FSR swapf 0x21,w ;restore PCLATH movwf PCLATH swapf 0x20,w ;restore status movwf status swapf 0x7F,f ;restore w by swapping it first, it was swapped earlier swapf 0x7F,w ;w is now restored retfie ;all done The code above is a fairly standard system save on interrupt. What if you don't want to save the system state? I often have projects that are very I/O intensive and every Tcyc is counted. Is there a way to suppress this feature? Steve
  18. I'm collecting notes on the behavior of BoostC. When I collect a few I'll post it in a public place so everyone can contribute and benefit from a reference. For example, here's a snippet of code: void interrupt(void) { nop ;any user code goes here } I would expect something like the following ASM equivalent: isr nop
  19. I found the problem. It's pilot error. I did not load the system.h file onto the "headers" folder under the project definition of MPLAB. The include directive alone is sufficient for SourceBoost, but not MPLAB. BTW, does anyone know where to find a BoostC refence manual? The help file is a bit thin. Sincerely, Steve
  20. I'm having trouble using Boostc as the language tool under MPLAB IDE. The project I'm working on requires the MPLAB IDE, not the Sourceboost IDE. I just renamed the sample file "interrupt.c" to "test_01.c", selected the BoostC C Compiler as the MPLAB language suite, selected a PIC16F648A as the target micro, then complied it. MPLAB generated the following error: Clean: Deleting intermediary and output files. Clean: Deleted file "C:\Aegis Production\Zounds\Test Code\test_01.HEX". Clean: Deleted file "C:\Aegis Production\Zounds\Test Code\test_01.mcs". Clean: Done. Executing: "C:\Program Files\SourceBoost\boostlink.pic.exe" -O1 -p "test_01" -t 18F2450 BoostLink Optimizing Linker Version 6.40 http://www.sourceboost.com Copyright© 2004-2006 Pavel Baranov Copyright© 2004-2006 David Hobday Optimisation level:1 Couldn't find function/label by name:main Failure BUILD SUCCEEDED: Thu Aug 24 10:55:45 2006 Mplab Window "Failed to Load C:\<path>\test_01.COF The file test_01.cof is was created just fine and it's in the working directory with the other test_01 files. This sample C file has a main() function. Do I need a command line switch to disable case sensitivity? This is very frustrating. Please let me know if you have any insights. Sincerely, Steve
  • Create New...