 |
 |
| View previous topic :: View next topic |
| Author |
Message |
ksraja
Joined: 08 Dec 2014
Posts: 8
|
| Software UART not working fine |
 Posted: Thu Jul 02, 2015 3:48 am |
 |
|
Hi
I am using PIC18F8722 in my project. I am interfacing 2 uarts for touch screen and another device. Now I want to communicate with one sensor using rs232, so that i am using a software uart.
It is not working fine. Here is my code:
| Code: |
#include <18F8722.h>
#device *=16
#device adc=8
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include "I2C.c"
#fuses PUT,HS,NOWDT,NOLVP,NOBROWNOUT,PROTECT
#use delay(clock=40000000)
#use rs232(baud=19200,xmit=PIN_A0,rcv=PIN_B6,ERRORS,FORCE_SW,STREAM=pcout)
#use rs232(baud=115200, xmit=PIN_C6,rcv=PIN_C7,ERRORS,UART1,STREAM=TFT)
#use rs232(baud=115200, xmit=PIN_G1,rcv=PIN_G2,ERRORS,UART2,STREAM=SENSOR)
|
Here i want to test the out data using a for() loop.
| Code: |
for(i=0;i<=255;i++)
{
putc(i, pcout);
delay_ms(10);
}
|
I am getting the output like this:
| Code: |
7F 3F 7E 1F 7D 3E 7C 0F 7B 3D 7A 1E 79 3C 78 07 77 3B 76 1D 75 3A 74 0E 73 39 72 1C 71 38 70 03 6F 37 6E 1B 6D 36 6C 0D 6B 35 6A 1A 69 34 68 06 67 33 66 19 65 32 64 0C 63 31 62 18 61 30 60 01 5F 2F 5E 17 5D 2E 5C 0B 5B 2D 5A 16 59 2C 58 05 57 2B 56 15 55 2A 54 0A 53 29 52 14 51 28 50 02 4F 27 4E 13 4D 26 4C 09 4B 25 4A 12 49 24 48 04 47 23 46 11 45 22 44 08 43 21 42 10 41 20 40 00 3F 1F 3E 0F 3D 1E 3C 07 3B 1D 3A 0E 39 1C 38 03 37 1B 36 0D 35 1A 34 06 33 19 32 0C 31 18 30 01 2F 17 2E 0B 2D 16 2C 05 2B 15 2A 0A 29 14 28 02 27 13 26 09 25 12 24 04 23 11 22 08 21 10 20 00 1F 0F 1E 07 1D 0E 1C 03 1B 0D 1A 06 19 0C 18 01 17 0B 16 05 15 0A 14 02 13 09 12 04 11 08 10 00 0F 07 0E 03 0D 06 0C 01 0B 05 0A 02 09 04 08 00 07 03 06 01 05 02 04 00 03 01 02 00 01 00 00 00 |
Can anyone give the solution for that ? |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9226
Location: Greensville,Ontario
|
|
| Posted: Thu Jul 02, 2015 4:53 am |
|
|
Couple of possibilties...
1) Pin A0 is also an analog input. Normally you must disable ALL peripherals used by an I/O pin EXCEPT the one you want. The default usually is analog is enalbed.
2) Does the PIC truly function? Have you tried the '1Hz LED' program to verify the PIC is running at 40 MHz and that A0 can toggle ?
3) Improper interfacing to PC. Be sure to use a 'MAX232' type chip between the PIC and PIC WITH a good ground.
4) There actually is a 'pattern' in the data ! What terminal program is the PC running?
Jay |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
| Re: Software UART not working fine |
| Posted: Thu Jul 02, 2015 5:25 am |
|
|
See my comments in the code below:
| ksraja wrote: |
| Code: |
#include <18F8722.h>
#device *=16 // No need for this on PIC18s.
#fuses PUT,HS,NOWDT,NOLVP,NOBROWNOUT,PROTECT
#use delay(clock=40000000) // 40MHz? Really that fast? Where's it coming from?
#use rs232(baud=19200,xmit=PIN_A0,rcv=PIN_B6,ERRORS,FORCE_SW,STREAM=pcout)
// Don't specifiy pins AND UART. It can confuse the compiler. Best just to use UART1 or 2 etc.
#use rs232(baud=115200, xmit=PIN_C6,rcv=PIN_C7,ERRORS,UART1,STREAM=TFT)
#use rs232(baud=115200, xmit=PIN_G1,rcv=PIN_G2,ERRORS,UART2,STREAM=SENSOR)
|
Here i want to test the out data using a for() loop.
| Code: |
for(i=0;i<=255;i++) // If i is an int this will never end as it cannot go above 255.
{
putc(i, pcout); // use fputc() when using a stream.
delay_ms(10);
}
|
|
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19515
|
|
| Posted: Thu Jul 02, 2015 7:21 am |
|
|
| Particularly repeat RF_Deveopers comment about the clock. Look at Table 28-6 Param 1A, the line for 'HS'. A clock 60% above the maximum allowed for the oscillator selected..... |
|
|
ksraja
Joined: 08 Dec 2014
Posts: 8
|
| Re: Software UART not working fine |
| Posted: Sun Jul 05, 2015 9:54 pm |
|
|
Hi
Thank you for your reply, in 40MHz is not working means other 2 uarts working fine, this software uart only not working fine.
In Pic support only 2 uart ?... it will not support more than 2 ... do you have any example working fine code for more than 2 uart.
i also using 40 MHz crystal ......
i will do what you are say ....but the same output only come
00 7F 3F 7E 1F 7D 3E 7C 0F 7B 3D 7A 1E 79 3C 78 07 77 3B 76 1D 75 3A 74 0E 73 39 72 1C 71 38 70 03 6F 37 6E 1B 6D 36 6C 0D 6B 35 6A 1A 69 34 68 06 67 33 66 19 65 32 64 0C 63 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19515
|
|
| Posted: Mon Jul 06, 2015 2:27 am |
|
|
You really do need to think again about your hardware.
The crystal oscillator on this chip is rated for 25MHz _maximum_. The odds of your's keeping working (especially as temperature changes, or supply voltage changes) are _tiny_. It's silly to be working with something so far out of spec.
Use an external crystal oscillator module. Feed the signal from this into the clock in pin of the PIC, and select 'EC' instead of HS. The EC input is rated to 40MHz.
I must admit I'd tend to be very suspicious that your chip might actually be running at sub frequency of the crystal, not 40MHz (this is what commonly happens when the internal oscillator is connected to a 40MHz crystal), and the other streams just happen to work, because either the devices at the other end are capable of autobaud detection, or are actually expecting a lower rate (or are actually connected to other PIC's also attempting to run at the wrong speed). Such a major error in the chip setup, gives us little (no...) confidence that your design really is doing what you think.... 
Realistically you should do a basic 'flash an LED' test and verify what speed your chip actually is running, before wasting any more time.
OK. That having been said, there is one obvious thing that could cause your problem, if the 'example' is not actually complete, but you are really trying it with other code that has interrupts enabled?. If so, then you need to add 'DISABLE_INTS' to your software UART setup. However this then introduces another problem.
The software serial is dependant on the code being able to accurately time bits by using software delays. If an interrupt occurs during the transmission of a character (or reception), then the character _will_ be sent incorrectly. DISABLE_INTS, prevents this from happening, which is OK, provided the handling of other interrupts can be delayed by up to a character time. Problem is that you have two serial streams potentially receiving characters at up to 11000cps, and possibly other interrupts as well. Since there are only two characters of hardware buffering on the serial receive, delaying for about 0.5mSec (the time needed to send a character at 19200bps), will potentially result in data loss.
If you could raise the data rate on the software stream to 115200 as well, then this problem would disappear (since interrupts would then be disabled for less time). Or if you have the ability to stop the devices on the other streams from sending data when you want to use the software serial, again the problem would vanish.
There are patterns in the data you are receiving, which say that what is being sent, is at the wrong rate. Now the CCS software UART has been around for over ten years and if the chip is clocking at the right rate, it works. So we are back to your chip very possibly not working at the speed you think it is.... |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
