View previous topic :: View next topic |
Author |
Message |
JeffLewcock
Joined: 10 Apr 2007 Posts: 29
|
(SOLVED) Problem reading data from RS232 |
Posted: Mon Jan 28, 2013 9:33 am |
|
|
I am trying to program a device to control a clock using GPS input for time.
I am having a problem getting data from the 232 I have read all the posts regarding this but cannot get even the simplest code to work.
I am reading the input on rs232 stream "GPS" and trying to transfer it to stream "PC"
I am currently using the EX_SISR.c code as a basis but this does not work.
All I get on the "PC" is
Running...
Buffered data =>
Buffered data =>
I notice that i do not get "interrupted" variable printed whether 0 or 1
Have I missed something or done something stupid ?
Nixie_Clock.h
Code: |
#include <18F67J60.h>
#device adc=16
#FUSES NOWDT //No Watch Dog Timer
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES HS //High speed Osc (> 4mhz for PCM/PCH) (>10mhz for PCD)
#FUSES NOETHLED //Ethernet LED disabled
#use delay(clock=25000000)
#use rs232(baud=4800,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8,stream=GPS,errors)
#use rs232(baud=4800,parity=N,xmit=PIN_A2,rcv=PIN_A3,bits=8,stream=PC)
#define LED PIN_B4
|
Nixie_clock.c
Last edited by JeffLewcock on Tue Jan 29, 2013 5:09 am; edited 2 times in total |
|
|
Gabriel
Joined: 03 Aug 2009 Posts: 1067 Location: Panama
|
|
Posted: Mon Jan 28, 2013 9:56 am |
|
|
.... If you post CCS Examples, You are going to have a bad time.
Read the forum rules... _________________ CCS PCM 5.078 & CCS PCH 5.093 |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19552
|
|
Posted: Mon Jan 28, 2013 10:08 am |
|
|
The obvious thing is how your RS232 transceivers are wired?.
You do realise that RS232 is a signalling standard, and the PIC cannot generate this standard?. It _requires_ a transceiver chip to generate this....
Best Wishes |
|
|
JeffLewcock
Joined: 10 Apr 2007 Posts: 29
|
|
Posted: Mon Jan 28, 2013 10:15 am |
|
|
Sorry Example code removed !!!
Brain not in gear.
I have transmitted data from both streams to the PC terminal both streams have level shifting hardware.
I have changed the example EX.SISR.c to use streams (I think).
In the isr
Code: | buffer[next_in]=fgetc(GPS); |
and added a flag "interuppted" that gets set to 1 if the isr fires.
In the main i have added
Code: | fprintf(PC,interrupted); |
and changed
printf("\r\n\Running...\r\n"); to fprintf(PC,"\r\nBuffered data => ");
and
putc( bgetc() ); to fputc(bgetc(),PC );
Jeff |
|
|
ezflyr
Joined: 25 Oct 2010 Posts: 1019 Location: Tewksbury, MA
|
|
Posted: Mon Jan 28, 2013 10:47 am |
|
|
Hi,
In addition to software issues, you may have hardware issues as well! What GPS are you connecting to the PIC? Can you post a link? Can you describe how you have it connected? Before I dug into *any* software at all, I'd want to be sure that my hardware is correct, or you'll waste a lot of time!
John |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19552
|
|
Posted: Mon Jan 28, 2013 11:41 am |
|
|
JeffLewcock wrote: | Sorry Example code removed !!!
Brain not in gear.
I have transmitted data from both streams to the PC terminal both. streams have level shifting hardware.
I have changed the example EX.SISR.c to use streams (I think).
In the isr
buffer[next_in]=fgetc(GPS);
and added a flag "interuppted" that gets set to 1 if the isr fires.
in the main i have added
fprintf(PC,interrupted);
and changed
printf("\r\n\Running...\r\n"); to fprintf(PC,"\r\nBuffered data => ");
and
putc( bgetc() ); to fputc(bgetc(),PC );
Jeff |
bkbhit already tells you a character has been received. You don't need your 'interrupted' flag.
Code: |
if (bkbhit()) {
fputc(bgetc(),PC);
}
|
Best Wishes |
|
|
JeffLewcock
Joined: 10 Apr 2007 Posts: 29
|
|
Posted: Mon Jan 28, 2013 12:42 pm |
|
|
Hi Ttelmah
Thanks for your input, I did realise this but could not work out whether somehow kbhit was being ignored so added the "interrupted" flag as a double check.
The weird thing is that the value of "interrupted" is never sent to the "PC" whatever the value whereas "Buffered data" is.
I will check the hardware again tomorrow as this seems the most likely explanation.
Thanks again
Jeff |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Mon Jan 28, 2013 5:12 pm |
|
|
... and as always: post your compiler version number! |
|
|
JeffLewcock
Joined: 10 Apr 2007 Posts: 29
|
|
Posted: Tue Jan 29, 2013 5:11 am |
|
|
Thanks Guys !
I have solved the problem, one of the cables I was using crossed pins 2 and 3 on the DB9
Feel a bit silly now !
jeff |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9246 Location: Greensville,Ontario
|
|
Posted: Tue Jan 29, 2013 6:22 am |
|
|
Hay Jeff don't feel silly.
Why 'they' changed the legacy standards when 9 pin connectors came out is beyond me and yes, I get 'confused' once in awhile as I use both 25 and 9 pin RS-232 sonncetors all the time.
sigh..so much for 'standards'!
jay |
|
|
ezflyr
Joined: 25 Oct 2010 Posts: 1019 Location: Tewksbury, MA
|
|
Posted: Tue Jan 29, 2013 7:27 am |
|
|
Hi,
The important 'take-away' for you, and anyone else reading this thread, is that's essential to make sure your hardware is working correctly before you actually begin coding in earnest! Anytime I start a new project, the first thing I do is write a collection of simple routines to test the hardware. This strategy always saves a lot of grief down the road!
John |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Tue Jan 29, 2013 8:23 am |
|
|
If pins 2/3 were swapped, did the cable have female connectors at both ends?
If so, this was probably a Null modem cable. (Unless it was homemade in which it could have been a wiring discrepancy.)
If the cable was male->female, then it is probably a wiring error. (if professionally made)
It would be a good exercise to find out the information surrounding the cable for next time... but at least your project is working now. _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
|