Jump to content

davidb

EstablishedMember
  • Content Count

    134
  • 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 faster than my old PICStart Plus. This has worked well for several projects where RAM use was fairly minimal. The problem is that Debug Express reserves RAM, as well as some program memory, for its own use. e.g. on the 16F887 it reserves 0x070, 0x0f0, 0x165 to 0x170 inclusive and 0x1f0. (These are shown as RR in the MPLAB IDE file registers window). On larger projects requiring more RAM BoostC has no knowledge of these reserved locations and simply overwrites them. Is anybody using BoostC with PICKit 2 and Debug Express? Does anyone know the best way, if there is one, of reserving these or any other locations to prevent them being used by BoostC? Perhaps I am missing something simple. It would be nice if BoostC could automatically recognise that Debug Express was in use to prevent it overwriting reserved locations. Alternatively a command line switch would be very useful. Thanks Davidb
  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 bug in the rom data type as such, but remember not to clear the ram as a block and initialise any variables as and when required. Still learning. Davidb
  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 can work around the data and utilise these gaps when and if the program size ever reaches that point. I thought I would try using the rom data type instead to see what difference there was in code size, speed etc. I simply removed the #pragma DATA HT_TABLE_START, 0x0782, etc and wrapped the required comma delimited data with: rom char *table_1 = {----REQUIRED DATA BYTES----- } rom char *table_2 = {----REQUIRED DATA BYTES----- } etc The data was accessed using the form: char data = table_1[offset]; Checking the first few elements returned seemed to work fine for tables 1, 2 & 3 but when accessing table 4 the returned data was actually that from table 1. This seems to be a classic address wrap around situation. Looking at the amount of code generated to access the data I naturally assumed that the compiler would take care of 256 byte boundaries and paging issues. It certainly doesn't force the data to start at a 256 byte boundary. The manual states that a rom pointer is limited to 8 bits or 256 elements, which is fair enough. I understood this to mean that I could have a number of rom arrays each of which could be up to 256 elements. I haven't had time to fully analyse the problem or provide cut down code as an example but from what I have seen I would guess that the limit may be 256 elements in total no matter how many arrays are defined. This may be a bit simplistic and may vary depending on where the code is placed by the compiler. Can anyone confirm if there is an overall limit on the number of rom array elements? REPRODUCIBLE: Yes but haven't had time to fully investigate IDE: V6.84 COMPILER: BoostC (Using aggressive optimisation) TARGET: 16F887 OS: XP Pro SP2 Thanks davidb
  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 can be really frustrating. Finding that some of these macros only work correctly with char types is annoying but not the end of the world. It is just that the manual didn't indicate that a problem might exist and time was wasted trying to understand why the program didn't work. I think if macros are provided then all restrictions when using them should be made clear in the manual. The current issue of the manual seems to be lagging somewhat on the compiler version. Can I suggest Dave & Pavel that you publish an addendum and update it as new problems, restrictions, fixes etc are found until such time that you can find time to update the whole manual. It would also make life easier for newbies as well if there was just one place to look rather than having to search the forum for an obscure problem. Having said all of that, I am very impressed with this value for money compiler as well as the support provided and just hope that it continues to improve. Well done! Davidb
  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: 16F887 OS: XP Pro SP2 while(1) { bit TRUE = 1; ushort x; uchar y; uchar z; if(TRUE) { MAKESHORT(x, y, z); // OK } if(TRUE) MAKESHORT(x, y, z); // OK if(TRUE) { MAKESHORT(x, y, z); // OK } else { x = 0; } if(TRUE) {MAKESHORT(x, y, z);} // Fails if(TRUE) MAKESHORT(x, y, z); // Fails else x = 0; if(TRUE) {MAKESHORT(x, y, z); // OK! } else x = 0; } This is not really a major problem but maybe an interesting one to add to the list. Thanks DavidB
  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: Not sure if this is a bug or just the way it works but I would expect to be able to use the standard bit shift method with any length of variable no matter how large the generated code. If there is a limit I would also expect a warning. while(1) // Loop forever { unsigned short test_word; // Test word unsigned short x; // Test bit result unsigned short y; // Temporary variable unsigned char bit_num; // Bit number test_word = 0; for(bit_num = 0; bit_num < 16; bit_num++) { test_word |= (1 << bit_num); // Set bit - OK } test_word = 0xffff; for(bit_num = 0; bit_num < 16; bit_num++) { test_word &= ~(1 << bit_num); // Clear bit - Only works up to 8 bits } test_word = 0xffff; for(bit_num = 0; bit_num < 16; bit_num++) { x = test_word & (1 << bit_num); // Test bit - Only works up to 8 bits } test_word = 0; for(bit_num = 0; bit_num < 16; bit_num++) { test_word ^= (1 << bit_num); // Toggle bit 0 > 1 - OK } test_word = 0xffff; for(bit_num = 0; bit_num < 16; bit_num++) { test_word ^= (1 << bit_num); // Toggle bit 1 > 0 - OK } // Workaround using intermediate variable test_word = 0xffff; for(bit_num = 0; bit_num < 16; bit_num++) { y = (1 << bit_num); test_word &= ~y; // Clear bit - Now OK } test_word = 0xffff; for(bit_num = 0; bit_num < 16; bit_num++) { y = (1 << bit_num); x = test_word & y; // Clear bit - Now OK } } Comments: Reproducible: 100% IDE: V6.81 COMPILER: BoostC (using aggressive optimisation) TARGET: 16F877 OS: XP PRO SP2 Thanks DavidB
  8. davidb

    Complement

    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 trisc = ~trisc; 0008 1683 BSF STATUS, RP0 0009 0987 COMF gbl_trisc, F intcon = ~intcon; 000A 098B COMF gbl_intcon, F while(1); 000B label268438907 000B 280B GOTO label268438907 } Take out the x =0; and it works as expected. I am new to SourceBoost C, so perhaps this is the way it is meant to work but I would like to understand why. BTW the target is the 16F874A. Thanks davidb
  9. davidb

    Complement

    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...