Jump to content

mp035

EstablishedMember
  • Content Count

    19
  • Joined

  • Last visited

Community Reputation

0 Neutral

About mp035

  • Rank
    Newbrie
  1. Thanks Reynard, I wonder why I am not getting the warning? --- WAIT..... Bl**dy H**l !!!!!!!!!! Because it was not in blue or red on MPLABX I did not see it, I should have been looking harder! Thanks for posting this, it is a good point. -- EDIT: I used your method instead of disabling the interrupts, as well as solving the issue, it will be faster. Thanks. Good note. Boost C uses 2's complement for signed integers, so the bit representation of the output will be correct whether or not the values are passed as signed.
  2. Hi Reynard, Thanks for trying it out, do you have interrupt and main in different files?
  3. Thanks for the reply Reynard. Yes I turned all warnings on, still no mention of the issue. I understand your concern regarding long calculations in the interrupt routine, this program is for real-time true RMS calculations of a waveform. Squaring in the ISR is the best option. I have been using this method for about 8 years on various compilers, but have just started coding with boostc again because of the shortcomings of the XC8 compiler. Boost V6 (and V5, I think) used to throw an error if a builtin function was called in both threads, but it looks like V7 does not.
  4. Hi, I am having some issues with incorrect results from a signed 32bit multiply, which I am unable to reproduce with a concise project under mplab sim. Looking at the dissasembly, it seems as if the main and interrupt routines are calling the same function, causing corruption of the registers used. interrupt disassembly ! accumulator -= (temp * temp); 0x471: MOVF sendval, W 0x472: MOVWF a 0x473: MOVF 0x68, W 0x474: MOVWF 0x72 0x475: MOVF 0x69, W 0x476: MOVWF 0x73 0x477: MOVF 0x6A, W 0x478: MOVWF 0x74 0x479: MOVF sendval, W 0x47A: MOVWF b 0x47B: MOVF 0x68, W 0x47C: MOVWF 0x76 0x47D: MOVF 0x69, W 0x47E: MOVWF 0x77 0x47F: MOVF 0x6A, W 0x480: MOVWF 0x78 0x481: CALL 0x7 !********************** I beleive this is the mul32 function. 0x482: MOVF $ret, W 0x483: MOVWF 0x6D 0x484: MOVF 0x7A, W 0x485: MOVWF 0x6E 0x486: MOVF 0x7B, W 0x487: MOVWF 0x6F 0x488: MOVF 0x7C, W 0x489: MOVWF 0x70 0x48A: MOVF 0x6D, W 0x48B: SUBWF accumulator, F 0x48C: MOVF 0x6E, W 0x48D: BTFSS STATUS, 0x0 0x48E: INCFSZ 0x6E, W 0x48F: SUBWF 0x29, F 0x490: MOVF 0x6F, W 0x491: BTFSS STATUS, 0x0 0x492: INCFSZ 0x6F, W 0x493: SUBWF 0x2A, F 0x494: MOVF 0x70, W 0x495: BTFSS STATUS, 0x0 0x496: INCFSZ 0x70, W 0x497: SUBWF 0x2B, F and in main: ! accumulated_value *= -1L; 0x365: MOVF accumulated_value, W 0x366: MOVWF a 0x367: MOVF 0x21, W 0x368: MOVWF 0x72 0x369: MOVF 0x22, W 0x36A: MOVWF 0x73 0x36B: MOVF 0x23, W 0x36C: MOVWF 0x74 0x36D: MOVLW 0xFF 0x36E: MOVWF b 0x36F: CLRF 0x76 0x370: DECF 0x76, F 0x371: CLRF 0x77 0x372: DECF 0x77, F 0x373: CLRF 0x78 0x374: DECF 0x78, F 0x375: CALL 0x7 !**************************** same function call. 0x376: MOVF $ret, W 0x377: MOVWF accumulated_value 0x378: MOVF 0x7A, W 0x379: MOVWF 0x21 0x37A: MOVF 0x7B, W 0x37B: MOVWF 0x22 0x37C: MOVF 0x7C, W 0x37D: MOVWF 0x23 Can anyone weigh in on whether this is a bug, or whether I should keep looking? Thanks. EDIT: putting intcon.GIE = 0, intcon.GIE=1 instructions around the main.c multiply solves the issue, so I'm almost certain this is a bug. Older versions of boostc used to flag this situation during compilation. I am using PIC16F1823, my main and interrupt functions are in different files (main.c and interrupt.c respectively.)
  5. Hi All, This behaviour used to bug me in MPLAB 8, but i understand that there was no make facility for mplab 8. I have just started using boostc under MPLAB X and it still has the same behaviour. Why does Boost c have to do a complete rebuild every time, even when no source code has changed. This is problem is exacerbated by the fact that I am forced to run Boost C under virtualbox (currently the only application that I still need windows for) and building a simple project takes more than 2 minutes. Does anyone know if there is an option to use "make" with BoostC under Mplab X? thanks.
  6. Hi Pavel, Could I also please have a copy of the plugin? Will you be supporting Linux or Mac OSX also? (It would give me a really strong reason to update my 6.X boost c pro license which by the way has been well worth the money.)
  7. Hi all, I have found a bug in boost c to beware of, if you use the instruction subwfb inside an _asm{} on pic18 boostc, version 6.84, the command will appear as subfwb in the compiled file. To replicate, compile this file: void main() { unsigned char foo = 4; unsigned char bar = 8; _asm { movf _foo, W subwfb _bar, W } } notice that the instruction is incorrectly converted in the output (.asm): main_1_foo EQU 0x00000001; bytes:1 main_1_bar EQU 0x00000002; bytes:1 ORG 0x00000000 GOTO _startup ORG 0x00000004 main ; { main; function begin MOVLW 0x04 MOVWF main_1_foo MOVLW 0x08 MOVWF main_1_bar MOVF main_1_foo, W SUBFWB main_1_bar, W RETURN ; } main function end ORG 0x00000012 _startup GOTO main END I hope this helps someone. Mark.
  8. Hi Chris, Sorry for the way way way too late reply, I put this project in the background for a while as I had some more pressing jobs. LOL You could buy a lifetime supply of asprin with the money you save from using BoostC! (esp. vs. HI TECH C). I didn't mean to imply that Boost C was a bad compiler. I bought a licence a couple of years ago, before it could handle 32 bit math, and array handling was sketchy at best. Even then it was good value for money. Now it's exceptional. Just thought that others may benefit from this little solution, and was wondering if it would even work. Anyways Dave cleared that up nicely. Thanks for your input guys. Happy BOOSTing! Mark.
  9. What chip are you using? The first thing I would check is the status of the cmcon and adcon0, and/or adcon1 registers, certain flavours of pic boot up with some of the pins dedicated to the comparator (like the pic 16f628a) and others boot up with them dedicated to the ADC.
  10. Hi David, I would suggest using a device that has a timer1 oscillator(16f628A for a small app, or a 16f877A, or if you've got a lot of work an 18f4520 or similar), and then use a 32.768khz watch crystal, just connect the crystal across the timer1 oscillator pins, and bypass each of the 2 pins to ground with a 33pf ceramic cap. It its best to dedicate the timer1 to your time stamping & rtc code, you can then update some day:hr:min:sec registers in the interrupt routine. The other delay routines ie delay_us(int) etc do not use the timers, they are made up of the appropriate number of NOP's, calcualated at compile time from the CLOCK_FREQ pragma.
  11. Hi all, I am writing an application on a PIC 18f4520 that needs to multiply long integers in the main as well as the interrupt thread. I have gotten around the "Serious Warning" in BoostC 6.70 by writing my own mul32 routine (I actually stole it from a section of code generated by boostc): unsigned long mul32(unsigned long left, unsigned long right) { unsigned long result; _asm { CLRF _result CLRF _result+1 CLRF _result+2 CLRF _result+3 MOVF _left, W MULWF _right MOVF _prodl, W MOVWF _result MOVF _prodh, W MOVWF _result+1 MOVF _left+1, W MULWF _right MOVF _prodl, W ADDWF _result+1, F MOVF _prodh, W ADDWFC _result+2, F BTFSC _status, 0 INCF _result+3, F MOVF _left+2, W MULWF _right MOVF _prodl, W ADDWF _result+2, F MOVF _prodh, W ADDWFC _result+3, F MOVF _left+3, W MULWF _right MOVF _prodl, W ADDWF _result+3, F MOVF _left, W MULWF _right+1 MOVF _prodl, W ADDWF _result+1, F MOVF _prodh, W ADDWFC _result+2, F BTFSC _status, 0 INCF _result+3, F MOVF _left+1, W MULWF _right+1 MOVF _prodl, W ADDWF _result+2, F MOVF _prodh, W ADDWFC _result+3, F MOVF _left+2, W MULWF _right+1 MOVF _prodl, W ADDWF _result+3, F MOVF _left, W MULWF _right+2 MOVF _prodl, W ADDWF _result+2, F MOVF _prodh, W ADDWFC _result+3, F MOVF _left+1, W MULWF _right+2 MOVF _prodl, W ADDWF _result+3, F MOVF _left, W MULWF _right+3 MOVF _prodl, W ADDWF _result+3, F } return result; } So I now call c = mul32( a,b ) instead of c = a*b. My question is this: Does boost save the prodh and prodl registers in the context save for an interrupt? And if it does, why have Pavel and Dave not already made the boostc compiler to simply generate 2 or 3 of the 32bit math routines, one for each of the threads ie __mul_23_32 , ___int_mul_32_32, and __intlow_mul_32_32 ?? It seems like a simple fix to a problem that causes many headaches, so I'm sure I'm missing something. Any opinions would be appreciated. Many thanks.
  12. Thanks heaps Dave , perhaps this message should be pinned. There are a lot of configuration options on the PIC 18 and this post saved me hours of tearing my hair out.
  13. This bug is fixed in release 6.50, lucky, I'd seen no reply on it and have ported 32k of code to the far inferior microchip c18 compiler to try and keep my project moving. Happy to be able to switch back to BoostC. I'm taking the bug project off my website.
  14. Operating system : Windows XP Compiler: Boost C for pic18 v6.30 IDE: Microchip MPLAB 7.41 PIC CPU: 18f452 Full Project files can be downloaded from: http://members.optusnet.com.au/~theelectro...o/boostcbug.zip Bug description: The value being passed to the value pointed at by *cf_buffer() is incorrect. Its complex, see the comments in the project, or the copy of the code below, I've cut everything that is non-essential from the code, I hope It makes it easier to read. #include <system.h> unsigned char byte0(unsigned long data){ unsigned char temp; temp = data; return temp; } unsigned char byte1(unsigned long data){ unsigned char temp; data = data >> 8; temp = data; return temp; } unsigned char byte2(unsigned long data){ unsigned char temp; data = data >> 16; temp = data; return temp; } unsigned char byte3(unsigned long data){ unsigned char temp; data = data >> 24; temp = data; return temp; } unsigned char cf_buffer0[256]; unsigned char cf_buffer1[256]; unsigned char *cf_buffer(unsigned short address){ // this function is used to decode full buffer addresses unsigned char temp = 0; LOBYTE(temp, address); if (address.8){ return &cf_buffer1[temp]; } else{ return &cf_buffer0[temp]; } } void main(){ unsigned long value1; unsigned long value2; value1 = 0x0D0C0B0A; value2 = 0x01020304; *cf_buffer(0) = byte0(value1); // should be 0x0A, but ends up being 0x00 *cf_buffer(1) = byte1(value1); // should be 0x0B, but ends up being 0x01 *cf_buffer(2) = byte2(value1); // should be 0x0C, but ends up being 0x02 *cf_buffer(3) = byte3(value1); // should be 0x0D, but ends up being 0x03 *cf_buffer(100) = byte0(value2); // should be 0x04, but ends up being decimal 100 *cf_buffer(101) = byte1(value2); // should be 0x03, but ends up being decimal 101 *cf_buffer(102) = byte2(value2); // should be 0x02, but ends up being decimal 102 *cf_buffer(103) = byte3(value2); // should be 0x01, but ends up being decimal 103 // whereas this works fine *cf_buffer(108) = 4; // should be 0x04, ....OK *cf_buffer(109) = 3; // should be 0x03, ....OK *cf_buffer(110) = 2; // should be 0x02, ....OK *cf_buffer(111) = 1; // should be 0x01, ....OK // and so does this cf_buffer0[104] = byte0(value2); // should be 0x04, ....OK. cf_buffer0[105] = byte1(value2); // should be 0x03, ....OK cf_buffer0[106] = byte2(value2); // should be 0x02, ....OK cf_buffer0[107] = byte3(value2); // should be 0x01, ....OK while(1) {} // it seams that the value of the address passed to the *cf_buffer function is being stored, rather than the // value returned by the bytex() functions }
×
×
  • Create New...