Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by edt

  1. Yeah, I'd like to believe that, but it sounds like a bad urban legend email forward to me. You ever seen that one about "plucking the yew"? *gag*
  2. The MAX232 itself cannot send anything but RS-232 signals...that's why we think you're confused. I haven't done anything with USB before, but I know there are nice cheap adapters that are great for plugging RS-232 things into laptops that only have USB ports, no serial ports. If you're looking for a production solution, there are probably chip versions of the same thing or something like it.
  3. I came across the following behavior. The problem is very reproducible. I think the compiler accidentally assumes every immediate value is 0. 33: switch (3) { 34: case 0: 35: trisa = 0x01; 0003 3001 MOVLW 0x1 0004 1683 BSF 0x3, 0x5 0005 1303 BCF 0x3, 0x6 0006 0085 MOVWF 0x5 36: break; 37: case 1: 38: trisa = 0x23; 39: break; 40: } I'm seeing this with BoostC 6.70 on Windows XP. The target is a P16f877A.
  4. Just to be sure, what errors did it give you?
  5. Sorry, hadn't seen it. More information sent.
  6. Sent. Hope that's enough to track it down. Good luck
  7. I expected as much. I wish I could do more because it seems to be a very hard bug to stumble onto, but I relayed what you said about non-disclosure to my superior and he still doesn't like the idea. Do the .obj files have source-level debugging information in them? I didn't see an option to enable/disable debugging for BoostC. Maybe if they don't or there's some way to strip the information, I could try to get permission to send you the .obj files themselves (assuming the debug info has nothing to do with reproducing the bug). We're still in development, so I don't think we need to be too protective of the machine code. I verified that two of the .obj files alone are enough to trigger the bug in BoostLink.
  8. Oddly enough, I made a copy of the entire project directory, everything identical except the name of the containing directory, and it built without error. The original still has the problem, though.
  9. I have a very finicky problem involving an inline function. I can describe the problem, but unfortunately I could not duplicate it in a small test case, and I don't feel comfortable sending the entire body of source code since it's proprietary. I can work with you if you have trouble tracking it down and need any more information from my end. I created an inline function "inline void init_PLC_rx(void)" defined in a header file and called from my ISR. When I compiled the project, I got this error: "Linker Internal Error: Cant find Goto destination". I tried renaming the function, changing the function body, replacing the call with a different inline call defined in the same header file as init_PLC_rx, and moving the call itself around in the ISR, and for all except the last of those the problem disappeared. When I moved the call around, it seemed to always work below a certain point a few lines down and not at all above. I tried replacing a line in the function body (that should compile to 1 instruction, maybe with bank switching) with 0-6 nop() calls, removing lines, adding nop()s at the end, and everything compiled except the original version. It seems that even the same size code won't reproduce the problem (since I tried replacing with nops). I'm using BoostC 6.70 under MPLAB on Windows XP. The target device is a PIC16F877A.
  10. There is nothing saying that error is from the linker, "Unexpected program termination!" isone of the standard windows errors when a program dumps. The same one i have if my AV is blocking it, as it just kills the process. <{POST_SNAPBACK}> But before the error, BoostC and BoostLink are both reporting version/copyright/messages, so they're not being completely blocked from executing. Are you saying that the AV is letting a program run but restricting its access?
  11. Switch is for comparing variables to constants. Sometimes you have constants that depend on other constants. It doesn't have to use the << operator, + or - have the same problems. Or take a case like this:#define NUM1 5 #define NUM2 3 #define DIFF (NUM1 - NUM2) ... var = DIFF; switch (var) { case DIFF: ... Still, it's not critical to me. I just thought there was a chance Dave and Pavel might like to know.
  12. I wasn't paying attention to the length of code, I just looked at the problem description. Maybe there's something to it I didn't see, but... Good luck getting paid.
  13. I'm having trouble with syntax like this: #define NUM1 7 switch (var) { case (1 << NUM1): break; case (1 << 2): break; } I know the cases must be integer constants, but in normal operation SourceBoost will optimize these expressions out to constants. I can work around the issue for now. I just wanted to point it out in case you guys hadn't noticed.
  14. lol this thread is priceless. You just paid for your commercial SB license with such a simple program. You should give Dave and Pavel some commission for setting it up on their forum. Makes me want to get into contract work...
  15. Good to know. I always thought I'd already tried that with no luck. <{POST_SNAPBACK}> Note: blah = array.(x+3); Will not compile! <{POST_SNAPBACK}> Thanks, I was going to mention the same thing, but then I realized he might mean the second would compile *if the first* would (in other words, if x is a constant). I did verify that "blah = var.(2+3)" compiles. Of course, calling it "array" is strange because it doesn't make much sense to use the dot operator on an array, but I think that was just a misnomer.
  16. I was glad to leave page and bank concerns behind without bloating the assembly. I do see your point, though. Have a look at this thread: http://forum.sourceboost.com/index.php?showtopic=2227&hl=Basically, you can't! The only way is inline.
  17. Those automatically insert bank select instructions, which is what he doesn't want. I didn't know there were rules that strict about the sequence. Does that actually fail to write? Maybe for cases like this there could still be a banksel instruction. Instead of working like in MPASM: banksel reg_a movf reg_a, 0 it could force the bank select early like this: banksel movlw 0x55 movwf glb_eecon2 In other words, instead of meaning "switch to the bank of register XX now" it could mean "if the bank switches between here and the next register access, get the switch out of the way now". It could also accept an argument and ignore it so that the MPASM syntax would work.
  18. Parentheses should have the highest precedence, so I don't think it's anything to do with precedence. Although, I found that some cases work with struct member accesses and not with bit indexes (both use '.' operator), so maybe it's not with the grammar, either. Good to know. I always thought I'd already tried that with no luck.
  19. Did you get it working? Were there any other problems?
  20. The thought crossed my mind, but I glanced through them quickly and thought it was the other way around! Thanks for the clarification.
  21. The "reg.bit_index" and "array[index]" forms both require that the source is a symbol and not a derived expression. Consequently, lines of code like these cause problems: my_bit = (my_reg + 1).5; my_val = (my_bit ? arr1 : arr2)[2]; Bit indexes aren't standard C anyway, so I can't say anything about their specification, but I specifically tried the array-index-of-expression case in GCC and it worked as expected. I think this would be a fairly straightforward change to the grammar to support this syntax. Could it be done, or is there a reason it shouldn't be?
  22. Doesn't it make the code not portable to assume byte order? Is there a way around it?
  23. Oops, forgot about disabling interrupts... I looked straight at it in the datasheet, too: "; All interrupts are disabled". Thanks
  • Create New...