Jump to content

dgille

EstablishedMember
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

0 Neutral

About dgille

  • Rank
    Newbrie
  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;
  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 j
  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
  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 new
  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 bee
  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
  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
  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. Th
×
×
  • Create New...