Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by edt

  1. I want an EZ controller (available from Sourceboost.com) to send USB info to a PC. The EZ already has a MAX232 and I can use it (and I have for two years), software and all.
    How could I use the MAX232 to send USB signals instead of rs232 signals? I have plenty of rs232 code already, I am looking for hints on USB code.

    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.

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

  3. Its going to be extremely difficult to track this down unless we can reproduce it.

    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.

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

  5. No this doesn't look like antivirus blocking the linker. If that was the case you wouldn't see any output from the linker.

    There is nothing saying that error is from the linker, "Unexpected program termination!" is

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

    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?

  6. ... interesting way to use a case statement

    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.

  7. I'm having trouble with syntax like this:

    #define NUM1 7
    switch (var) {
     case (1 << NUM1):
     case (1 << 2):

    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.

  8. edt,
    Semi-related and of interesting note, the opposite side poses no issue.

    ie.  blah = array.x; or blah = array.(x+3);

    As from common itteration loops.

    Good to know. I always thought I'd already tried that with no luck.


    blah = array.(x+3);

    Will not compile!

    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.

  9. Never the less I would still like to be able to write inline asm that is under my full control.
    I was glad to leave page and bank concerns behind without bloating the assembly. I do see your point, though.


    I haven't worked out how to use MPLAB to write asm obj modules to link with boostc.

    Have a look at this thread: http://forum.sourceboost.com/index.php?showtopic=2227&hl=

    Basically, you can't! The only way is inline.

  10. You mean like the _asm and asm wrappers that already exist?

    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:

    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.

  11. it would require another presidence rule that checks for brackets before

    a dot operator i'd expect.

    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.


    Semi-related and of interesting note, the opposite side poses no issue.

    ie.  blah = array.x; or blah = array.(x+3);

    As from common itteration loops.

    Good to know. I always thought I'd already tried that with no luck.

  12. 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?

  • Create New...