|
|
View previous topic :: View next topic |
Author |
Message |
pekka1234
Joined: 28 May 2017 Posts: 80
|
Serial baud rate is some times problem |
Posted: Sun Oct 02, 2022 4:29 am |
|
|
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.
Code: |
#include <16F886.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES INTRC_IO //Internal RC Osc, no CLKOUT
#FUSES NOPROTECT //Code not protected from reading
#FUSES IESO //Internal External Switch Over mode enabled
#FUSES BROWNOUT //Reset when brownout detected
#FUSES PUT //Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT //Program memory not write protected
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES NOMCLR //Master Clear pin not enabled
#FUSES NOWRT
#use delay(clock=8000000, restart_wdt)
#use rs232(baud=9600, parity=N, xmit=PIN_C6, rcv=PIN_C7,errors, bits=8) // RS232 settings
void main()
{
unsigned int16 i;
For (i=9600; i<2000; i += 100)
{
setup_uart(i); // test new baud
printf("\rTest baud %ld", i);// try write something to serial connection
delay_ms(1000); // it will give about 10 right signals. From thee you can select new rs232 setup
}
}
|
I had also other problem with my working computer.
CCS program doesn't work any more. This computer has no Internet connection.
I fetch CCS files from other, but working computer.
They doesn't help. What was the problem?
The time has changed to year 2090. I change the time 2050 and the CCS started to work. I have old 2032 battery, and it doesn't keep the time.
So, do you know how many years CCS compiler works? |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19463
|
|
Posted: Sun Oct 02, 2022 9:51 am |
|
|
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
Joined: 28 May 2017 Posts: 80
|
|
Posted: Sun Oct 02, 2022 10:49 am |
|
|
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
Joined: 11 Mar 2010 Posts: 19463
|
|
Posted: Mon Oct 03, 2022 1:26 am |
|
|
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:
Code: |
#include <16F886.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES NOPROTECT //Code not protected from reading
#FUSES BROWNOUT //Reset when brownout detected
#FUSES PUT //Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT //Program memory not write protected
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES NOMCLR //Master Clear pin not enabled
#FUSES NOWRT
#use delay(internal=8MHz, restart_wdt)
#use rs232(baud=9600, parity=N, UART1, errors, bits=8, BRGH1OK) // RS232 settings
|
Prove that your clock is running at the right speed. Do a simple 'flash an
LED' test, and check with a stopwatch. This is always the first place
to start when having baud problems.
Honestly do you think you are likely to be still using a windows based
PC more than 30 years in the future?. If you are, and have a problem then
just do as you are now, and tweak the clock value. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9205 Location: Greensville,Ontario
|
|
Posted: Mon Oct 03, 2022 5:17 am |
|
|
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
Joined: 28 May 2017 Posts: 80
|
|
Posted: Mon Oct 03, 2022 6:11 am |
|
|
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
Joined: 11 Mar 2010 Posts: 19463
|
|
Posted: Mon Oct 03, 2022 7:33 am |
|
|
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
Joined: 28 May 2017 Posts: 80
|
|
Posted: Mon Oct 03, 2022 8:10 am |
|
|
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
Joined: 24 Jun 2004 Posts: 1907
|
|
Posted: Mon Oct 03, 2022 9:11 am |
|
|
Earlier today, Ttelmah asked you to change your RS232 settings to:
Code: | #use rs232(baud=9600, parity=N, UART1, errors, bits=8, BRGH1OK) // RS232 settings |
The reason he asked you to do this is because the compiler will (often) create a soft UART (i.e. a bitbanged UART) if you omit the crucial "UART1" term above.
Please try making the above change and see what happens. |
|
|
pekka1234
Joined: 28 May 2017 Posts: 80
|
|
Posted: Mon Oct 03, 2022 9:42 am |
|
|
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
Joined: 24 Jun 2004 Posts: 1907
|
|
Posted: Mon Oct 03, 2022 9:47 am |
|
|
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
Joined: 28 May 2017 Posts: 80
|
|
Posted: Mon Oct 03, 2022 9:58 am |
|
|
newguy
Thank you for your advice.
I must remember it,
but it doesn't clarify my oscillator problem with soft oscillator. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19463
|
|
Posted: Tue Oct 04, 2022 2:30 am |
|
|
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
Joined: 28 May 2017 Posts: 80
|
|
Posted: Tue Oct 04, 2022 11:45 am |
|
|
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.
Code: |
#include <16F886.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES NOPROTECT //Code not protected from reading
#FUSES BROWNOUT //Reset when brownout detected
#FUSES PUT //Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT //Program memory not write protected
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES NOMCLR //Master Clear pin not enabled
#FUSES NOWRT
#use delay (crystal=8000000)
//#use delay (internal=8000000)
#use rs232(baud=9600, parity=N, UART1, errors, bits=8, BRGH1OK) // RS232 settings
void main()
{
unsigned int16 i;
For (i=9600; i<20000; i += 100)
{
setup_uart(i); // test new baud
printf("\rTest baud %ld", i);// try write something to serial connection
delay_ms(1000); // it will give about 10 right signals. From there you can select new rs232 setup
}
}
|
The results are here
http://probyte.fi/Serialtest3.jpg
I am a not internal programmer expert.
I must use external crystal with such cases.
This BRGH1OK setting is not explained clearly in manual.
But there are hundreds or thousands similar things in PIC programming |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1907
|
|
Posted: Tue Oct 04, 2022 12:33 pm |
|
|
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. |
|
|
|
|
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
|