|
|
View previous topic :: View next topic |
Author |
Message |
TopFuel Guest
|
USART at very hi speed 18F6520 |
Posted: Wed Oct 08, 2008 4:57 pm |
|
|
I have a RF transceiver demo board that uses a Pic 18F6520 as the micro,
The RF chip has a baud rate of 1.536Mbps. The demo board uses a 12.288Mhz crystal and the PLL clock option. This makes the clock freq 12.288Mhz instead of it being divided by 4 like normal. This allows the Uart to be run at 1.536Mhz. Only problem is that the effective clock rate is 49.152Mhz which is over the max of 40Mhz, so they lowered the supply v to 4.5V. It seems to works so I cannot argue that. Not a good idea though.
I am trying to develop a simple Wireless presence detector. The transmitter will send out a repeating data pattern, if the receiver see the pattern, it sets an output. So far I have the TX part working using the hardware uart Confirmed with the scope. I have written the RX code using the Uart interrupt. I ran the code with ICD2 debugger, I can see that I am receiveing some data but after a few bytes the interrupt routine stops being called and the OERR bit is set. The data that I am sending is 0x55 5 times then some data patterns for a total of 29 bytes. The Irq code sucessfully captures the 5 0x55's and 1 byte of the data then stops.
I changed the baud rate of both TX and RX to 576000 and the code worked.
I did some math and as I figure, since the instruc clock freq is 12.288Mhz that means the instruction time is about 81nsec. If the Uart is setup at 1.536Mbps then the RDA interrupt should occur every 651 * 8 nsec or 5.208usec. In that time I should be able to execute 72 instructions. My whole ISR is only 55 instructions, however the longest path in the ISR is probably only 30 instructions. I have no other IRQ's enabled. I cannot figure out why I get OERRs.
Any help or troubleshooting techniques wouild be greatly appreciated. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Oct 08, 2008 5:06 pm |
|
|
Quote: | My whole ISR is only 55 instructions |
Does that include the CCS interrupt dispacther code, to get in and out
of the isr ? Look at address 0x00008 in the .LST file to see this code. |
|
|
TopFuel Guest
|
LST file contents |
Posted: Wed Oct 08, 2008 5:31 pm |
|
|
Looks like the compiler adds 22 more instructions, That could do it,
How can I make it faster?
0008: MOVWF 05
000A: MOVFF FD8,06
000E: MOVFF FE0,07
0012: MOVLB 0
0014: MOVFF FE9,0D
0018: MOVFF FEA,08
001C: MOVFF FE1,09
0020: MOVFF FE2,0A
0024: MOVFF FD9,0B
0028: MOVFF FDA,0C
002C: MOVFF FF3,14
0030: MOVFF FF4,15
0034: MOVFF FFA,16
0038: MOVFF 00,0F
003C: MOVFF 01,10
0040: MOVFF 02,11
0044: MOVFF 03,12
0048: MOVFF 04,13
004C: BTFSS FA3.5
004E: GOTO 0058
0052: BTFSC FA4.5
0054: GOTO 009E |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Oct 08, 2008 5:36 pm |
|
|
I'm not a specialist with high speed interrupts on the 18F PICs. Either
Ttelmah or ckielstra, or maybe some others could explain it to you. |
|
|
treitmey
Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA
|
|
Posted: Thu Oct 09, 2008 8:03 am |
|
|
I'm just taking a swag here. but if the OERR is showing up, your not emptying the USART fast enough, right. So if the baud is fixed, reduce the byte count and have an inter-character timing.
USART is still running fast.
Only send 2 bytes,...that will fit in the USART, and not set OERR
Then wait some x amount of time before sending another 2 bytes.
During time x, (on the pic) you will be retrieving the data from the USART.
also, we had a chat about running past 40Mhz, The consensus seemed to be that if this is a production board, don't do it. The chip production may change slightly and you then may not find parts to build the board at desired speed. |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1636 Location: Perth, Australia
|
|
Posted: Thu Oct 09, 2008 8:32 am |
|
|
Here is how I would handle this:
Write the ISR in assembler. Use global variables in the handler located in the access bank and place your temporary variables in the access bank. Place the code directly at the HP interrupt vector address. You will be responsible for saving and restoring any registers your assembler code uses. You may need a large ring buffer depending on how long it takes your mainline to drain the ring buffer. If this is the case you will need to use an FSR pointing to RAM outside the access bank forcing you to save and restore the FSR.
Tell the compiler you do are not using HP interrupts.
In the mainline manually setup to the PIC for supporting the HP interrupt. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Thu Oct 09, 2008 3:21 pm |
|
|
Quote: | Looks like the compiler adds 22 more instructions, That could do it, | Not entirely true...
1) These 22 instructions are mostly MOVFF, an instruction taking 2 clock cycles or twice as long as the standard instruction speed.
2) These instructions are for saving the registers your interrupt might touch. You forgot to count the instructions at the end of the ISR for restoring the saved registers, about another 22 MOVFF instructions (or 44 clock cycles).
Total execution time:
- Saving registers: 44
- Your ISR: 30
- Restoring registers: 44
-----------------------------
Total: about 120 instruction clocks.
With a clock of 12.288MHz, 4 x PLL and receiving at 1.536Mbps you have 8 instruction clocks for every bit received.
Assuming your protocol has 8 bits, no parity, 1 start bit and 1 stop bit this is a total of 10 bits / received byte.
The interrupt routine should take no longer than:
8 instructions per bit * 10 bits = 80 instruction times
Your 120 clocks routine is too long and hence the overflow error.
As an additional alternative to all the previous mentioned solutions you could create a custom interrupt dispatcher which only saves and restores the registers you are really touching. This is more of a last resort solution because you have to study the assembly code to find the modified registers. A new compiler version might create different assembly code with other touched registers. If you want I can help you going this route but it's a bit too much to type here now. |
|
|
|
|
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
|