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 communication with 16F1847 - SOLVED
Goto page Previous  1, 2
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Apr 29, 2016 8:12 am     Reply with quote

It's worth knowing 'how' to do such things, which is why PCM_programmer actually showed you this.

As a comment, if the code works with 8MHz external, and gives problems with 8MHz internal, then the problem could easily be oscillator accuracy. Unfortunately the internal oscillator is not that accurate. It is normally 'good enough' for serial, but it only takes other factors to be straining things, and it could give problems...
There are ways of adjusting the clock to improve things. This is why the 1947 has the 'autobaud' feature. You have to switch the UART to this, and then send (from the PC) a specific character a couple of times, and the chip can then tweak the baud registers to get the timing right.
gjs_rsdi



Joined: 06 Feb 2006
Posts: 468
Location: Bali

View user's profile Send private message Send e-mail

PostPosted: Fri Apr 29, 2016 6:08 pm     Reply with quote

Hi Ttelmah

My previous post was to thank PCM programmer for his effort to help and to clarify things.
Want to thank you also for your help.
This topic helped me to understand many things I had no idea about them.
By the way, the rs232 at 8MHz, internal and external, works much accurate at 4,800 than at 9,600 on the 1847.
At 16MHz and 32MHz, internal and external, rs232 works at 9,600 with no errors.

Best wishes
Joe
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Sat Apr 30, 2016 12:19 am     Reply with quote

You can improve the baud rate. Smile

Add BRGH1OK to your #use RS232 declaration.

There are a number of PIC's (quite a lot of the old ones), that don't allow the BRGH bit to be set to 1 and work. CCS therefore defaults to not setting it, unless you tell it your chip is one of the ones that is OK. BRGH 1 OK (makes sense).
Without this, the BRG will be using Fosc/64, so it will be using /13 from this, to give 9615bps 1.9% error. With BRGH enabled, it can instead use Fosc/16, and then /51, to give 9803bps. 0.04% error!.....

Try it in your RS232 declaration. Very Happy

Once you know about this, if using lower CPU clocks, it becomes something you should always enable (if on a chip where this isn't a problem).
gjs_rsdi



Joined: 06 Feb 2006
Posts: 468
Location: Bali

View user's profile Send private message Send e-mail

PostPosted: Sat Apr 30, 2016 6:53 pm     Reply with quote

Hi Ttelmah

Thank you for the advice. Implemented with internal & external 8MHz clock
Code:

#use rs232(baud=4800,parity=N,UART1,bits=8,BRGH1OK,errors)
#use rs232(baud=9600,parity=N,UART1,bits=8,BRGH1OK,errors)
Both cases at 4,800 I get 42 answers from 44 requests.
The requests are answered always after read or write/read the internal EEPROM.
At 9,600 get 34 answers from 44 request.
I have to state that:
1. If I don't push fast request one after the other, both 9,600 and 4,800 are OK, I mean delay of maybe 1 second is OK.
2. With the 16F648A always OK at 8MHz, (9,600 and 4,800) no any unanswered requests

From the tables in the data sheet:
BRGH=1/Fosc=8,000,000/BRG16=0; 9,600; 9,615; 0.16%; SPBRG=51
BRGH=1/Fosc=8,000,000/BRG16=1; 9,600; 9,615; 0.16%; SPBRG=207
BRGH=1/Fosc=32,000,000/BRG16=1; 9,600; 9,604; 0.04%; SPBRG=832
I would like to ask you how I can set BRG16 ?
Try to learn as much as I can, sometimes difficult, "Can't teach old dog new tricks" Smile

Best wishes
Joe
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Sun May 01, 2016 2:48 am     Reply with quote

With BRGH1OK, this will be selected.

You should not be getting _any_ losses.
If I see anything over perhaps one byte in a million corrupted, then I'll be looking for what the problem is.
First thing is if you have something like a DFM, or digital scope, actually measure serial bits from your PC. It is surprising how many sometimes have very poor timing. Async serial can typically withstand perhaps 6% total timing errors, but this is the sum of the errors from both ends.
A timing error won't 'lose' the byte, you will get a corrupted byte. Re-write your code to see what is actually being received. If you know that byte 'x' is received as 'y', then by drawing out the bit patterns for the byte, you can see what the clock relationship actually is.
Honestly, I would be suspicious that you actually have a problem inside your code, that is being shown more as the data rate goes faster. Ignore the EEPROM code for a while, and instead work out a way to actually see what is being received (write the sequence into RAM, and then send it back in - say - hex). Then you can see if the chip is genuinely seeing the wrong byte, and since the returned data is in a different format, if it is corrupted, the corruption will be obvious.

I'm very suspicious your problem is _not_ serial bit rate timing related.
gjs_rsdi



Joined: 06 Feb 2006
Posts: 468
Location: Bali

View user's profile Send private message Send e-mail

PostPosted: Sun May 01, 2016 7:42 pm     Reply with quote

Hi Ttelmah

Thank you again for the advice.
I made a new program that have just the serial communication based on the PCM programmer program:

Code:
#use delay(internal=8MHz)
#use rs232(baud=9600,parity=N,UART1,bits=8,errors)
#byte APFCON0 = getenv("SFR:APFCON0")
#byte APFCON1 = getenv("SFR:APFCON1")


My program includes 8 data to send and 8 data to receive.
300 consecutive fast requests had no any error, so as you wrote, the problem should be in my software.
I have buttons, LED's, PWM and EEPROM read, write/read in addition to the rs232
I should see how I can find the problem (maybe with the CCS editor compair) as with the 16F648A I have no any missing messages and no any problems (after the corrections made to the advises in my previous topic). The rs232 settings in 16F648A are bellow:

Code:
#FUSES EC_IO//for external clock                 
#use delay(clock=8000000,RESTART_WDT)
#use rs232(baud=9600,parity=N,xmit=PIN_B2,rcv=PIN_B1,bits=8,restart_wdt)


I will post the findings, maybe it will help other people.
Best wishes
Joe
gjs_rsdi



Joined: 06 Feb 2006
Posts: 468
Location: Bali

View user's profile Send private message Send e-mail

PostPosted: Sun May 01, 2016 8:13 pm     Reply with quote

Back again

Made compare with the CCS IDE.
The only differences are in the #FUSES, but I think it is just difference between the old/new controllers and rs232:
Code:
#include <16F648A.h>
#FUSES WDT                 
#FUSES EC_IO                 
#use delay(clock=8000000,RESTART_WDT)
#FUSES BROWNOUT,MCLR,NOLVP,PUT
#FUSES PROTECT
#FUSES NOCPD
#use rs232(baud=9600,parity=N,xmit=PIN_B2,rcv=PIN_B1,bits=8,restart_wdt)


Code:
#include <16F1847.h>
#device ADC=10
#FUSES WDT                      
#FUSES ECH,NOCLKOUT
#FUSES PLL_SW            
#FUSES NOIESO               
#FUSES BORV25                   
#FUSES MCLR,NOLVP,PUT         
#FUSES NOFCMEN
#FUSES STVREN                  
#FUSES PROTECT
#FUSES NOCPD
#use delay(clock=8MHz)
#use rs232(baud=9600,parity=N,UART1,bits=8,BRGH1OK,errors)
#byte APFCON0 = getenv("SFR:APFCON0")
#byte APFCON1 = getenv("SFR:APFCON1")

APFCON0=APFCON1=0;//in main


Using the PCM C Compiler, Version 3.249 for 16F648A
using the CCS PCM C Compiler, Version 5.056d for 16F1847
I suppose I am missing something or maybe the demo compiler have some limits. I have to mention also that my Internet is very slow and the demo compiler works just while I am online

Best wishes
Joe
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon May 02, 2016 12:35 am     Reply with quote

First, you are not resetting the watchdog in delays/serial in the new code. Big difference.

I removed the watchdog stuff, because I was suggesting you thought again about whether the watchdog is doing you any good at all, and searched here, and elsewhere online about this.

The point about a watchdog, is that it should _only_ be reset, if the code is running correctly. If you are writing proper watchdog code, you have tests for each operation that the code is performing having worked correctly, and only if every one of these passes, get to a 'restart_wdt' instruction. You lay this code out so that it cannot be reached by any other route (so have a 'return' instruction coded the line before the entry point to the tests).

This way the watchdog only gets reset if everything is working properly.
The problem otherwise is that if you have 'restart_wdt' instructions scattered through the code, the program can go completely wrong, and be randomly jumping around in the code, yet the watchdog still gets restarted. Sad
This is pointless.
Unfortunately the CCS authors, encourage the 'functionless' way of using the watchdog.

Then the watchdog timer on the later chip is very different from the older one. The 648, has a watchdog that typically trips in 18mSec, but can be between 7 and 33uSec according to chip. The 1847 has a watchdog that trips slightly faster (16mSec), but with less variation. Does your code guarantee that a reset_wdt, _will_ always be reached in less than this?.

Then you don't set APFCON1. The bottom bit of this is the TX line.
gjs_rsdi



Joined: 06 Feb 2006
Posts: 468
Location: Bali

View user's profile Send private message Send e-mail

PostPosted: Mon May 02, 2016 2:34 am     Reply with quote

Hi Ttelmah

Thank you for the answer
1.WDT
I have tested all the functions that are working correct before enable it. I am setting it in the main to reset after 128ms (with the 16F1847), my programs take about 500us including interrupt routines. The reason I am enable it is that the board is close to an AC motor working with 220VAC. I had a project in the past with AC motors (assembler, 16C84) that didn't work just with RC clock because the EMI on the lines.
Added reset_wdt to the rs232 and the delay, still missing answers
Disable WDT, no change in the behavior, still missing answers.
2. Regarding APFCON1, I am clearing the bit (bit0) in the main as I want to use B2 as the TX line

I will try to close the functions one by one and see when the serial communication will start working correct.

Best wishes
Joe
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon May 02, 2016 3:10 am     Reply with quote

All good steps.

One thing that is perhaps worth saying, is that later chips are often more prone to problems from EMI, than older chips. As internal tracks get thinner, they become more sensitive. Things that are vital with this are:
1) Ensuring no line ever 'floats'. All pins on the PIC should either be set as outputs and driven, or connected to external circuitry that drives them.
2) Being really careful about HF decoupling close to the chip, and everything that drives the chip.
3) Looking at how lines are actually routed. Avoid taking lines connecting to high power 'past' the PIC. Look at where grounds go 'back' to. Think about where all currents actually flow, and how these flows will induce voltages in adjacent lines.

I've got recent PIC's actually directly controlling circuits handling over 800A (80KW), without any EMI problems, but this was down to a lot of care/circuit debugging....
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 Previous  1, 2
Page 2 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