CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Serial baud rate is some times problem
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
pekka1234



Joined: 28 May 2017
Posts: 80

View user's profile Send private message

Serial baud rate is some times problem
PostPosted: Sun Oct 02, 2022 4:29 am     Reply with quote

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

View user's profile Send private message

PostPosted: Sun Oct 02, 2022 9:51 am     Reply with quote

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.... Sad

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

View user's profile Send private message

PostPosted: Sun Oct 02, 2022 10:49 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Oct 03, 2022 1:26 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Oct 03, 2022 5:17 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Oct 03, 2022 6:11 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Oct 03, 2022 7:33 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Oct 03, 2022 8:10 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Oct 03, 2022 9:11 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Oct 03, 2022 9:42 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Oct 03, 2022 9:47 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Oct 03, 2022 9:58 am     Reply with quote

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

View user's profile Send private message

PostPosted: Tue Oct 04, 2022 2:30 am     Reply with quote

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

View user's profile Send private message

PostPosted: Tue Oct 04, 2022 11:45 am     Reply with quote

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

View user's profile Send private message

PostPosted: Tue Oct 04, 2022 12:33 pm     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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