PIC16F688 Usart INT_TBE issue

Tom Jetland · Joined: 23 Jun 2011 Posts: 31 Location: UK

Hi,

I have discovered a problem with the compiler (V4.128) when using Microchips PIC16F688.

Basically, it seems that when using the feature

Tom Jetland · Joined: 23 Jun 2011 Posts: 31 Location: UK

Oh.. quick update.. I've had a reply from CCS which says

temtronic · Posted: Thu Dec 08, 2011 6:54 am

Tom, like others.....you've fallen into the 'have to update' trap.
Just because an update is available DOESN'T mean it is BETTER !
Unless you've got a few problems(several issues with different PICs) AND the updated version says it 'cure' them, do not update. Sure download the program,save in a new folder(PCM4321,PCH4125,etc) but run several tests to confirm it works better than what you have.That will take time($$$).
Same holds true for the PICs you use.Generally most projects could be done with either an 18 pinner or a 40 pin PIC.Buying into the 'newer is better,more features' may not be a smart move.R&D costs $$$, wasted time to get the new one 'running' when the old reliable would have been out the door,making you money is another 'trap'.

Tom Jetland · Joined: 23 Jun 2011 Posts: 31 Location: UK

Wise words my friend...

I'm guessing it quite straight-forward to downgrade to a previous version of compiler??

Tom

Ttelmah · Joined: 11 Mar 2010 Posts: 19504

Though a silly 'undocumented' change, the behaviour shouldn't really affect using INT_TBE. The time taken to write a whole string to a buffer, will be a few uSec at most. Now normally a buffered transmit routine, will test the buffer empty bit, and if it is set, write the first character directly to the UART, and enable INT_TBE, then write subsequent characters to the RAM buffer, so they can be sent as transmission of the first character completes.. Given the mSec or more it takes to send a character at 9600bps on the serial, there would be no perceptible change to the behaviour.
It almost sounds as if you are trying to use INT_TBE, without a RAM buffer?. If so, then there is no advantage to using the interrupt. Or possibly you are always just writing to the buffer, and not testing if the UART buffer is empty to write the first character directly?.

Best Wishes

Ttelmah · Joined: 11 Mar 2010 Posts: 19504

Though a silly 'undocumented' change, the behaviour shouldn't really affect using INT_TBE. The time taken to write a whole string to a buffer, will be a few uSec at most. Now normally a buffered transmit routine, will test the buffer empty bit, and if it is set, write the first character directly to the UART, and enable INT_TBE, then write subsequent characters to the RAM buffer, so they can be sent as transmission of the first character completes.. Given the mSec or more it takes to send a character at 9600bps on the serial, there would be no perceptible change to the behaviour.
It almost sounds as if you are trying to use INT_TBE, without a RAM buffer?. If so, then there is no advantage to using the interrupt. Or possibly you are always just writing to the buffer, and not testing if the UART buffer is empty to write the first character directly?.

Best Wishes

FvM · Joined: 27 Aug 2008 Posts: 2337 Location: Germany

I agree, that it's unclear which problems have been brought up by the said change. A possible issue could be if the user_putc() is waiting for free buffer space, which could cause a deadlock situation.

Tom, can please clarify what's the exact problem you faced with V4.128?

Tom Jetland · Joined: 23 Jun 2011 Posts: 31 Location: UK

You're quite correct FvM, the user_putc() routine is waiting for free buffer space. As mentioned previously, the TBE_INT DOES still occur inside the user_putc() on the current version of the compiler on the 16F628A (and so the buffer is emptied and the new chars are added to the buffer). It only seems to be on the 16F688 where the problem lies.

I guess I'll just increase the size of the buffer (I wish I had selected the PIC to use... I kind of 'inherited' it)....

Tom