UART/CODE problem Oshonsoft

camerart said:

Hi,
When setting the BAUD rate on a PIC, one of the settings is BRGH, the H stans for High.
what I want to know is, what is high and what is low?
In other words when is BRGH used?
Camerart

Click to expand...

All explained in the datasheet - it simply gives you more options of different baud rates at different clock speeds. Often using one specific option, for your specific case, producing a more accurate speed if you choose the correct option.

The datasheets usually have a table of example values, which show the percentage accuracy using each option at various speeds. The tables also show some speeds aren't available at all, if you choose the wrong option.

Generally, if you're looking for 9600 baud, you can use either, as it's likely to in the range of both, but one will be more accurate.

From the datasheet table for the 16F1827 it shows that with a 20MHz clock and BRGH as 0, 9600 baud is -1.36%, but with BRGH as 1, it's 0.16% accurate. With a 20MHz clock, and BRGH as 1, the lowest standard baud possible is 9600 baud, or 1200 baud with BRGH = 0.

Table 25.5 on page 301 of the 16F1827 datasheet dated 01/05/10

Nigel Goodwin said:

All explained in the datasheet - it simply gives you more options of different baud rates at different clock speeds. Often using one specific option, for your specific case, producing a more accurate speed if you choose the correct option.

The datasheets usually have a table of example values, which show the percentage accuracy using each option at various speeds. The tables also show some speeds aren't available at all, if you choose the wrong option.

Generally, if you're looking for 9600 baud, you can use either, as it's likely to in the range of both, but one will be more accurate.

From the datasheet table for the 16F1827 it shows that with a 20MHz clock and BRGH as 0, 9600 baud is -1.36%, but with BRGH as 1, it's 0.16% accurate. With a 20MHz clock, and BRGH as 1, the lowest standard baud possible is 9600 baud, or 1200 baud with BRGH = 0.

Table 25.5 on page 301 of the 16F1827 datasheet dated 01/05/10

Click to expand...

Hi N,
I see! so the BRGH is simply for a choice of accuracy, thanks. I've read the tables, but couldn't see the difference!

There are a few issues with reading the GPS, as what ever settings I use, HSEROPEN or the S/W settings, it only READs when the GPS istelf is set to 38400 BAUD. It also stalls after a few mins.
I'm not sure about the BAUD rate, but I've just received XTLS that if set correctly, give almost no % error, but I think they won't make much difference?
C.

Basically baud = fosc / 16* sprg or fosc / 64 *sprg

There is also a sprgh for the smallest speeds..

When Eric said on AAC Vlad gets 0.04% with a 20Mhz... I didn't believe him as I can only get 0.16%

Ian Rogers said:

Basically baud = fosc / 16* sprg or fosc / 64 *sprg

There is also a sprgh for the smallest speeds..

When Eric said on AAC Vlad gets 0.04% with a 20Mhz... I didn't believe him as I can only get 0.16%

Click to expand...

Hi I,
The calc I posted on AAC, works, but doesn't have BRGH, as I've now got 7.3738 XTLs, with the calc, I can achieve 0% error. It has benn said already, that this probably isn't the problem I'm having, but I'll fit them anyway.

As I haven't been able to set the BAUD rate to receive anything other than 38400 BAUD, I' wonder if it's only the TX that gets set?
C

Ian Rogers said:

Basically baud = fosc / 16* sprg or fosc / 64 *sprg

There is also a sprgh for the smallest speeds..

When Eric said on AAC Vlad gets 0.04% with a 20Mhz... I didn't believe him as I can only get 0.16%

Click to expand...

Considering that's what MicroChip say, I'm with you

However, if you use BRG16 = 1, then you can get 0.01% and 0.03% on a limited number of low speed baud rates - 300, 1200 and 2400. Or with BRGH = 1 and BRG16 =1, even 0% on some, and 0.03% on 9600.

Not that all this matters of course, the whole point of asynchronous connection is that it doesn't need to be perfectly accurate, as it re-syncs every ten bits. The MIcroChip table offers values as 'poor' as 3.55% out.

Nigel Goodwin said:

Considering that's what MicroChip say, I'm with you

However, if you use BRG16 = 1, then you can get 0.01% and 0.03% on a limited number of low speed baud rates - 300, 1200 and 2400. Or with BRGH = 1 and BRG16 =1, even 0% on some, and 0.03% on 9600.

Not that all this matters of course, the whole point of asynchronous connection is that it doesn't need to be perfectly accurate, as it re-syncs every ten bits. The MIcroChip table offers values as 'poor' as 3.55% out.

Click to expand...

Hi I and N,
I haven't been able to change the BAUD rate, either using Oshonsoft HSEROPEN or setting the bits like this:
--------------------------------------
RCSTA = %10010000
TXSTA.BRGH = 1
BAUDCON.BRG16 = 1
SPBRG = 207
PIR1.RCIF = 0
PIE1.RCIE = 1
PIE1.CCP1IE = 1
INTCON.PEIE = 1
INTCON.GIE = 1

------------------------------------------------------

Any other ways to do it?
C

What PIC are you using?

Beau Schwabe said:

What PIC are you using?

Click to expand...

Hi B,
18F4431.
C

With 32MHz clock I get 38461 Baud with Hseropen 38400.
Error about 0.16%

jjw said:

With 32MHz clock I get 38461 Baud with Hseropen 38400.
Error about 0.16%

Click to expand...

Hi J,
I have a thread on AAC, which explains that I can calculate and set the BAUD rate, but the GPS connected to the RX, only works when the GPS is set to 38400Baud, where I'm trying to get it to work with 9600 BAUD.
I've tried setting the PIC to 9600 using the Oshonsoft HSEROPEN 9600 and the list I posted previously, but it doesn't appear to change.
C

Do you have the clock (crystal) frequency specified correctly?

For The Popcorn said:

Do you have the clock (crystal) frequency specified correctly?

Click to expand...

Hi F,
I think so:
Define CONFIG1H = 0x06 '=8mHz x4 =32
Define CLOCK_FREQUENCY = 32
C.

camerart said:

As I haven't been able to set the BAUD rate to receive anything other than 38400 BAUD, I' wonder if it's only the TX that gets set?

Click to expand...

How are you changing GPS baud rate?
If you don't reconfigure that first, the PIC can never communicate with it!

eg. If the GPS is set for 38,400 then that's the only speed the PIC can use, for communications to work.

Remember! Nigel said it a couple of posts back.. 0.16% is fine as only 10 bits are read. The only thing I can say now is! Noise! It's working "kinda" so the Baud must be near enough. The Tx pin on the 4431 will only be used once a packet arrives, However!! If the SPI is being clocked by the 46k22 ( I think that's the main one ) then I would be looking at the PORTC pins, SPI is on PORTC as well !
I'm pretty sure Vlad "bit bangs" the SPI unless you bypassed that.

rjenkinsgb said:

How are you changing GPS baud rate?
If you don't reconfigure that first, the PIC can never communicate with it!

eg. If the GPS is set for 38,400 then that's the only speed the PIC can use, for communications to work.

Click to expand...

Hi R,
I use u-center to configure the UBLOX GPS module.
The BAUD can be changed, plus many other things, e,g, output speed etc.

I set the GPS to 9600 and after it has worked through the system to the other PIC, the out put is then gobbledegook.
If I change the GPS to 38400 BAUD it then shows correct characters.
C

Ian Rogers said:

Remember! Nigel said it a couple of posts back.. 0.16% is fine as only 10 bits are read. The only thing I can say now is! Noise! It's working "kinda" so the Baud must be near enough. The Tx pin on the 4431 will only be used once a packet arrives, However!! If the SPI is being clocked by the 46k22 ( I think that's the main one ) then I would be looking at the PORTC pins, SPI is on PORTC as well !
I'm pretty sure Vlad "bit bangs" the SPI unless you bypassed that.

Click to expand...

Hi I,
The TX pin on the 4431 is not used for TX, but for an SS/CS input.
The SPI is clocked by the MASTER 46K20.
The SPI is set to PORTD.

I tried Vlads HSEROPEN 9600 and seting the BITS as #5.
C

You should put everything back the way it was. Running at 32MHz, the baud rate isn't your problem.
As long as it's within a few percent you should be fine... you don't need "exact xtals" or half the nonsense spewed out in that AAC thread. You're barking up the wrong tree.

If the program was working and then "hangs up after a while", your problem is with the whole arrangement of the three different processors you have and the asynchronous communications between them. Getting this to work is not trivial, and getting it to work reliably is VERY non-trivial. Recovering from any error/missed event is hard. You have simple code for handling things like a buffer overrun byte in the uart, but resyncing things after an event like that takes some effort since your GPS is sending you multi-byte messages/packets 4 or 5 times a second. Just clearing the overrun won't help. Add to that the fact that you were probably in the middle of trying to transfer SPI data to your other uC at the time and the problems just compound.

This kamikaze approach of "change this, change that", posting on several different forums, and not really knowing what you're doing with all the "help" you're getting... good luck!

From what I've seen in all these threads, 90% of the problems are self-inflicted. You should have picked a more capable device and done it all in one processor.

camerart said:

Hi I,
The TX pin on the 4431 is not used for TX, but for an SS/CS input.
The SPI is clocked by the MASTER 46K20.
The SPI is set to PORTD.

I tried Vlads HSEROPEN 9600 and seting the BITS as #5.
C

Click to expand...

I Know that.... BUT!!!!!!! in your code you open the Hardware uart... that pin will still be connected to the USART.. once the SPI starts you may ( may! because I can't tell from here) causing a conflict as is is getting a 5v input from the other chip.

As Tumbleweed said.. I'll have to drop out here as I'm not helping.