Jump to content

don_erickson

EstablishedMember
  • Content Count

    19
  • Joined

  • Last visited

Community Reputation

0 Neutral

About don_erickson

  • Rank
    Newbrie
  1. After doing some more reading, I learned that I must also configure the oscillator control register as described on page 40 of the data sheet. After I put 0x7c into osccon, to configure it to run at 8 mHz, it worked like I wanted.
  2. Trying to use the internal oscillator on a 16F87, to free up RA6 & RA7. In the include file PIC16F87 I found a INTRC_IO which seems to correspond to the INTRC listed in the data sheet for the 16f87. This compiles and builds, but runs very slow. So it appears that my clock is now 31.25 kHz. What I want is what the data sheet calls INTOSC, which would make it run at 8 mHz, but I don't find that in the PIC16F87 file. Is it missing, or is it called something else?
  3. Using a 16f87, IDE 5.9, BoostC 2.0. #pragma DATA 0x2007, _CP_OFF & _CCP1_RB3 & _DEBUG_OFF & _WRT_ENABLE_OFF & _CPD_OFF & _LVP_OFF & _BODEN_OFF & _MCLR_OFF & _PWRTE_OFF & _WDT_OFF & _HS_OSC causes the compiler to say: timer34.c(31): error: failure but if I leave out the _WRT_ENABLE_OFF part, #pragma DATA 0x2007, _CP_OFF & _CCP1_RB3 & _DEBUG_OFF & _CPD_OFF & _LVP_OFF & _BODEN_OFF & _MCLR_OFF & _PWRTE_OFF & _WDT_OFF & _HS_OSC the compiler has no objection. _WRT_ENABLE_OFF is defined in p16f87.h, just like the others. Is this a bug? Don Erickson, don@erickson.net
  4. Using a 16f87, IDE 5.9, and c2c 2.0 Beta. clear_bit ( intcon, T0IF ); gives error: timer34.c(145:25): error: unknown identifier 'T0IF' timer34.c(145:25): error: invalid operand 'T0IF' but clear_bit ( intcon, TMR0IF ); compiles. Both are clearly defined in p16f87.h, so either one should work. This looks like an annoyance rather than a problem. Don Erickson, don@erickson.net
  5. Oh -- OK, I see now. We can trick the debugger into seeing reality. I just tried it for the few locations I was concerned with, and it takes care of my problem. Thanks. don
  6. My problem is that the debugger says that these unprogrammed locations consist of "00", when in fact they consist of "FF". I can read the contents of the EEPROM with my programmer, and can confirm that they are "FF". But when the debugger says they are "00", I can't tell what is changing one particular location to "00". don
  7. IDE 5.7, using the debugger, shows "00" for all unprogrammed eeprom locations. It should be "FF". Something in my program is over-writing one location with a "00", and I can't use the debugger to find out what is doing that, since I won't be able to to see the change. Thanks don
  8. Using IDE 5.7 and Boostc 1.6. I have a function which used to work, and now it does not. No changes have been made to it. It is a function to read a string of characters from EEPROM data and send them to the LCD. I call it like this: read_eeprom_string( 0x80, 11); 0x80 is the location in EEPROM data where the string starts, and it is 11 characters long. The function (and another one that it calls) is as follows: //************************************ // Read one character from EEPROM data memory char read_eeprom( char addr ) { eeadrh = 0; eeadr = addr; clear_bit(eecon1, EEPGD); set_bit(eecon1, RD); return eedata; } //************************************** // Read a string from EEPROM data, send to LCD void read_eeprom_string( char addr, char num) { char count; char res; count = 0; while (count < num ) { res = read_eeprom(addr + count); LCD_char(res ); count++; } } This routine used to work, and now it only writes the first character of the string, and then returns. I have not changed this function. I ran it on the debugger, and confirmed this. count = 0, and num = 11. The debugger shows the first character being read and written to the LCD, and when it executes the count++ instruction, counts stays = 0. Then it compares count and num, and returns even though count = 0 and num = 11. The generated code: ORG 0x000000D7 read_eeprom_string ; { read_eeprom_string ; function begin CLRF read_eeprom_string_2_count label268436129 MOVF read_eeprom_string_arg_num, W SUBWF read_eeprom_string_2_count, W BTFSC STATUS,C GOTO label268436130 MOVF read_eeprom_string_2_count, W BCF STATUS, RP0 ADDWF read_eeprom_string_arg_addr, W BSF STATUS, RP0 MOVWF read_eeprom_arg_addr CALL read_eeprom MOVF CompTempVarRet0, W MOVWF read_eeprom_string_2_res MOVF read_eeprom_string_2_res, W MOVWF LCD_char_arg_data CALL LCD_char INCF read_eeprom_string_2_count, F GOTO label268436129 label268436130 RETURN ; } read_eeprom_string function end This problem must have something to do with other parts of this (my first C program for the PIC) program that do not work correctly yet, after quite a few weeks of effort. The program compiles and links without errors. Maybe I should go back to Assembly language. Thanks Don Erickson
  9. Using Sourceboost 5.6.1, BoostC 1.5, on a 16F87. I am a beginner, and I have been struggling to learn how to handle bits on portb. I have posted other inquiries. I am using bits 0 and 1 as outputs; bit 0 for a Sonalert, and bit 1 for a relay. So, I have: #define Relay 0 // Port B bit 0 relay #define Sonalert 1 // Port B bit 1 sonalert and I can use set_bit(portb, Relay); // turn on relay which generates 03D4 0614 BSF gbl_portb,0 and this works fine. Sonalert on bit 1 also works fine. I also use bits 2 and 3 of the same port as inputs; two switches. (trisb = 0x0C). So, it would seem reasonable to have: #define CHG 2 // Port B bit 2 input - Change #define S_R 3 // Port B bit 3 input - Set/Reset since if the outputs work defined as the bit number, the inputs should also work defined as the bit number. So when I do this, for the S_R switch on bit 3 for example, I have if ((portb & S_R) == 0) { // reset which generates 0112 0330 MOVLW 0x03 0113 0313 BCF STATUS, RP1 0114 0605 ANDWF gbl_portb, W 0115 031D BTFSS STATUS,Z But note that this is looking bits 0 and 1 -- I wanted it to look at bit 3. I have to define S_R as the VALUE of bit 3 and not the bit number. Thus: #define CHG 4 // Port B bit 2 input - Change #define S_R 8 // Port B bit 3 input - Set/Reset button Now, the same if ((portb & S_R) == 0) { // reset generates 0110 8619 BTFSC gbl_portb,3 which is not only simpler, but it also looks at bit 3 like I wanted. It took me a couple of days to learn that if I am treating bits on a port as outputs, I define them with the bit number, but if I am using them as inputs, I must define them with the value of the bit, not the bit number. Is this a lack of consistency, or am I making things difficult for myself? Thanks Don Erickson
  10. When I was using C2C-plus compiler, I could read the value of an input on port b in an if statement such as if (input_pin_port_b(CHG) == 0){ etc but Boostc won't accept this. I had been trying if (portb, CHG == 0) { etc but Pavel has pointed out that this doesn't do anything, even though the Boostc compiler doesn't object. There must be a way to read the value of a pin of an input port? The examples that I have found use the version that the C2C-plus compiler uses. Thanks Don Erickson
  11. Using Sourceboost 5.6.1 " boostc 1.5 Windows Me I have a program which compiles successfully with Boostc 1.5. When I have it Build, the linker comes into play, and reports that it has omitted four of my functions. When I look at the code window, I see that either the compiler left out about 30 - 35 lines of my source code, or the linker saw fit to ignore it. As a result, four of my functions are never called. These 30 to 35 lines are not commented out -- just ignored by either the compiler or the linker. How can I tell which, and better yet, how do I tell what is going on? I had this program running partially with C2C-plus, but it won't even initialize the LCD when I use Boostc. Thanks Don Erickson
  12. I will be interested in BoostC errors as well. We prepare a new BoostC release and I'd like to fix as many defects as possible. Regards, Pavel <{POST_SNAPBACK}> OK, I got it figured out. I changed my program so it would run with Boostc (changing my statements like "output_low_port_b(Relay);" to "clear_bit(portb, Relay);, etc. Once I had that done, the Boostc compiler still reported an error, but it pointed to exactly where I had my error; I had a one-bit variable called Match, and I had been trying to Match = 1 and Match = 0. Once I changed that to set_bit(flags, Match) etc the compiler was happy. It really helps when the compiler points out the error. I will stay with Boostc from now on. Thanks Don Erickson
  13. Using Boostc 1.5, under Windows Me. Trying to enter the configuration bits for a 16F87. What I wanted to do is: #pragma DATA 0x2007, _CP_OFF & _CCP1_RB3 & _DEBUG_OFF & _WRT_PROTECT_OFF & _CPD_OFF & _LVP_OFF & _BODEN_OFF & _MCLR_OFF & _PWRTE_OFF & _WDT_OFF & _HS_OSC #pragma DATA 0x2008, _IESO_OFF & _FCMEN_OFF But the compiler reports an error (failure) on the first one. too long? After removing all the bits that would be correct by default, I tried #pragma DATA 0x2007, _CCP1_RB3 & _BODEN_OFF & _WDT_OFF & _HS_OSC #pragma DATA 0x2008, _IESO_OFF & _FCMEN_OFF And this compiles OK. Also -- that BODEN_OFF -- according to the data sheet for the 16F87, shouldn't that be BOREN_OFF? Thanks Don Erickson
  14. That was using the C2C_ compiler, not Boostc. When I try BoostC, I get many more errors. I will try to put together a simplified version of the program and get back to you. Thanks Don Erickson
×
×
  • Create New...