Jump to content

edt

EstablishedMember
  • Content Count

    64
  • Joined

  • Last visited

Community Reputation

0 Neutral

About edt

  • Rank
    Regular
  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.
×
×
  • Create New...