Jump to content

Aegis-tec

EstablishedMember
  • Content Count

    20
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Aegis-tec

  • Rank
    Regular
  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
×
×
  • Create New...