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 inpu
  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 PIC18
  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 ////////////////////////////////////////////////// #
  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 <syste
  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
  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...