|
|
View previous topic :: View next topic |
Author |
Message |
temtronic
Joined: 01 Jul 2010 Posts: 9135 Location: Greensville,Ontario
|
|
Posted: Thu Jan 25, 2018 6:49 am |
|
|
OK, I have to ask ...
What RS232 transceiver chips are you using between the two PICs? |
|
|
doguhanpala
Joined: 05 Oct 2016 Posts: 120
|
|
Posted: Fri Jan 26, 2018 3:23 am |
|
|
temtronic wrote: | OK, I have to ask ...
What RS232 transceiver chips are you using between the two PICs? |
I do not use any chip. There is one jumper that goes from 18f2550's PIN_B1 to 16f's PIN_B1. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9135 Location: Greensville,Ontario
|
|
Posted: Fri Jan 26, 2018 5:57 am |
|
|
Ok, I've re-read this thread and I think I see a HUGE problem.
As I see it..
You've got the 2550 B1 tied to 628 B1, that's the ONLY connection between the PICs.
the 2550 sends serial data to the 628
BUT the 628 also sends data TO the 2550 using the same pin.
Normally 'RS-232' consists of 3 connections
2550 TX--> 628 RX
2550 RX <-- 628 TX
2550 GND <> 628 GND
You appear to have
2550 B1<--> 628 RX
2550 GND <> 628 GND
arrows( < , > ) show direction of signals
Your program code with the use RS232(..) configures the I/O pins for 'UART' operations. In the 628 case B1 is a UART receive only pin although later you 'toggle' it to send data to the 2550. Then the 2550 has B1 configured to be a software UART receive pin,which interrupts are not allowed.
As I see it, you've got a few options to get this project working.
1) rewire the PICs for 'normal' RS232 operations,using 3 connections AND use the hardware UARTs of both PICs.
2) 'one wire' serial is possible and CCS has example code in the FAQ section of the manual.
3) keep 2550 B1 --> 628 B1 to send data to 628 PIC and ADD a connection from a 628 PIC output pin to 2550 PIC input pin. HAve the 628 control this pin to tell the 2550 PIC 'data received'. This method has been used since RS232 was created decades ago.
Now,perhaps I have misread, it might be goo to post your current codes.
Jay |
|
|
doguhanpala
Joined: 05 Oct 2016 Posts: 120
|
|
Posted: Fri Jan 26, 2018 6:59 am |
|
|
temtronic wrote: | Ok, I've re-read this thread and I think I see a HUGE problem.
As I see it..
You've got the 2550 B1 tied to 628 B1, that's the ONLY connection between the PICs.
the 2550 sends serial data to the 628
BUT the 628 also sends data TO the 2550 using the same pin.
Normally 'RS-232' consists of 3 connections
2550 TX--> 628 RX
2550 RX <-- 628 TX
2550 GND <> 628 GND
You appear to have
2550 B1<--> 628 RX
2550 GND <> 628 GND
arrows( < , > ) show direction of signals
Your program code with the use RS232(..) configures the I/O pins for 'UART' operations. In the 628 case B1 is a UART receive only pin although later you 'toggle' it to send data to the 2550. Then the 2550 has B1 configured to be a software UART receive pin,which interrupts are not allowed.
As I see it, you've got a few options to get this project working.
1) rewire the PICs for 'normal' RS232 operations,using 3 connections AND use the hardware UARTs of both PICs.
2) 'one wire' serial is possible and CCS has example code in the FAQ section of the manual.
3) keep 2550 B1 --> 628 B1 to send data to 628 PIC and ADD a connection from a 628 PIC output pin to 2550 PIC input pin. HAve the 628 control this pin to tell the 2550 PIC 'data received'. This method has been used since RS232 was created decades ago.
Now,perhaps I have misread, it might be goo to post your current codes.
Jay |
Hello Jay,
Thank you for your answer. I have to use 1 pin to communicate 2 IC's. I cant use 18F2550s hardware uart pins because the module will get data from bluetooth and the board uses those pins for bt communication.
I am aware that using 3 connections for rs232 will make my job 'a lot' easier(wait for data,get data, do your thing, say its finished, wait again) but the project requiers 1 pin unfortunately. Using software serial solves my problems and works correctly but it doesnt feel right to me. It is not, upgradeable. You had 3 suggestions, 2 of them requires another connection so i will research one wire serial.
The codes i posted before, are the latest versions.
Thank you for your explanations.
Have a nice day! |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9135 Location: Greensville,Ontario
|
|
Posted: Fri Jan 26, 2018 7:20 am |
|
|
OK... so I'm on the right path..I'm getting older and have 100+ projects to deal with as Spring is just 53 days away...sigh.
The CCS option is from the 'commonly asked questions' section of their manual, not the FAQ section
""
There are two example programs (EX_PBUSM.C and EX_PBUSR.C) that show how to use a simple one-wire interface to transfer data between PICsĀ®. Slower data can use pin B0 and the EXT interrupt. The built-in UART may be used for high speed transfers. An RS232 driver chip may be used for long distance operations. The RS485 as well as the high speed UART require 2 pins and minor software changes. The following are some hardware configurations.
""
You should be able to modify this for your project. I'd read the examples but for some 'silly' reason the examples folder did NOT copy onto my transfer flash drive...arrgh. Upgrading from XPH to W7U on a 2nd PC has been a nightmare, I'd rather 'play with PICs' !
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19264
|
|
Posted: Fri Jan 26, 2018 7:55 am |
|
|
I suspect what he is doing can be made to work, but an 'already working' solution will really be easier.
I think what is happening, is that once the UART is disabled, and he then takes control (sending data the other way), he doesn't then set the TRIS back to the way it needs to be for UART comms.
A lot of modern chips once a peripheral is selected, it overrides the TRIS, however on older chips there are specifications in the data sheet for how the TRIS has to be set for peripherals like the UART. The compiler does this for you when initialising, but not when 're-enabling'. So after his first changeover the TRIS is set wrong and then things go wrong.
Personally I'd do it by connecting the RX pins of both UART's. Have a pull up resistor on the line so it idles high. Enable the hardware UART's at both ends, and then turn off the TXEN, so both UART's are receive only. You can then send data both ways by fully switching off the hardware UART, and transmitting using a software UART set to to use 'float_high' on the pin. Then re-enable the UART immediately. Each end when not sending, will receive anything sent the other way. No need for delays. Provided the sequencing is logical so both ends can't send at once, that gives nice half duplex comms, with the big advantage of using the hardware receive. |
|
|
|
|
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
|