| View previous topic :: View next topic |
| Author |
Message |
stoyanoff
Joined: 20 Jul 2011
Posts: 375
|
| Problem with communication between PIC and PC(RS232) |
 Posted: Wed Feb 06, 2013 4:43 am |
 |
|
Hi, everyone! I have a problem with RS232 communication between PC and PIC18F2550. Here is my schematics :http://dox.bg/files/dw?a=3b528d5ba9
On the PC I made the program from this example : http://www.codeproject.com/Articles/8605/Serial-Communication-using-C-and-Whidbey I`ve used it before it works fine!
Here is my code for 18F2550 :
| Code: |
#include <18F2550.h>
#fuses HS,NOWDT
#use delay(clock=20M)
#USE RS232 (baud=9600, xmit=PIN_C6,rcv=PIN_C7,BITS=8,PARITY=N,ERRORS)
char RSdata;
void main()
{
RSdata=0;
while(1)
{
putc(5);
//putc('A');
}
}
|
The problem is I don`t recieve anything on the PC. I tried to transmit from the PC, but again the microcontroller doesn`t recieve anything.
Can you tell me what I`m doing wrong?
Thanks! |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19467
|
|
| Posted: Wed Feb 06, 2013 4:56 am |
|
|
This is becoming a 'classic'.
Problem is that with a lot of chips now the defaults for fuses are not what you expect. On the PIC18F2550, there is a divider between the crystal, and the CPU, and the default for this is /4, unless you actually specify the /1 fuse. So your chip is running at 5MHz, not 20MHz....
Compile the program, and look at the end of the .LST file:
| Code: |
Configuration Fuses:
Word 1: CC3F PLL12 CPUDIV4 USBDIV HS FCMEN IESO
Word 2: 1E3E PUT BROWNOUT BORV21 VREGEN NOWDT WDT32768
Word 3: 8700 CCP2C1 PBADEN LPT1OSC MCLR
Word 4: 0081 STVREN NOLVP NOXINST NODEBUG
Word 5: C00F NOPROTECT NOCPB NOCPD
Word 6: E00F NOWRT NOWRTC NOWRTB NOWRTD
Word 7: 400F NOEBTR NOEBTRB
|
You need:
HS, CPUDIV1, NOVREGEN, NOPBADEN, NOWDT
As a starting point.
(I'm turning off the USB regulator - no point in having this on, unless you are using USB, and setting portB to be digital). The critical one though is CPUDIV1.
Best Wishes |
|
|
stoyanoff
Joined: 20 Jul 2011
Posts: 375
|
|
| Posted: Sat Feb 09, 2013 3:59 am |
|
|
OK! I did this. Now I can pass data to the controller but when I try to pass data to the PC there is a problem. The controller blocks.
| Code: |
#include <18F2550.h>
#fuses HS, CPUDIV1, NOVREGEN, NOPBADEN, NOWDT
#use delay(clock=20M)
#use RS232(baud=9600, xmit=PIN_C6,rcv=PIN_C7,BITS=8,PARITY=N)
void main()
{
while(1)
{
putc('a');
}
}
|
When I run this code in debugger mode and every time it block to the row #use rs232...
It just can`t pass this. And it doesn`t transmit. I tried the option step forward but ... nothing. It stays there.
Any ideas why??? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9207
Location: Greensville,Ontario
|
|
| Posted: Sat Feb 09, 2013 6:12 am |
|
|
IF what you're meaning is that you compile the program using the 'debug' mode and not 'release', then downloaded to the PIC and tried on real hardware and it stalled....
Then
yes, it will NOT run correctly
You must set the build configuration to 'release', press F10, then download the code into the PIC.
With newer versions of MPLAB , you can change the default build configuration to be 'release',older versions you have to 'patch'.
hth
jay |
|
|
stoyanoff
Joined: 20 Jul 2011
Posts: 375
|
|
| Posted: Sat Feb 09, 2013 6:36 am |
|
|
I tried to run this project with MPlab SIM. And again I have the same block
See the picture:http://dox.bg/files/dw?a=e3e96d73ff
What`s happenning here? When I press RUN it`s running, but when I press STOP it`s in the same possition and there is nothing on the exits(which is logical if it doesn`t reach the transmition part). I tried to make a new project and to restart the PC - nothing...
How to fix this??? How to set the mplab to release???
When I add a breakpoint start to run but it doesn`t pass anything to the exit.
Look at this simulation: http://dox.bg/files/dw?a=bdce542f99
And when I compile it and load it to the microcontroller it doesn`t send anything on the line. It stays high(5V) and nothing.....
When I change xmit with rcv(xmit=PIN_C7,rcv=PIN_C6) it starts to work: http://dox.bg/files/dw?a=1f10071db6
Am I mixed the pin direction??? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19467
|
|
| Posted: Sat Feb 09, 2013 7:12 am |
|
|
When you swap the pins, it switches to using software RS232, instead of the hardware UART.
It merrily works, both in MPLAB, and in a real chip for me. Letter a's merrily being clocked out on C6. I have made sure the SPI is turned off though - setup_spi(FALSE), since this is the only other device sharing the pins. I also programmed the input pin (C7) high in MPLAB, since otherwise this will be continuously receiving data.
Best Wishes |
|
|
stoyanoff
Joined: 20 Jul 2011
Posts: 375
|
|
| Posted: Sat Feb 09, 2013 7:56 am |
|
|
I want to shoot myself! The problem is not in the microcontroller but in the software on the PC. The original program from the link above is using command for reading string, but I`m sending only one char!
Thanks, everyone! |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9207
Location: Greensville,Ontario
|
|
| Posted: Sat Feb 09, 2013 8:22 am |
|
|
build vs release...
From MPLAB's main menu
select 'Project'
then select 'build configuration'
then select 'release'.
While most programmers default to 'build', I've set mine to 'release' as I do not use any simulators,using real PICs in the real world to 'debug' any problems.After all it HAS to work in the real world.
Mid versions of MPLAB had the deafult set to 'build', causing me no end of grief,so I contacted them and they sent me a 'patch' to default to 'release'. Newer versions should save the project build configuration as you set it. I haven't tried since I've had no need to upgrade past V8.86.
hth
jay |
|
|
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Sat Feb 09, 2013 6:42 pm |
|
|
Hi,
When I read this thread originally, this statement "On the PC I made the program from this example : http://www.codeproject.com/Articles/8605/Serial-Communication-using-C-and-Whidbey" really got my attention. One of the first rules of troubleshooting/debugging is to reduce the number of variables as much as possible. In effect, you were using one piece of unknown code to test another piece of unknown code with totally predictable results!
John |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
