 |
 |
| View previous topic :: View next topic |
| Author |
Message |
SkeeterHawk
Joined: 16 Oct 2010
Posts: 59
Location: Florissant, CO
|
| Timer Changing UART Baud Rate |
 Posted: Tue Apr 07, 2026 2:34 pm |
 |
|
I found a weird problem (At least I think it is weird) and would like to get your feedback on what may be going on.
First off, I am using compiler version 5.114
I recently added a timer to my project that has been working and communicating via UART to the computer. Here is the statement where I initialize the UART:
| Code: | | #use rs232(baud=19200,parity=N,xmit=PIN_C7,rcv=PIN_C5,bits=8,stream=Computer) |
I recently turned on Timer2 using this code to initialize it:
| Code: | | setup_timer_2((T2_START_IMMEDIATELY | T2_CLK_HFINTRC | T2_DIV_BY_32), 32, 1); |
This made it interrupt at 15.2kHz, which worked fine for my application to send step pulses to a stepper controller.
My PIC18F57Q84 is running with the internal oscillator at 32MHz.
After adding my code for the timer/stepper, my communications routine stopped working, so I figured that I made a typo in there that I would track down later. Well, after adding some more monitoring hardware to the stepper, I wanted to send it to the computer so that I could watch its behavior, so I remarked out the call to my usual UART routine, and simply wrote a fprintf statement to output the data. Turned out there was gibberish on the terminal. I just tried to print "Testing" and it was still gibberish. I finally got down to where I was using a fputc statement to write one letter:
| Code: | | fputc('U', Computer); |
I picked the ASCII "U" because it was 0x55 in HEX, so I could see where the end of the character was before the stop bit (since the MSB was 0), and it would just toggle back and forth outputting the 0x55. It turned out that the 8 bits plus the start bit took 620uS to send. 620uS/9 = 68uS per bit. Since the time is 1/baud rate, I inverted that to get 14.52k baud...much slower than the 19.2K I was set up for.
When I remarked out the timer that I had added for the stepper motor, the transaction jumped up to 468uS. 468uS/9 = 52uS. 1/52uS 19.23k baud, and now the communication worked.
I am going to slow down my stepper controller so that it will respond the same to a slower step rate frequency, but this really surprised me that just adding a timer running at 15.2kHz with a processor going 32MHz would be able to throw off the baud rate that badly. Does anyone else have experience with an issue like this? Thanks for the feedback!!
_________________
Life is too short to only write code in assembly... |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9632
Location: Greensville,Ontario
|
|
| Posted: Tue Apr 07, 2026 2:38 pm |
|
|
| hmm.. I'd cut a small program that shows this 'feature' and then dump the listing and SEE where the change in UART speed has happened. |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1933
|
|
| Posted: Tue Apr 07, 2026 4:50 pm |
|
|
Have a look at the disassembly in symbolic mode and in the .... can't remember the term .... let's just say "not symbolic" mode too.
Sounds very suspiciously like the compiler's built in function to use timer 2 is corrupting the UART's baud rate generator (BRG) settings. All you need to do is cut a very short sample program that demonstrates the problem and have a look at the disassembly to confirm that the timer 2 setup is not playing nice. Once confirmed, send to CCS and they'll likely have a fix prepared quite quickly.
In the meantime just set up timer 2 yourself by manually setting the appropriate registers and Bob's your uncle. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 20058
|
|
| Posted: Wed Apr 08, 2026 1:51 am |
|
|
15.2KHz, is a very fast interrupt to try to handle. Interrupt every 500
instructions. Given it takes something like 60 instructions just to get
into and out of the interrupt, doing nothing at all, it would not take
much code in the interrupt to cause timing issues elsewhere.
Even with no extra code. the interrupt will slow the rest of the code
a lot. Honestly, I'd suggest you switch up to 64MHz, if you want to
interrupt this fast.
The most likely problems that the compiler is implementing a software
UART, not a hardware one. This makes sense, since this is a PPS chip.
Change your UART setup to:
| Code: |
#PIN_SELECT U1TX=PN_C7
#PIN_SELECT U1RX=PIN_C6
#use rs232(UART1, baud=19200, parity=N, bits=8, STREAM=Computer)
|
If you look at the data sheet pin allocations, U1TX is not shown on pin
C7, and even if it was, on PPS chips the compiler does not know about
default assignments. |
|
|
SkeeterHawk
Joined: 16 Oct 2010
Posts: 59
Location: Florissant, CO
|
|
| Posted: Thu Apr 09, 2026 2:09 pm |
|
|
That was a fantastic observation Ttelmah!! I didn't even consider that it may have created a software UART. I will take both of your suggestions and up the processor speed as well as force those pins to the UART using the Peripheral Pin Select. I will update this post with the results.
In other news, for NewGuy, I thought that the way to look at the disassembly was to go to View>C/ASM list. I don't see a way to show it as "Symbolic" or "Non-Symbolic". Is there another way of doing that? I'd appreciate the insight here. Thank you!
_________________
Life is too short to only write code in assembly... |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
