Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by teejaydub

  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
  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 //
  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 sympto
  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) { unsigne
  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.
  14. I wonder if this is the same thing I've seen: C compilation goes quickly, but linking takes either a few seconds or several minutes, with very minor changes to the code. Is the linker doing some kind of iterative memory allocation that can get caught in pathological cases? The time I saw it last, it *may* have gone away when I changed some functions from void foo() to void foo(void) but it's been so intermittent I'm not really sure. Emte, just a weird guess - are you using TortoiseSVN?
  15. I frequently get the following message from the linker: Linker Internal Error: Can't find label I'm afraid I can't give you source code to reproduce it without an NDA, and I haven't been able to narrow down the symptoms to a small section of code - in fact it may correlate with large blocks of code. So of course diagnosis on your end may be hard. But if you can add more information to that error message, specifically what label isn't found, it would at least help figure out what elicits the bug.
  16. I'm checking out BoostC. Trying to optimize a double for-loop that uses array indices, I used a pointer instead. The resulting code was much larger, in large part because the compiler's apparently using 16-bit values for pointers. This is on a 16F648A, which only has 256 bytes of RAM. So an 8-bit value should be sufficient for any pointer type, and would be more directly supported by the hardware. (E.g., "p++" would be one instruction, not three.) Any thoughts? Any way I can force this? It makes pointer use extremely inefficient.
  • Create New...