Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Reynard

  1. In this case should'nt it be x=45? OOps, I see youir point - my mistake I think 0x00 is a perfectly good result. You are shifting in a '0' from the left 8 times not rotating a char 8 times. Cheers Reynard
  2. A tick appears to be an oscillator cycle. If you step through a 1 cycle instruction it will increment the tick count by 4. A 4MHz xtal will give 1us instruction cycle time. The tick count will change to values in 'kilo' after a while i.e. 10k etc. which cannot be reset to zero. If you install BoostC within MPLab (Microchip IDE) you can use its watchdog feature measure in real time. Cheers Reynard Doh! Did I say watchdog feature ? read that as "Stopwatch feature to measure in real time." Reynard
  3. A tick appears to be an oscillator cycle. If you step through a 1 cycle instruction it will increment the tick count by 4. A 4MHz xtal will give 1us instruction cycle time. The tick count will change to values in 'kilo' after a while i.e. 10k etc. which cannot be reset to zero. If you install BoostC within MPLab (Microchip IDE) you can use its watchdog feature measure in real time. Cheers Reynard
  4. You don't say what PIC type you are using. Is the input C12IN0- (C1CH bits = 00) on pin RA1 and not RA0 ? Cheers Reynard
  5. As you said it appears that BoostC does not like initialising structures like other compilers. You will have to fill your structure the hard way. BoostC is still value for money and is still growing. Cheers Reynard ps. MikroC works but you have to pay more.
  6. The answer to that is yes, looks like the IDE version number didn't get updated Regards Dave Can't win them all. It is after all only a Release Cantidate and may be changed. Cheers Reynard
  7. It would be a nice feature to have an option or pragma to force the use of 8 bit pointers. Most of the smaller PIC's only have 256 or less RAM bytes so using 16 bit pointers and switching of IRP bit just adds alot of surplus code. I will refrain form saying that the CCS compiler does it. Doh! just said it. Cheers Reynard
  8. The code below gives errors: CaseTest.c(13): error: missing right brace CaseTest.c(10): error: missing semicolon CaseTest.c(10): error: failure It appears that the case statement constant does not like having the left shift operator in it. (It may not like the right shift operator either but have not tried it.) Replacing the I2C_STATE_1 definition with (0x09) works OK. #include <system.h> #define SSPSTAT_MASK (1 << D_A | 1 << S | 1 << R_W | 1 << BF) #define I2C_STATE_1 (1 << S | 1 << BF) // I2C write, last byte an address. void main(void) { } void I2C_SerialInterrupt(void) { pir1.SSPIF = false; // clear interrupt flag. switch (sspstat & SSPSTAT_MASK) { case (I2C_STATE_1): break; } // end switch. } void interrupt(void) { if (pir1.SSPIF) { // I2C interrupt ? I2C_SerialInterrupt(); // yes, process I2C interrupt. } } Using BoostC 6.81, PIC16F873A, WinXP Pro SP2. Cheers Reynard
  9. Rignt shifting an unsigned long right 4 or more bits, except multiples of 8 , creates 12 redundant program words to the assembler code at beginning of the statement. #include <system.h> unsigned long mylong; void main(void) { mylong = 0x12345678; 0003 3078 MOVLW 0x78 0004 1283 BCF STATUS, RP0 0005 1303 BCF STATUS, RP1 0006 00A0 MOVWF gbl_mylong 0007 3056 MOVLW 0x56 0008 00A1 MOVWF gbl_mylong+D'1' 0009 3034 MOVLW 0x34 000A 00A2 MOVWF gbl_mylong+D'2' 000B 3012 MOVLW 0x12 000C 00A3 MOVWF gbl_mylong+D'3' mylong >>= 4; 000D 3000 MOVLW 0x00 000E 3800 IORLW 0x00 000F 3800 IORLW 0x00 0010 39FF ANDLW 0xFF 0011 1903 BTFSC STATUS,Z 0012 2819 GOTO label268438905 0013 0D23 RLF gbl_mylong+D'3', W 0014 01A0 CLRF gbl_mylong 0015 01A1 CLRF gbl_mylong+D'1' 0016 01A2 CLRF gbl_mylong+D'2' 0017 01A3 CLRF gbl_mylong+D'3' 0018 281C GOTO label268438907 0019 label268438905 0019 3004 MOVLW 0x04 001A 00A4 MOVWF CompTempVar495 001B 08A4 MOVF CompTempVar495, F 001C label268438907 001C 1903 BTFSC STATUS,Z 001E 1003 BCF STATUS,C 001F 0CA3 RRF gbl_mylong+D'3', F 0020 0CA2 RRF gbl_mylong+D'2', F 0021 0CA1 RRF gbl_mylong+D'1', F 0022 0CA0 RRF gbl_mylong, F 0023 03A4 DECF CompTempVar495, F 0024 281C GOTO label268438907 } Using BoostC 6.81, WinXP Pro XP2. Cheers Reynard
  10. The compiler does not recognise that right shifting by 24 is a multiple of 8 bits. #include <system.h> unsigned long mylong; unsigned char mychars[5]; void main(void) { mylong = 0x12345678; 0003 3078 MOVLW 0x78 0004 1283 BCF STATUS, RP0 0005 1303 BCF STATUS, RP1 0006 00A5 MOVWF gbl_mylong 0007 3056 MOVLW 0x56 0008 00A6 MOVWF gbl_mylong+D'1' 0009 3034 MOVLW 0x34 000A 00A7 MOVWF gbl_mylong+D'2' 000B 3012 MOVLW 0x12 000C 00A8 MOVWF gbl_mylong+D'3' mychars[0] = (unsigned char)(mylong >> 0); 000D 0825 MOVF gbl_mylong, W 000E 00A0 MOVWF gbl_mychars mychars[1] = (unsigned char)(mylong >> 8); 000F 0826 MOVF gbl_mylong+D'1', W 0010 00A1 MOVWF gbl_mychars+D'1' mychars[2] = (unsigned char)(mylong >> 16); 0011 0827 MOVF gbl_mylong+D'2', W 0012 00A2 MOVWF gbl_mychars+D'2' mychars[2] = (unsigned char)(mylong >> 24); 0013 0825 MOVF gbl_mylong, W 0014 00A9 MOVWF CompTempVar499 0015 0826 MOVF gbl_mylong+D'1', W 0016 00AA MOVWF CompTempVar500 0017 0827 MOVF gbl_mylong+D'2', W 0018 00AB MOVWF CompTempVar501 0019 0828 MOVF gbl_mylong+D'3', W 001A 00AC MOVWF CompTempVar502 001B 1003 BCF STATUS,C 001C 0CAC RRF CompTempVar502, F 001D 0CAB RRF CompTempVar501, F 001E 0CAA RRF CompTempVar500, F 001F 0CA9 RRF CompTempVar499, F 0020 1003 BCF STATUS,C 0021 0CAC RRF CompTempVar502, F 0022 0CAB RRF CompTempVar501, F 0023 0CAA RRF CompTempVar500, F 0024 0CA9 RRF CompTempVar499, F 0025 1003 BCF STATUS,C 0026 0CAC RRF CompTempVar502, F 0027 0CAB RRF CompTempVar501, F 0028 0CAA RRF CompTempVar500, F 0029 0CA9 RRF CompTempVar499, F 002A 1003 BCF STATUS,C 002B 0CAC RRF CompTempVar502, F 002C 0CAB RRF CompTempVar501, F 002D 0CAA RRF CompTempVar500, F 002E 0CA9 RRF CompTempVar499, F 002F 1003 BCF STATUS,C 0030 0CAC RRF CompTempVar502, F 0031 0CAB RRF CompTempVar501, F 0032 0CAA RRF CompTempVar500, F 0033 0CA9 RRF CompTempVar499, F 0034 1003 BCF STATUS,C 0035 0CAC RRF CompTempVar502, F 0036 0CAB RRF CompTempVar501, F 0037 0CAA RRF CompTempVar500, F 0038 0CA9 RRF CompTempVar499, F 0039 1003 BCF STATUS,C 003A 0CAC RRF CompTempVar502, F 003B 0CAB RRF CompTempVar501, F 003C 0CAA RRF CompTempVar500, F 003D 0CA9 RRF CompTempVar499, F 003E 1003 BCF STATUS,C 003F 0CAC RRF CompTempVar502, F 0040 0CAB RRF CompTempVar501, F 0041 0CAA RRF CompTempVar500, F 0042 0CA9 RRF CompTempVar499, F 0043 1003 BCF STATUS,C 0044 0CAC RRF CompTempVar502, F 0045 0CAB RRF CompTempVar501, F 0046 0CAA RRF CompTempVar500, F 0047 0CA9 RRF CompTempVar499, F 0048 1003 BCF STATUS,C 0049 0CAC RRF CompTempVar502, F 004A 0CAB RRF CompTempVar501, F 004B 0CAA RRF CompTempVar500, F 004C 0CA9 RRF CompTempVar499, F 004D 1003 BCF STATUS,C 004E 0CAC RRF CompTempVar502, F 004F 0CAB RRF CompTempVar501, F 0050 0CAA RRF CompTempVar500, F 0051 0CA9 RRF CompTempVar499, F 0052 1003 BCF STATUS,C 0053 0CAC RRF CompTempVar502, F 0054 0CAB RRF CompTempVar501, F 0055 0CAA RRF CompTempVar500, F 0056 0CA9 RRF CompTempVar499, F 0057 1003 BCF STATUS,C 0058 0CAC RRF CompTempVar502, F 0059 0CAB RRF CompTempVar501, F 005A 0CAA RRF CompTempVar500, F 005B 0CA9 RRF CompTempVar499, F 005C 1003 BCF STATUS,C 005D 0CAC RRF CompTempVar502, F 005E 0CAB RRF CompTempVar501, F 005F 0CAA RRF CompTempVar500, F 0060 0CA9 RRF CompTempVar499, F 0061 1003 BCF STATUS,C 0062 0CAC RRF CompTempVar502, F 0063 0CAB RRF CompTempVar501, F 0064 0CAA RRF CompTempVar500, F 0065 0CA9 RRF CompTempVar499, F 0066 1003 BCF STATUS,C 0067 0CAC RRF CompTempVar502, F 0068 0CAB RRF CompTempVar501, F 0069 0CAA RRF CompTempVar500, F 006A 0CA9 RRF CompTempVar499, F 006B 1003 BCF STATUS,C 006C 0CAC RRF CompTempVar502, F 006D 0CAB RRF CompTempVar501, F 006E 0CAA RRF CompTempVar500, F 006F 0CA9 RRF CompTempVar499, F 0070 1003 BCF STATUS,C 0071 0CAC RRF CompTempVar502, F 0072 0CAB RRF CompTempVar501, F 0073 0CAA RRF CompTempVar500, F 0074 0CA9 RRF CompTempVar499, F 0075 1003 BCF STATUS,C 0076 0CAC RRF CompTempVar502, F 0077 0CAB RRF CompTempVar501, F 0078 0CAA RRF CompTempVar500, F 0079 0CA9 RRF CompTempVar499, F 007A 1003 BCF STATUS,C 007B 0CAC RRF CompTempVar502, F 007C 0CAB RRF CompTempVar501, F 007D 0CAA RRF CompTempVar500, F 007E 0CA9 RRF CompTempVar499, F 007F 1003 BCF STATUS,C 0080 0CAC RRF CompTempVar502, F 0081 0CAB RRF CompTempVar501, F 0082 0CAA RRF CompTempVar500, F 0083 0CA9 RRF CompTempVar499, F 0084 1003 BCF STATUS,C 0085 0CAC RRF CompTempVar502, F 0086 0CAB RRF CompTempVar501, F 0087 0CAA RRF CompTempVar500, F 0088 0CA9 RRF CompTempVar499, F 0089 1003 BCF STATUS,C 008A 0CAC RRF CompTempVar502, F 008B 0CAB RRF CompTempVar501, F 008C 0CAA RRF CompTempVar500, F 008D 0CA9 RRF CompTempVar499, F 008E 1003 BCF STATUS,C 008F 0CAC RRF CompTempVar502, F 0090 0CAB RRF CompTempVar501, F 0091 0CAA RRF CompTempVar500, F 0092 0C29 RRF CompTempVar499, W 0093 00A2 MOVWF gbl_mychars+D'2' mychars[5] = (unsigned char)(mylong >> 32); 0094 3000 MOVLW 0x00 0095 01A5 CLRF gbl_mychars+D'5' } 0096 0008 RETURN The above code snippet shows shifting by 8, 16 and 32 is handles OK (32 has a redundant instruction though). Perhaps a loop could be considered for shifts greater than say 8 to produce more compact code with a little loss of speed. Creating a union of a long and char[4] is a workaround to all those shifts to get access to the individual bytes of the long. Cheers Reynard
  11. A static array only initializes (zeroes) the first 2 bytes of the array. Put the array inside a structure though and all bytes are initializes. static unsigned char myArray[4]; static struct { unsigned char myArray[4]; } myStruct; produces assemly instructions: static unsigned char myArray[4]; 0004 1283 BCF STATUS, RP0 0005 1303 BCF STATUS, RP1 0006 01A0 CLRF gbl_11_myArray 0007 01A1 CLRF gbl_11_myArray+D'1' static struct { unsigned char myArray[4]; } myStruct; 0008 01A4 CLRF gbl_11_myStruct 0009 01A5 CLRF gbl_11_myStruct+D'1' 000A 01A6 CLRF gbl_11_myStruct+D'2' 000B 01A7 CLRF gbl_11_myStruct+D'3' An array of int's does the same (only 2 bytes zeroed). Using IDE & BoostC 6.81, PIC16F873A, Windows XP Pro SP2. Cheers Reynard
  12. See no problem here. The code loops around 2 assembly instructions that both belong to the same source code line so there is no opportunity for execution line to advance to any other source code line. That's why it looks like stepping takes forever. Regards, Pavel And there was me thinking it would step through the lines of source code including the for (;. Doh ! Cheers Reynard
  13. Pressing Step Into or Step over causes debugger to run forever after a couple of steps. Program should just loop in single step mode forever for each button press. #include <system.h> unsigned char ucTest; bool bTest; void main(void) { bTest = false; for (; { if (bTest) { ucTest = 1; } } } Also, pressing the reset button (after stopping run forever) does not reset the debug cursor to the first instruction. Using: BoostC & IDE 6.81 Windows XP Pro SP2 PIC16F873A Cheers Reynard
  • Create New...