Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About teejaydub

  • Rank
  1. SB7 isnt changing the configuration bits based on the debug/release dropdown menu. The debug configuration bit is not defined the the chips header file. You need to change the bit in the #pragma because its missing from the header file. (see dave's reply, ^^above) Oh - sorry, I didn't get that. Maybe this is hijacking the thread, but at least it relates to the subject line so I'll restate it: I still don't want to have to choose between Debug and Release builds that hard-code the defines (_DEBUG and _RELEASE) and hard-code the subfolders (Debug\ and Release\), because I already have conventions for existing projects and source code that serve those purposes. So I'd like to be able to either customize what those configs do and what they're called, or at least turn them off completely.
  2. Is there any plan to allow the user to configure the set of configurations? Or to turn the whole thing off? Hard-coding a relationship between the chip's config bits to output folders is useless to me, and I'm wasting a lot of time now trying to make SourceBoost 7 just do what SourceBoost 6 did with my output.
  3. This code fails with SourceBoost 6.84, BoostC 6.84, BoostLink 6.84, target PIC16F688. #include <system.h> typedef struct { char a; char b; } msg_t; msg_t msg; void setTo12(char& c) { c = 12; } // Two different ways of defining an inline function: // This one works, but bypasses type checking. #define GetValueMacro(c) setTo12(c) // This one includes type checking, but produces incorrect code. inline void GetValueInline(char& c) { setTo12(c); } main() { while (1) { msg.a = 100; msg.b = 0; // This works. //GetValueMacro(msg.b); // Result: // msg.a = 100 // msg.b = 12 // This fails - passes the address of a instead of b. GetValueInline(msg.b); // Result: // msg.a = 12 // msg.b = 0 } }
  4. I haven't used ICD2 as a debugger myself yet, but... The -rt linker option needs an address after it. Maybe since you haven't specified one, it's using 0, which means that there's no room for any code! Try, e.g., "-rt 0x700". And, it might be necessary to add "-icd2" to the linker command line for this chip.
  5. If you haven't already, I would try compiling something very simple like: #include <system.h> void main(void) { while (1) ; } And make sure it compiles under the SourceBoost IDE first. Then - where do you get the error message, when MPLAB is running the compiler or linker?
  6. I've written a little script to enable the PICkit2's current applet (v2) to program a chip automatically when the SourceBoost IDE finishes building. Details are here.
  7. I've always found this confusing. I currently have the files in the following places: C:\Program Files\Microchip\MPLAB IDE\Core\MTC Suites C:\Program Files\Microchip\Third Party\MTC Suites I don't know which one is necessary, but one or both of these seems sufficient. You do need #include <system.h> in every C file. I have an ICD2 but have only used it as a debugger, so I don't know more than that.
  8. No, I don't touch STATUS in any of this code. I'll send in a ZIP with instructions on reproducing - thanks.
  9. I've got a problem I've tracked down to faulty bank switching. Using BoostC 6.80, targeting PIC16F916, compiling under SourceBoost 6.80. There's one function whose argument (a single char) is being placed at address 0xB6 in Bank 1 of RAM, but one particular caller doesn't set the corresponding STATUS bit, so when a call is made, whatever's in the corresponding byte in Bank 0 at 0x36 gets clobbered. Other callers to the same function do the required BCF/BSF; so far it just looks like this particular one that doesn't. I see this behavior using MPLAB SIM, and the same external symptom on the programmed chip. Is this a known bug, or are there any easy things I can check? I can probably get permission from the client to send the code privately, but I just wanted to see if there's any other option before I do all that, and get the appropriate e-mail address otherwise.
  10. Yup! Didn't know it was required for that keyword. Thanks!
  11. No - removing the comma doesn't fix it. (And that's legal C anyway.)
  12. I've been able to use rom character arrays in other modules, but I'm having trouble with the code below. It looks correct to me, if I'm understanding the 'rom' keyword correctly. Is this a compiler bug, or am I overlooking something? Source: unsigned char crc; // CRC arrays for the nibble-wise routine. rom char* r1 = { 0x00, 0x5e, 0xbc, 0xe2, 0x61, 0x3f, 0xdd, 0x83, 0xc2, 0x9c, 0x7e, 0x20, 0xa3, 0xfd, 0x1f, 0x41, }; rom char* r2 = { 0x00, 0x9d, 0x23, 0xbe, 0x46, 0xdb, 0x65, 0xf8, 0x8c, 0x11, 0xaf, 0x32, 0xca, 0x57, 0xe9, 0x74 }; unsigned char crc8(unsigned char data) { unsigned char i = (data ^ crc); crc = r1[i & 0xf] ^ r2[i >> 4]; return crc; } I get these errors: failure ...\romArrayBug.c(19:8): error: failed to generate expression ...\romArrayBug.c(19:8): error: invalid operand 'r1[i & 0xf] ' ...\romArrayBug.c(19:20): error: failed to generate expression ...\romArrayBug.c(19:20): error: invalid operand '^ ' ...\romArrayBug.c(19:6): error: failed to generate expression IDE version: 6.60 Compiler: BoostC 6.60 Target device: PIC16F688 OS: XP Pro SP2
  13. I agree. I'm asking instead for a better error message that gives me something that might be helpful in dealing with the problem. Only you know what extra context info you have when that message is generated; maybe there's nothing helpful available, but if there is, I'd love to see it.
  • Create New...