Jump to content

edt

EstablishedMember
  • Content Count

    64
  • Joined

  • Last visited

Community Reputation

0 Neutral

About edt

  • Rank
    Regular
  1. edt

    Need Help!

    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. edt

    Switch On Constant

    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. edt

    Need Help!

    My favorite command is rtfm.
  5. edt

    Help

    Just to be sure, what errors did it give you?
  6. Sorry, hadn't seen it. More information sent.
  7. Sent. Hope that's enough to track it down. Good luck
  8. 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.
  9. 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.
  10. 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.
  11. 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?
  12. edt

    Switch Case Expressions

    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.
  13. 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.
  14. 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.
×