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

is it necessary to get value from int_rda?
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
temtronic



Joined: 01 Jul 2010
Posts: 6254
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Jan 25, 2018 6:49 am     Reply with quote

OK, I have to ask ...
What RS232 transceiver chips are you using between the two PICs?
doguhanpala



Joined: 05 Oct 2016
Posts: 95

View user's profile Send private message

PostPosted: Fri Jan 26, 2018 3:23 am     Reply with quote

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: 6254
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Jan 26, 2018 5:57 am     Reply with quote

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: 95

View user's profile Send private message

PostPosted: Fri Jan 26, 2018 6:59 am     Reply with quote

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: 6254
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Jan 26, 2018 7:20 am     Reply with quote

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: 13552

View user's profile Send private message

PostPosted: Fri Jan 26, 2018 7:55 am     Reply with quote

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.
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