Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About dgille

  • Rank
  1. This is a combination of works from various authors. Please enhance and post back here for others. Best regards, D GLCD_driver.c
  2. Yes I understand that GCC uses "&&" and is non-standard. The example I included was from a supposedly "normal" C compiler. Can I get some guidance on the following: I need to redirect a program to another address after leaving an interrupt service routine. My plan is to adjust the stack pointer and write the correct address to the top of stack and then allow the return from interrupt instruction to execute. - How should write the source code so that I can take the address of a point (somewhere else in the code) to put it on the top of the stack ? Thanks, D
  3. Hello, I need to redirect a program to another address after leaving an interrupt service routine. My plan is to adjust the stack pointer and write the correct address to the top of stack and then allow the return from interrupt instruction to execute. I have not found a way to take the address of a label in BoostC. The web suggests the following ... http://stackoverflow.com/questions/1777990...ress-of-a-label int main (void) { int i=1; void* the_label_pointer; the_label: the_label_pointer = &the_label; if( i-- ) goto *the_label_pointer; return 0; } BoostC does not allow the above syntax. BoostC Optimizing C Compiler Version 6.96 (for PIC18 architecture) To make matters worse, the "Hardware Stack" dialog box does not report anything but 00's and no TOS movement. If I add the following code to my program and trace it, the watch variable values do not match the values in the "File Registers" dialog box. Are there ways to take the address of a label ? What is the best way to work with the stack ? How can I get the "Hardware Stack" dialog box working and matching the results from the "File Registers" dialog box and my own watched variables ? I'm using a PIC 18F1330 with MPLAB 8.50 and ICD 3 Thanks in advance for you kind assistance, D non_viewable_stack_and_non_matching_vars_18F1330.zip
  4. Hello all, Just installed MPLAB 8.50. Hooked up my 18F processor and did a compile. To my surprise the bit watch variables have array like expansion and I can not tell what state the bit is in. How do you determine the state of a bit variable ? Also the memory usage gauge seems to work for program memory but has a "0" status for data memory. How do you fix the interface so data size registers for Boost C compiles? Thanks,
  5. My apologies if this is a repeat ... I keep looking for BoostC to add the 18F instructions extensions. Just wondering if this is ever going to take place. My regards to the Boost Compiler Team, GREAT WORK! D
  6. I presume VAR1 .. VAR60 resolve to unsigned bytes and the 0xFF values are padding or reserved space. You have hit a compiler limit for continuation lines. EDIT: I *HAD* a proposed work around which I will leave below for the entertainment of those of you who have already got their scars from banging their head against a brick wall. It WON'T work as the compiler doesn't evaluate expressions used as the address parameter of #pragma data! From the manual: There is NOTHING magical about #pragma DATA _EEPROM and you can use multiple #pragma DATA lines to do the job. _EEPROM is just a constant for the base address of the EEPROM when its mapped into the programming address space and is defined in PxxFxxxx.h Edit: So far so good, I was just quoting from the manual and include files. but the next bit is broken. DON'T use continuation lines for this. You need to break up your EEPROM initialisation into separate lines with a sensible number of bytes on each line. I strongly recommend using 16 bytes per line, but if your variables naturally break into smaller blocks AND YOU HAVE CONSTANTS DEFINED FOR THEIR OFFSETS within the EEPROM, you could vary the line length. E.g. #pragma DATA _EEPROM+0x00, <byte1>, <byte2>, ... <byte16> #pragma DATA _EEPROM+0x10, <byte17>, <byte18>, ... <byte32> ... #pragma DATA _EEPROM+0xF0, <byte240>, <byte241>, ... <byte256> I hope that helps :-) Edit: well that was no use or help at all. I apologise profusely for posting untested code. My fault and very lazy of me as well. <eats crow> Lastly, many technically skilled people in countries where English is the national language are less likely to respond to: as the reaction is often: Thanks in advance is rarely followed by any appreciation or acknowledgement afterwards and Yes, certainly there is at least one person somewhere who knows the answer. Fortunately this forum is very friendly, but even so I would be inclined to use 'I would be grateful for any assistance.' then thank everybody afterwards. If you are visiting some of the more 'touchy' electronics groups and forums on other sites, *please* remember this ;-) Thank you very much for the reply! I've learned much and your suggestion will get me back in business. All the best, D
  7. #pragma DATA _EEPROM Hello all, I am attempting to load many locations in the device EE memory. I am getting a compile error "File.c(54): error: failure" (where line 54 holds the input string which loads the EE locations). The line looks like: #pragma DATA _EEPROM VAR1, ... 0xFF, 0xFF,VAR25,\ VAR26, ...., VAR50,\ VAR51, ..., VAR54,\ VAR55, ..., VAR55,\ VAR56, ..., VAR60 The VARs are defined with "#define" statements previously to the pragma. It appears that there is a limit to how many locations can be pre-programmed or a limit on the input string length. If I remove 12 of the data from the pragma statement, it will compile and load the EE properly. Does someone know the answer? Thank you in advance, D
  8. What happens if you watch variables using the MPLAB ide and simulator? Regards Dave Dave, When I run the same program under the Boost IDE the watch window reports "ERROR" as the value. Just tried it with the simulator, variables are still "Out of Scope"
  9. Hello to all: After using BoostC for some time now, I find that I have a problem that I've not seen before. After a clean compile and download through ICD2 to my target (PIC 18F4550) using either run to breakpoint or steping none of my Watched variables are being updated. Only the SFRs are updated. The value column of the watch window shows "Out of Scope" for all the compiler generated variables. I'm using BoostC V6.89 with MPLAB V8.10 and ICD2. This is a recent ocurance. I'd estimate the issue is only a few days old. I've only changed the target board (an old Xilent X18A to a newer X18A) which is an exact copy of the old board. Any thoughts would be greatly appreciated. Thanks much, d
  10. Had another thought, is there documentation on linking MPLAB assembly to boost C code? I may be able to just do it the hard way. Thanks, D
  11. Hello to all: I'm not able to get my FONT array compiled. The array is larger than 128 bytes (unsigned char Font5x7[]) and will not compile. I first thought of breaking it into multiple arrays but that did not work either. I then attempted to use DBs in an ASM{} which blew-up as well (rom ....) has no better results. I'm using a 18F4550. If you have overcome this limitation please let me know. My thanks in advance. D
  12. Hello, I am extensively using the preprocessor to conditionally compile my source code. I've attempted to use the following code ( from: Sam's Teach Yourself C in 24 Hours http://aelinik.free.fr/c/ch23.htm ) In the following example: #if MACRO_NAME1 || MACRO_NAME2 printf("MACRO_NAME1 or MACRO_NAME2 is defined.\n"); #else printf("MACRO_NAME1 and MACRO_NAME2 are not defined.\n"); #endif the logical operator || is used, along with MACRO_NAME1 and MACRO_NAME2 in the expression evaluated by the #if directive. If one of the macro names, MACRO_NAME1 or MACRO_NAME2, has been defined, the expression returns a nonzero value; otherwise, the expression returns 0. My code: #if ENABLE1 && (ENABLE2 || ENABLE3) // line 732 ................... code ................... code #endif The following errors are returned: <FILE>.c(732): Expression: Expected operand: ) <FILE>c(732): Expression: Mismatched "()" 2 errors detected Error: preprocessing error I think I'm coding things correctly. If not I'd very much appreciate getting straitened out. If this is a compiler issue, I'd like to understand how to code around it. Thanks in advance for your kind help, d
  13. I have yet another issue with bit addressing .... Have an array Unsigned char SlaveReg[8]; Wanted to access at the bit level each of the 8 locations. added unsigned char *svstat = &SlaveReg[0]; This placed the correct address in svstat as shown below U8 SlaveReg[8]; U8 *svstat = &SlaveReg[s_status]; 07F2 0E00 MOVLW HIGH(gbl_SlaveReg+D'0') 07F4 6E40 MOVWF gbl_svstat+D'1' 07F6 0E2D MOVLW LOW(gbl_SlaveReg+D'0') 07F8 6E3F MOVWF gbl_svstat The compiler will not accept *svstat.bit = 1; // it sees svstat as a non-pointer It does accept *svstat = 1; // or a byte wide operation. If I instead use the array 0th element (luckily this is the major location that I need) the correct code is generated (also note address of 9th element is > 0x100) SlaveReg.bit1=1; 0144 822D BSF gbl_SlaveReg,1 Need to have a uniform bit operation methodology Like many I need to use the bits as tests in loops and easy set clear operation. This should be usable over the entire addressing range. Would love to see bits enhancement in the next compiler.
  14. Hello, I just crashed on the same rock. rs232_driver.h with no printf. I wanted to use both the LCD and the serial port so I hacked the LCD driver file to support serial printf. include the header file MySerial_driver.h after rs232 in your C src file and use lprintf for LCD and printf for the serial port. Rgds, Don //////////////////////////////////////////////////////////////////////////// // Supports rs232_driver.h //////////////////////////////////////////////////////////////////////////// // Author(s): David Hobday, Pavel Baranov // Date 15 November 2004 // // Copyright © 2004-2006 Pavel Baranov // Copyright © 2004-2006 David Hobday // Copyright © 2004 Andrew Smallridge // // // How to use - by David Hobday // ============================ // // // Add the following // // Revisions // ========= // // V1.10 David Hobday 03/03/2005 // ============================= // 1) Improved documentation in file // 2) Changed delays to delay_10us for usage on target with clock <= 4MHz // 3) Changed template to make more friendly and obvious // // V1.11 18/03/2005 // David Hobday // 1) Fixed operation with PIC18 - template arguments of incorrect type // 2) Tested with PicDem2Plus board (4MHz PIC16F877/PIC18F452) // 3) Added serial_gotoxy function. // 4) Added option to use display busy bit or time delays // 5) Added overloaded lprintf function for ROM string // 6) Added overloaded lprintf function to output numbers supported formats: // "%d" - decimal // "%X" - hex // "%b" - binart // example: display binary number six digits, '0' as file character. // lprintf( "val:%06b", numb ); // 7) Other improvements/cleanup. // // // V1.11 David Hobday 25/03/2005 // ============================= // 1) Fixed bug with lprintf( "test:%d", 0 ); not printing a 0. // 2) Added a few more comments in lprintf( const char*, int ) code // // // V1.12 Jason Sobell 03/07/2005 // ============================= // 1) Fixed display of unsigned integers >32767 // // // V1.13 David Hobday 08/07/2005 // ============================= // 1) Removed code that is no longer needed (as val is now unsigned). // 2) Tweaked Jason Sobell changes a little to reduce code size. // // // V1.14 David Hobday 11/11/2005 // ============================= // 1) Changed serial_gotoxy function so that it works as expected with 20 x 4 display // // V2.0 Don Gille 7/7/2006 //================================= // changed to support rs232_driver.h with printf function //////////////////////////////////////////////////////////////////////////// void Printf( const char *serialptr ) { char pi = 0, c; while( 1 ) { c = serialptr[pi++]; if ( !c ) return; putc( c );// Display on serial } } void Printf( rom char *serialptr ) { char pi = 0, c; while( 1 ) { c = serialptr[pi++]; if ( !c ) return; putc( c );// Display on serial } } void Printf( const char *serialptr, unsigned int val ) // JS - Accept unsigned by default { unsigned char pi = 0, bi, c, fill, baseOrBits, sign, mask; unsigned char buff[ 10 ]; // max length allow is 9 bit pad; while( 1 ) { c = serialptr[pi++]; if ( !c ) return; switch( c ) { case '%': c = serialptr[pi++]; if ( !c ) return; // Next character if zero indicates that we should zero fill output if ( c == '0' ) { fill = '0'; c = serialptr[pi++]; if ( !c ) return; } else fill = ' '; // Next character if valid digit indicates field width if( c > '0' && c <= '9' ) { pad = 1; bi = c - 48;; c = serialptr[pi++]; if ( !c ) return; } else { pad = 0; bi = sizeof( buff ) - 1; } // Next character indicates the radix (number base) sign = 0; switch( c ) { case 'd': if( val & 0x8000 ) // Negative values must be adjusted to be positive // JS { sign = '-'; val ^= 0xFFFF; // 2s complement negate // JS val++; } case 'u': baseOrBits = 10; // base ten, divide by ten per digit break; case 'X': baseOrBits = 4; // base 16, requires a 4 bit shift per digit mask = 0x0F; break; case 'b': baseOrBits = 1; // base 16, requires a 1 bit shift per digit mask = 0x01; break; default: return; // no radix } // null terminate, then reverse fill string buff[ bi ] = '\0'; bit first = true; while( bi ) { bi--; if( val || first ) { first = false; if( baseOrBits == 10 ) { c = (unsigned char)(val % 10); // JS - Optimization, use absolute of 10 val /= 10; // JS - Optimization, use absolute of 10 } else { c = val & mask; val = ((unsigned int)val) >> baseOrBits; } if( c > 9 ) c += 55; // convert to hex digits character A-F else c += 48; // convert to digit character 0-9 } else { if( sign && (bi == 0 || fill != '0') ) { c = sign; sign = 0; } else c = fill; } buff[ bi ] = c; if( pad == 0 && val == 0 && sign == 0 ) break; } // output string to display while( 1 ) { c = buff[ bi ]; if( !c ) break; putc( c );// Display on serial bi++; } break; default: putc( c );// Display on serial break; } } } #define printf Printf
  15. I've been using the BoostC product for PIC processors and found it to be a great tool. I'd like to expand the use of the compiler to my SX projects. As you know the SXKEY is the development tool of choice for SX processors. What would be ideal is a full debug interface to the SXKEY (Parallax is selling the processors now and might be open to suppling the details to hook-up the BoostC IDE). As a simpler request, just enabling a one click programming of the SX processor throught the SXKEY would be wonderful. If there is already avialable information on this, please point me to it. Thanks again, dgille
  • Create New...