Might the PIC UART not correctly interpret the x4 clock multiplier? If it thinks the clock speed is 8MHz when in fact it's 32MHz, what it thinks is 9600 baud will be 38,400 baud.

 

Might the PIC UART not correctly interpret the x4 clock multiplier? If it thinks the clock speed is 8MHz when in fact it's 32MHz, what it thinks is 9600 baud will be 38,400 baud.

Hi J,
Interesting! This must be what's going on.
C

 

Hi C,
The PIC datasheets, show the 4* clock drives all the peripherals.
Note the compensating text image.
E
ll

 

Hi C,
The PIC datasheets, show the 4* clock drives all the peripherals.
Note the compensating text image.
E
View attachment 302394ll

Morning E,
Thanks.
I was just reading the very long BAUD section of the D/S, and it implied that this can only be done with an internal OSC. Is this true?
EDIT: NOTE: I read ages ago, that for SPI the SLAVE clock should be faster than the MASTER?
C

 

Hi C,
I would suggest the following test.

Write a short/simple Oshonsoft program, using the PIC type which is giving the Serial data problem.

Program the PIC to transmit at 9600 baud, via its internal UART a typical GPS message at say 1 message/sec.

Use this programmed PIC to emulate the normal input from from your GPS module into your main PIC.

You can use your Logic analyser to check for timing/transmission errors

E

 

Hi C,
I would suggest the following test.

Write a short/simple Oshonsoft program, using the PIC type which is giving the Serial data problem.

Program the PIC to transmit at 9600 baud, via its internal UART a typical GPS message at say 1 message/sec.

Use this programmed PIC to emulate the normal input from from your GPS module into your main PIC.

You can use your Logic analyser to check for timing/transmission errors

E

Hi E,
I have no doubt that your suggestion would work, as I have lots of working progs doing just that, that were tested with Oscilloscopes and analyser, then the progr was developed to what it is now, where SPI is working as the timing is now, and the UART is almost working, So if all fails, I will try you method, but for a while, I'l see if this can be fixed, thanks.

One question from trying to understand the BAUD section of the D/S, can BAUD be adjusted with XTL and PLL?
C.

 

Hi I, E and S,
If you error is overrun, then you are not processing the data fast enough, or getting too much of it. Try to reduce the "extra" data from the GPS module. You can remove certain strings from being sent. That removes the extra processing you have to do to process strings that may not be of value to your program. Strip down the GPS data to just what you need, no more.
Previously, I set the M8N to only read 1x sentence, that I need, and cut it in 1/2, so it's now as short as possible.

Regarding Crystals! I want to be 100% sure that Crystals and PLL can be used.
If I choose one of the XTL suggestions '7.3728mHz' and PLL does this seem ok?

We're now trying to get the BAUD down to 9600, by changing the settings.

EDIT: Is there a BAUD rate calculator like Excel, that would help in setting up?
C

 

Hi,
I 'did' and Libra office calc from the D/S. I'll order some of the suggested 7.3728 Mhz XTLs. (X4 PLL = 29.4912mHz )
Here:
C.

 

Oshonsoft compiler calculates the baud rate values from your “Crystal” frequency declaration (Define) in your code when you use a Hseropen statement. Not sure if you declare actual crystal or the 4x PLL frequency however….

 

Oshonsoft compiler calculates the baud rate values from your “Crystal” frequency declaration (Define) in your code when you use a Hseropen statement. Not sure if you declare actual crystal or the 4x PLL frequency however….

Hi S,
Up to lately, I used the Oshonsoft 9600 and configs to set-up, but my mate has (tidied up the CODE) and now uses BRG etc. I'm just trying to figure out how this all works.

I'm about to order 7.3728mHz Crystals X4 PLL, to make the values in the Calculation I posted. According to recent posts, this should make the BAUD rate more accurate.

C.

 

Hi E,
The 7.3728 XTLs are on their way!

S, said this: https://forum.allaboutcircuits.com/threads/uart-code-problem-oshonsoft.195758/post-1848763

The CODE has been tidied up, so no HSEROPEN but this:
=======================================
''setup USART for 9600 baud receive
'RCSTA = %10010000 'SPEN (RCSTA<7>) bit must be set ( = 1),
'TXSTA.BRGH = 1
'BAUDCON.BRG16 = 1
'SPBRG = 207
'PIR1.RCIF = 0
'PIE1.RCIE = 1
'PIE1.CCP1IE = 1
'INTCON.PEIE = 1
'INTCON.GIE = 1
=======================================
I've tried different settings, to see what happens, including changing the GPS BAUD RATE, the CONFIGS and CLOCK SPEED, but no good results.

HSEROPEN set TX and RX, but I'm using the TX pin as an SPI acknowledgment track between the 2x PICs, could this be a problem?
C

 

Hi C,
When you use HSEROPEN, compile as usual, then look at the ASM file that the compiler created.
It shows you what the HSEROPEN created.
E
Example:

; 4: Hseropen 9600
; exact baud rate achieved = 9603.84153; bit period = 104.125µs; baud rate error = 0.04%
BSF TRISC,6
BSF TRISC,7
MOVLW 0x40
MOVWF SPBRG
MOVLW 0x03
MOVWF SPBRGH
CLRF BAUDCON
BSF BAUDCON,BRG16
MOVLW 0x24
MOVWF TXSTA
MOVLW 0x90
MOVWF RCSTA
; 5:


Actual Basic test Code. I used,
'DEBUG 2
Hseropen 9600

Loop:
nop
Goto Loop

 

Hi C,
When you use HSEROPEN, compile as usual, then look at the ASM file that the compiler created.
It shows you what the HSEROPEN created.
E
Example:

; 4: Hseropen 9600
; exact baud rate achieved = 9603.84153; bit period = 104.125µs; baud rate error = 0.04%
BSF TRISC,6
BSF TRISC,7
MOVLW 0x40
MOVWF SPBRG
MOVLW 0x03
MOVWF SPBRGH
CLRF BAUDCON
BSF BAUDCON,BRG16
MOVLW 0x24
MOVWF TXSTA
MOVLW 0x90
MOVWF RCSTA
; 5:


Actual Basic test Code. I used,
'DEBUG 2
Hseropen 9600

Loop:
nop
Goto Loop

Hi E,
Thanks, I can almost read it.
Am I correct that
BSF TRISC,6
BSF TRISC,7
sets both TRISs to =1? *I read this in the D/S.
I'm using RC6 as an INPUT SS/CS for 4431 SLAVE
Could this be causing a problem?
C.

 

Hi C,
BSF TRISC,6 makes this pin an Input.

Examples:
Control registers, called TRISA, for Port A and TRISB for Port B, determine whether the port is an input or an output, (or a mixture.)
Writing logic 1 into a bit of TRISA causes the corresponding bit of Port A to input data.
Logic 0 makes the corresponding bit output data.
TRISB controls Port B in the same way.

TRIS stands for TRIState. It means the port is waiting for an input
rather than output a high or low signal. It's named as such because a port can have 3 states: Output High. Output Low.

 

Hi C,
BSF TRISC,6 makes this pin an Input.

Examples:
Control registers, called TRISA, for Port A and TRISB for Port B, determine whether the port is an input or an output, (or a mixture.)
Writing logic 1 into a bit of TRISA causes the corresponding bit of Port A to input data.
Logic 0 makes the corresponding bit output data.
TRISB controls Port B in the same way.

TRIS stands for TRIState. It means the port is waiting for an input
rather than output a high or low signal. It's named as such because a port can have 3 states: Output High. Output Low.

Hi E,
This is a bit strange, as I always set the TRISC.6 to =0 as it is the TX pin. Then Hseropen 9600. I didn't realise they were opposite?
Could this be the cause of the BAUD rate problems?

EDIT: I should have said I usually set TRISC.6 (TXpin) to =0, but at the moment it it set to =1 as it is now an SS/CS for 4431 SLAVE
C

 

hi C,
Read Section 9.4 on this PDF.
E

 

Transmission is just a term. the GPS and Pic have a "transmission" whether the receiver is one or transmitter is one the other or both. Saying that, you can view the periods between the transmission by scope.

I'll explain... The GPS will spew a sentence out with a terminator. You close in on that terminator and parse the sentence.

If the quiet period is long enough, by all means do it in the interrupt.. Set your scope to .5hz and watch the serial data
View attachment 302271
Two packets with a quiet time between.. That's the time when the buffer needs parsing, that's your window.

In C, I could probably do a 30 byte buffer in a quarter less time. Not saying Vlads compiler work is inefficient but it wont be as efficient as a decent C compiler optimised to the hilt. If the next string arrives while the interrupt is busy the first bit, let alone byte, will throw it out of sync. If you can use a ring buffer and wait for a start and also an end it'll be more concrete.

Look at the GPS document. You may be able to set the transmission delays giving more time to sort yourself out.

I once did a modbus job, ModBus over ethernet, but the packets were required every 100mS so I struggled to do anything. most of the time ( pic18) was just preping for modbus.

Hi I,
I tried the Osc on the GPS outputting 5/sec Here:
C

 

hi C,
Read Section 9.4 on this PDF.
E

Hi E,
I read it and it make things complicated, EDIT: If a pin is set it could be overriden to be the opposite¬
C

 

Hi C,
That image shows a 5/Sec rate with a transmission period of ~83mSec, which assuming a GPS message length of 80 characters, indicates a 9600 Baud rate.

I read it and it make things complicated, inoutoutin?

When you post a query, please explain which part don't you understand, so that we can give a meaningful answer.

 

Hi C,

I read it and it make things complicated, inoutoutin?

When you post a query, please explain what part don't you understand, so that we can give a meaningful answer.

I edited #38, hope it now makes sense.
C