Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by davidb

  1. Declare fixed address variables at the locations you want to protect. BoostLink will work around any fixed address variables. Something like this would fit the bill: char reserved_0x070 @ 0x070; char reserved_0x0F0 @ 0x0F0; char reserved_0x165[ 11 ] @ 0x0165; char reserved_0x1F0 @ 0x1F0; Regards Dave Thanks Dave. I thought that there must be a simple solution but clean forgot about declaring fixed address variables to reserve locations! Davidb
  2. Hi all, I have been using Boost C with MPLAB IDE for the last few of my PIC projects (having previously used asm). For the bulk of the development I have used ICE2000 with a prototype board using DIL parts. I have been impressed with BoostC and its integration with MPLAB. Production PCBs use SM parts so I have been using the Microchip PICKit 2 programmer together with Debug Express for final development programming & debugging via an ICSP connector. PICKit 2 is a cheap and competent programmer/debugger (all though very limited compared to ICE2000) that also programs so much fas
  3. Hi, Ignore my previous ramblings, I have found the problem! During initialisation I was calling a function to block clear the ram. I have always used this when writing in assembler since I found it made debugging easier. With SourceBoost C it has had the opposite effect. When the rom data type is used, SourceBoost C appears to create rom table numbers in ram which my routine then carefully cleared. This may also explain other problems as well. Removing the function cured the problem. What fooled me was that three out of the four tables appeared to work correctly. Not a
  4. Hi, BUG DESCRIPTION: There is either a problem with the rom data type or in my understanding of its limitations. I have a program with 4 arrays: 20 bytes, 162 bytes, 162 bytes & 142 bytes. I have been using #pragma DATA TABLE_START, 0x0782, followed by the number of required bytes in a header file to place the data in fixed locations at the top of memory (the longer ones were started at 256 byte boundaries). The data is accessed using short asm code. This works without any problems except there are obvious unused gaps in memory between the data and I am not sure if the compiler ca
  5. Orin, I didn't bother spending time delving into the macro itself but I understand what you are saying and guessed thats what was causing the problem. I really posted it to make other people aware that a problem exists if you try to take short cuts in writing the code. In this case the code fails to compile so at least it is highlighted, although the error messages are somewhat obscure. (if one thing really needs improving in the compiler it is the error reporting!) In the case of the bit manipulation macro problems I posted previously, the code compiles but does not work and that
  6. Hi, BUG DESCRIPTION: There appears to be a minor problem with the MAKESHORT macro when used within parenthesis such as when used with 'if' or 'if-else'. This was discovered when tidying code. The following simple example shows various ways of using the macro, all of which I believe should be valid C. Some compile OK and some fail. The only common factor appears to be that if, for any reason, MAKESHORT is used within parenthesis then at least the right hand one must be on a new line. REPRODUCIBLE: 100% IDE: V6.84 COMPILER: BoostC (Using aggressive optimisation) TARGET: 16F88
  7. Hi, Bug Description: The clear_bit(var,num) and test_bit(var,num) macros fail if the var is larger than 8 bits and num is a variable. The set_bit and toggle_bit macros appear to work as expected. The macros were expanded into standard code to prove the point as shown in the following snippet. If an intermediate variable is used then the code for testing a bit and clearing a bit will compile and work as expected as shown in the last two examples. I haven't fully checked but I believe the all macros are OK if num is a constant (also optimises code as well). Expected Behaviour
  8. davidb


    Dave, I agree it works as shown when x is unitialised but in a working program x would have value. If you assign a value to x before or strangely, after the expression you get a different result. It doesn't seem to matter if x is local or global. If you do this with tris, intcon or probably any of the other PIC registers it works as expected. e.g. void main( void ) { unsigned char x; x = ~x; 0003 1283 BCF STATUS, RP0 0004 1303 BCF STATUS, RP1 0005 0920 COMF main_1_x, W 0006 00A0 MOVWF main_1_x x = 0; 0007 01A0 CLRF main_1_x t
  9. davidb


    Hi, I am new to SourceBoost C (V6.70) and have been testing it with some simply code. If x is data type char why does x = ~x compile to COMF x,W MOVWF x instead of the more efficient COMF x,F ? short and long types seem to be OK. I looked through the archives and found a reference to this with trisc = ~trisc This now appears to work as expected but not with other variables. Am I missing something? davidb
  • Create New...