View previous topic :: View next topic |
Author |
Message |
lloureiro
Joined: 19 Sep 2012 Posts: 9
|
No working UART code with CCS PIC C Compiler |
Posted: Sun Apr 03, 2016 6:38 pm |
|
|
I and uart wasn't made one to other.
i did this code with compiler:
Code: |
#include <16F886.h>
#FUSES PUT //Power Up Timer
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#use delay(internal=8000000)
#use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8,stream=PORT1,errors)
|
Code: |
#include <fdx.h>
void main()
{
while(TRUE)
{
puts("some texet");
delay_ms(1000);
//TODO: User Code
}
}
|
And it gives good chars at C6, bad chars with HyperT.
I have ttl-usb cable.
Why bad chars???? :(
Thanks |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19378
|
|
Posted: Sun Apr 03, 2016 11:35 pm |
|
|
Probably baud rate.
The internal oscillator is not that accurate. On a lot of later chips it is good enough for serial, but on your chip it is 'borderline'. It only offers +/- 5% guaranteed accuracy, and this is not good enough.
Have you got a MAX232 or similar transceiver?. |
|
![](templates/subSilver/images/spacer.gif) |
lloureiro
Joined: 19 Sep 2012 Posts: 9
|
|
Posted: Mon Apr 04, 2016 1:31 am |
|
|
Yes, i have a similar transceiver, a TTl-USB Serial cable.
And i will read Datasheet and think about use external oscilator.
Thanks. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9177 Location: Greensville,Ontario
|
|
Posted: Mon Apr 04, 2016 5:20 am |
|
|
Try a slower baud rate, say 300 and only send one letter ( 'A' )with a delay, to the PC.
What you see on pin C6 should be the inverted data for an 'A'. one bits will be low, zero bits will be high. You really need an oscilloscope to view.
Now there are TWO versions of 'USB' modules. Please confirm you are using a TTL<>USB module and NOT an RS232<>USB module. They look very similar,same pinout,but you need the TTL version. You mention USB cable. If this has a DE-9 connector on it to connect to the PIC, it probably is an RS-232<>USB adapter and will give you garbage on the screen.
Hope this helps
Jay |
|
![](templates/subSilver/images/spacer.gif) |
ezflyr
Joined: 25 Oct 2010 Posts: 1019 Location: Tewksbury, MA
|
|
Posted: Mon Apr 04, 2016 10:36 am |
|
|
Hi,
I have to disagree with Ttelmah's analysis!!
I've done a lot of PIC16/PIC18 projects using the internal oscillator, and I've never encountered a situation where the internal oscillator accuracy prevented the UART from transmitting data that could not be read using Hyperterminal..... On the other hand, the forum archives are replete with examples of marginal or non-working USB-to-serial converters (RS232 or TTL output levels)...... Thus, I'm going with the 'high percentage' shot!
Also, when I see multiple threads on the same exact topic, I suspect 'loose nut behind the keyboard' as the primary issue...... _________________ John
If it's worth doing, it's worth doing in real hardware! |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9177 Location: Greensville,Ontario
|
|
Posted: Mon Apr 04, 2016 11:12 am |
|
|
There is so much 'bloatware' between the PIC and Hyperterminal, it is difficult to say where the problem really is. I know none of my $2 USB<>TTL modules have ever been 'funny'. The PIC internal Oscillators always work(though not when real cold....). Could even be simple wiring error.
It's easy to prove PIC or PC, simply loopback the TTL side of the USB<>TTL module. Every key pressed should be displayed on HT screen. If that works, it not the PC, HT or the USB<>TTL module, something with the PIC or PIC<>USB connections.
Jay |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19378
|
|
Posted: Mon Apr 04, 2016 12:20 pm |
|
|
I've done a lot of serials based on the internal oscillator.
All the ones on modern chips have worked fine.
However the first ones I did based on (guess what chip....), gave problems....
Also, there is the issue of the internal calibration value. Unlike a lot of later chips, where this is hard coded, on these it is erasable. If the chip has been erased, and the option was not selected in the programmer to preserve the calibration value, then the value will be the erased number which can easily give about 10% error. ![Sad](images/smiles/icon_sad.gif) |
|
![](templates/subSilver/images/spacer.gif) |
|