Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About mp035

  • Rank
  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
  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?
  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_
  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 eve
  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 numbe
  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 _prod
  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
  • Create New...