Siddy

Now I get it. I suppose I was expecting the following ASM result, as I would have written it: ;if H_Byte & 0x10 Then movlw 16 andwf H_BYTE,W btfsc STATUS,Z goto ENDIF7 'result was zero 'result was nonzero ...but that's not in line with the GCB architecture, which has to handle 32-bit variables, etc. Never mind, it's GCB--I could write in ASM right there like that if I wanted ;-). Thanks again.

Regarding the delays. Historical. These delays are there to support the 1000+ parts we support and we need to maintain backwards compatibility with the existing user programs. To avoid holding the entire project back because of older conventions, I would suggest permanently archiving a "milestone" version of GCB for older projects, with a download link. That way, current and future projects don't get held back by older conventions--and people with older projects can still use them with the older...

Regarding the delays. Historical. These delays are there to support the 1000+ parts we support and we need to maintain backwards compatibility with the existing user programs. To avoid holding the entire project back because of older conventions, I would suggest permanently archiving a "milestone" version of GCB for older projects, with a download link. That way, current and future projects don't get held back by older conventions--and people with older projects can still use them with the older...

I could easily do that, but then nobody else would be able to enjoy the benefits of full speed RS-232 transmission. Just trying to help improve an excellent addition to the PIC programming world.

I could easily do that, but then nobody else would be able to enjoy the benefits of full speed RS-232 transmission.

Aha, that makes sense. I suppose that means that the compiler is viewing it as if H_Byte and (0x10 = 0x10) Then and concluding that the last part is of no value. Regardless, checking the low bit for true/false seems to be the GCB "architecture" style (all routines based around that), so that'll just take some slightly different thinking (on my part). My code is working with the bit check, but if I ever have to check the result of an AND mask, I'll have to remember to put parentheses around it. T...

Aha, that makes sense. I suppose that means that the compiler is viewing it as if H_Byte and (0x10 = 0x10) Then and concluding that the last part is of no value. Regardless, checking the low bit for true/false seems to be the GCB "architecture" style (all routines based around that), so that'll just take some slightly different thinking. My code is working with the bit check, but if I ever have to check the result of an AND mask, I'll have to remember to put parentheses around it. Thanks.

Regarding polling of TRMT: Attached to this post are the timing diagrams from the Microchip PIC16F15345 datasheet, DS40001865B, pages 429-430 (which are by NO means specific to this PIC MCU--it's just what I'm currently working with). One is "Async Single", which shows the waveforms for a single transmit. Notice that TRMT is held LOW until the EUSART has finished sending the entire byte. Waiting for TRMT to rise before returning has the exact code equivalent of sending the RS-232 data via bit-banging--COMPLETELY...