View previous topic :: View next topic |
Author |
Message |
Tom Jetland
Joined: 23 Jun 2011 Posts: 31 Location: UK
|
PIC16F688 Usart INT_TBE issue |
Posted: Thu Dec 08, 2011 6:21 am |
|
|
Hi,
I have discovered a problem with the compiler (V4.128) when using Microchips PIC16F688.
Basically, it seems that when using the feature
Code: | custom_getc("More than one char"); |
(CCS's non-standard feature of passing strings (chars) to a function)
the code that the compiler is generating to process this is preventing the INT_TBE from being serviced inside the custom_getc() function.
I have never had this problem before with other PICs, and have proven that the same code works on PIC16F628A for comparison,
i.e. the interrupt is serviced inside the function.
Also, when I'm trying to use the General Purpose Register, which according to Microchips datasheet starts at 0x20 of Bank 0, I get an error from the compiler telling me that location 0x23 is reserved and cannot be used...? This disagrees with the datasheet.
Any ideas guys?
Tom
Last edited by Tom Jetland on Thu Dec 08, 2011 6:23 am; edited 1 time in total |
|
![](templates/subSilver/images/spacer.gif) |
Tom Jetland
Joined: 23 Jun 2011 Posts: 31 Location: UK
|
|
Posted: Thu Dec 08, 2011 6:22 am |
|
|
Oh.. quick update.. I've had a reply from CCS which says
Quote: | The new version has a more optimized function for passing the string to your function
and it is true interrupts are kept disabled for the duration. In the next release we will support
the following directive to go back to the old way:
#device NOSTROPT
|
Just have to wait for the new version I guess..
Tom |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9170 Location: Greensville,Ontario
|
|
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'. |
|
![](templates/subSilver/images/spacer.gif) |
Tom Jetland
Joined: 23 Jun 2011 Posts: 31 Location: UK
|
|
Posted: Thu Dec 08, 2011 8:09 am |
|
|
Wise words my friend...
I'm guessing it quite straight-forward to downgrade to a previous version of compiler??
Tom |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19360
|
|
Posted: Thu Dec 08, 2011 9:27 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19360
|
|
Posted: Thu Dec 08, 2011 10:17 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Thu Dec 08, 2011 1:24 pm |
|
|
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? |
|
![](templates/subSilver/images/spacer.gif) |
Tom Jetland
Joined: 23 Jun 2011 Posts: 31 Location: UK
|
|
Posted: Sat Dec 10, 2011 6:31 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
|