Serial baud rate is some times problem

[pekka1234]

I have used PIC for 25 years, but when I use internal oscillator, baud rate suddenly doesn't work.
I see it with oscilloscope, that it is little too slow, but how much?
I made a small program, which search the right Uart speed.

[Ttelmah]

First, your program as posted cannot work.

For (i=9600; i<2000; i += 100)

'i' is set to 9600, so it is never '<2000', so the rest of the lines never get
executed.
Duh....

The obvious reason for the serial to stop working, is that the supply voltage
or temperature has changed significantly. The internal oscillator is warranted
to give better than 1% accuracy, if the supply is 3.5v, and the temperature
is 25C. If your supply is instead 5v, the accuracy drops to 2%, which is just
about the limit for normal serial operation. There is an extra error of about
0.16% from the BRG working at 9600bps, with an 8MHz oscillator.
If your temperature goes out to 0C, then the error goes out to about twice
what is allowed. This is why you always need to look at temperature and
supply voltage and the data sheet when choosing devices to operate off
the internal oscillator. In some cases you may need to read the temperature,
and adjust the oscillator frequency to compensate.
Tweaking the baud rate, has the problem that if the temperature/voltage
then changes, the corrections may be completely wrong.

The compiler doesn't have a time limit, but the registration files do. However
it is a lot of years. That it works set to 2050, tells you this.

[pekka1234]

Thelmah,

You found a small error, but You can't say it.

For ( i=9600,I<20000; i+=100)

He is a terminal picture of how I test it.

http://probyte.fi/serialtestjpg.jpg

It starts to work in about 13000baud
It has happened many times.
==
The reason for PIC change baud it is not what you said.
I was working already two weeks in my working room.
Nothing changed, it however change baud rate.
There were now power supply change , it was every time 5V,
There were no temperature change.
==
How I correct registration error, when it comes?
All other programs worked normally.

[Ttelmah]

So, what you are saying is you changed the baud rate on some code,
and then found it stopped working?.
Was this with the same compiler?. What version are you using?.

First try adding BRGH1OK to the RS232 declaration.

The compiler defaults to not allowing BRGH to be 1, and for most chips
you get more accurate baud rates if this is allowed.

Change your setups to:

[temtronic]

re: Honestly do you think you are likely to be still using a windows based
PC more than 30 years in the future?.

Funny you should say that...
I found 4 ( FOUR) BNIB sets of the NEW Windows 3.11 while trying to clean up here. Sigh, bought in 1992, so yes, 30 years ago !!
Last version that had MSDOS6.22 on floppies with the CDs.

WHERE did the time go ???

[pekka1234]

TTelmah,
No I did not change baud code, I shut to work.
I use V5.092 compiler like always.

I try to use BRGH10K, but it doesn't work. I must use Uart1, then it worked, but not changed the baud speed.
http://probyte.fi/serialtest1.jpg

I didn't do the led test, because I have a working computer.
It works normally with other projects.

I have never found any problem with PC serial devices.
==
I have used PCs more than 45 years. why not 30 years more?

I still wonder how CCS must stop using compiler after some years?

It has moved the oscillator value., but how my device work at customer?

[Ttelmah]

That means it was not using the hardware UART. which is why you had timing
problems. It is always safer to be explicit and force the hardware to be used.

[pekka1234]

How I can't use hardware Uart?
Look schematic
http://probyte.fi/onnelasch.jpg

and look the software
#use delay(clock=8000000, restart_wdt)
#use rs232(baud=9600, parity=N, xmit=PIN_C6, rcv=PIN_C7,errors, bits=8) // RS232 settings

What is wrong in these?

[newguy]

Earlier today, Ttelmah asked you to change your RS232 settings to:

[pekka1234]

Well, I did it today earlier, but I did it again.

The results are here
http://probyte.fi/with20MHz.jpg

The above is without 20 MHz crystal and below is results with 20MHz crystal.
So with 20Mhz crystal everything works well.

But how I know that the code has done without hardware?
The hardware is the same in both codes.

[newguy]

The hardware is the same, yes, but subtle differences in your code instruct the compiler to either use a soft UART or use the processor's hardware UART.

In general, if you omit the UARTx from the use rs232 statement, the compiler will create a bitbanged soft UART for you.

The other stuff you're seeing regarding whether the crystal is connected or not is just demonstrating the limits (accuracy) of the PIC's internal oscillator.

[pekka1234]

newguy

Thank you for your advice.

I must remember it,
but it doesn't clarify my oscillator problem with soft oscillator.

[Ttelmah]

First thing is to compare like with like. So you need to test with a 8MHz
crystal, not 20MHz.
You will then see what is the result of an accuracy problem, and what is
the result of speed. Running at 20MHz, there is a lot more time for things
to be done...

Now, the point about using the UART1 syntax, is it forces the hardware
UART to be used. This has become more and more necessary as more
recent compilers have come along. Historically, the earliest PIC's had just
one UART on one set of pins. Then you got PIC's with multiple UART's, and
then ones with some degree of 'mobility' for the UART began to appear. So
APFCON (giving alternate pin functions), followed by PPS (peripheral pin
select). So most modern chips cannot tell from a pin number what
peripheral is actually attached to the pins. As the compiler has evolved to
cope with this it had become increasingly important to use the UART name
syntax. I've seen code written from a ten year old compiler, that worked,
and was then recompiled on a more modern compiler, and stopped.
Investigation showed the old compiler was correctly assigning the hardware
UART, while the more recent one was getting this wrong. Using the UARTx
syntax fixed it, so is now what I recommend always.

The default value for the internal oscillator on this chip is actually
4Mhz, not 8MHz. This is why I specified the 'INTERNAL=8MHz' setting
which tells the compiler to select this. Otherwise it may be defaulting to
the 4Mhz rate, which would then give you half the baud expected.

Now when you say it sometimes works, and sometimes doesn't, are these
the same chip?. A 'classic' problem here would be that you have managed
to damage the calibration word on a chip. Or you can get examples from
the manufacturer where this is not set correctly.

[url]
https://www.microchip.com/forums/m821003.aspx
[/url]

You can see here this was a batch problem.
The calibration value is in the W register at boot, and the compiler
automatically copies this into the STATUS register to calibrate the clock.
It is also possible to damage this value.

You seem to say that the code does work when you use the UARTx syntax?.
If so, this says your compiler is sometimes not selecting the hardware
UART.

I have to ask why you have RESTART_WDT in your UART setup?.
This is almost criminally stupid!.. It is an instruction that the compiler
should not offer (understand that if you are using the watchdog, it only
becomes worthwhile if the code _ensures_ that the restart_wdt instruction
can only be reached if the code is running correctly). Having restarts
without such testing effectively negates the point of the watchdog.
In your case the watchdog is not enabled, so all it is doing is wasting time.

The BRGH1OK setting should really always be present, unless you are
working with a chip that has this as a problem.
Historically the earliest PIC's had an issue with this bit not working. This
was when the compiler was first written, so it defaults to assuming this
fault is present. However after those very few early PIC's this was fixed
and having this setting allows faster baud rates to be used. Your chip
does not have this problem, so should have the BRGH1OK setting.

[pekka1234]

I did the test with internal oscillator and crystal, both 8MHz

The results were what I expected. The internal oscillator didn't work, but external oscillator worked.

[newguy]

The manual is perhaps 25% of what's important at most. You need to also pay heed to the processor's:
a) data sheet; and
b) errata (this is critical!).

Furthermore, there's the overall circuit (what the processor is connected to) to consider as well as program flow.

The last part - program flow - is the hardest to master and, subsequently, the last critical skill to master.