global interrupts disabled mysteriously

[RF_Developer]

Hmmm, there's a bit more to it that simply having the count accesses being atomic, and I'm not totally confident that they will necessarily be on all PICs, particularly 16 series. In the classic buffer example, the entire buffer operation has to be atomic, not just updating the count. Once you've started the opertion in mainline code its bad news if the interrupt routine changes the buffer contents underneath you. Its not just a matter of the interrupt seeing half a value as it were, its that the entire buffer update process must happen atomically, both for the mainline code AND the interrupt code (which therefore should be made uninterruptible, which thankfully is generally the case with PIC unless interrupts are explictly enabled by the programmer.

The nightmare scenario is doing printfs and even putcs in serial interrupt routines! Even experienced programmers can do that, such as when they want some debug string output from ISRs.

I do not know for certain when CCS C enables and disables interrupts, nor how intelligently it does so. Its unreasonable to expect any compiler to intuit your code as to when it should and should not: it cannot decide whether your usage of varaibles is safe or not, or whether your code logic really needs interrupts turned off. So I expect it to manage that for me in scenarios where its likely to be needed. I agree it probably should really tell you when it does, after all it does when it manages interrupts to avoid recursion.

Personally I've long since given up on printf as my main means of outputting strings from any program. I much prefer to use other conversion routines and assemble strings in RAM before outputting them, often from just such a interrupt driven buffer, properly locked by me of course. I rarely need the anywhere near all of the formatting that printf provides and I find the overhead of printf to be a bad thing for my code. Great for debug stuff, but not for general purpose output, but then most of my I/O is binary/protocols/whatever and rarely good ol'ASCII strings. Your milage may vary. As such my general comment about your code is that its somewhat overcomplicated for what it does and you have made a rod for your own back. My experience is keep it simple and you'll have less hassles. all round. put another way, if you're having trouble like this; where you can't understand what's happening, then its time to rethink the architecture to simplfy it.

RF Developer

[Ttelmah]

Yes.
It is also, _vital_ to understand the difference between a chip like the Z80, and the PIC. The Z80, _has_ a stack useable for function data. The PIC doesn't. If fact the Z80 makes it even easier, having a second copy of all the main registers, with a single instruction 'swap'. The PIC has no such ability, which is why it _has_ to be totally critical regarding function/data accesses inside interrupts.
If I want to write data using printf, to an ISR, I'll use a circular buffer, and explicitly control the interrupts round all data updates. Have done this with hundreds of CCS versions (going back to some of the earliest), and never had problems.
You need to understand the limitations of the hardware, and write code to support this, not 'hope' that things which are OK on other processor families will work here.

Best Wishes