|
|
View previous topic :: View next topic |
Author |
Message |
littlewhitedot
Joined: 27 Nov 2016 Posts: 5
|
Software uart |
Posted: Sun Jan 15, 2017 3:30 am |
|
|
Hi all, I am trying to implement SDI-12 connection to one of my PIC's GPIO. But SDI-12 is using both RX and TX on single data wire. How am I suppose to implement this? I know that:
Code: | #use RS232(BAUD=1200, STREAM=SDI12, xmit=PIN_D3, rcv=PIN_D3 PARITY=N, BITS=8) |
is impossible. Please help! Thank lots! |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19480
|
|
Posted: Sun Jan 15, 2017 4:33 am |
|
|
Use two streams:
Code: |
#use RS232(BAUD=1200, STREAM=SDI12OUT, xmit=PIN_D3, PARITY=N, BITS=8)
#use RS232(BAUD=1200, STREAM=SDI12IN, rcv=PIN_D3 PARITY=N, BITS=8)
|
Then fputc to SDI12OUT, and fgetc on SDI12IN. Remember also if something it going to arrive on the wire you potentially need to use the option so the line floats when not driven. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9216 Location: Greensville,Ontario
|
|
Posted: Sun Jan 15, 2017 6:50 am |
|
|
As I was curious about 'SDI-12', I downloaded the manual from the SDI-12 group. On page 6 it specifies the data format to be 7 bits with even parity so you should edit your RS232 options accordingly. yes 7+1 = 8 bits but it's NOT the same.
I don't know if the sensors check for parity (they should as 'they' specified it), but in the old days we did! In fact UARTs, should 'flag' or report if parity is in error.
Just something to consider.....
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19480
|
|
Posted: Sun Jan 15, 2017 9:17 am |
|
|
Depending on the age of the compiler, they sometimes don't generate parity correctly so on these you have to use 8bit mode and generate the parity yourself. Possibly he has a version where this is the case?. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19480
|
|
Posted: Sun Jan 15, 2017 3:25 pm |
|
|
What was being tried, can work potentially. He will need to use the 'INVERT' option on both the setup lines, and use the 'setup_UART' command to turn the transmit on/off. The hardware would be needed for a hardware UART, to provide the inversion. Honestly easier to use the hardware, but it ought to be possible.
Edited.
As a further comment, he needs to check that the pin he is using has TTL buffers, not Schmitt buffers, since the bus only guarantees 3.5v for Vh. |
|
|
littlewhitedot
Joined: 27 Nov 2016 Posts: 5
|
|
Posted: Tue Jan 17, 2017 7:51 pm |
|
|
Hi all, I am currently testing on the GPIO. My code is:
Code: |
#use RS232(BAUD=1200, STREAM=SDI12OUT, xmit=PIN_D4, PARITY=N, BITS=8)
#use RS232(BAUD=1200, STREAM=SDI12IN, rcv=PIN_D4, PARITY=N, BITS=8)
char testbuf;
void test_uart(){
while(1){
testbuf=fgetc(SDI12IN); //get char from PC
fprintf(SDI12OUT,"%c\r\n",testbuf); //output back to PC
}
}
|
I was trying to get some char from Hercules by typing in manually and observe the output, but the code doesn't seem to take in any of my input. I have tried with fprintf and it works, just not the case with fgetc. Can anyone help please? |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9216 Location: Greensville,Ontario
|
|
Posted: Tue Jan 17, 2017 8:14 pm |
|
|
Please reread my first reply....
8 bits, no parity is NOT the same as 7 bits, even parity !
Assuming 'Hercules' is the sensor, it's SMART and KNOWS you're not communicating properly, so it aborts your requests.
Now that _may_ not be your problem, but to confirm/deny/eliminate it , you really need to change to 7 data, Even parity and rerun your tests.
Now the Hercules datasheet _should_ tell you about error conditions and timing requirements. Unreleated to your devices but I use the HC-12 wireless modems. They do NOT respond to manual typing of AT commands! Somehow then NEED the AT commands to be sent as a 'script',ie: sent by the PIC. I'm presuming the HC-12 sets a timer to decide if the entire AT command was not sent in under xx ms, then that command is invalid. Quite clever and totally UNDOCUMENTED ! Neat but was a pain for 'low level' testing !
If the MFR doesn't have good datasheet/info, try google ! It's amazing what's out 'there'.
Jay |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Jan 17, 2017 8:25 pm |
|
|
Quote: | I was trying to get some char from Hercules |
That's the first time you mentioned 'Hercules'. Post a link to the
website for this product or board. |
|
|
littlewhitedot
Joined: 27 Nov 2016 Posts: 5
|
|
Posted: Tue Jan 17, 2017 9:00 pm |
|
|
I am sorry, Hercules is a serial port software to read input and output from a COM PORT of a PC. Link at http://www.hw-group.com/products/hercules/index_en.html
I just realised that the TX pin is not plugged in which is why it is not responding. Still trying to edit the code. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19480
|
|
Posted: Wed Jan 18, 2017 2:11 am |
|
|
Also note my comment about INVERT. The SDI-12 spec if this is what is being used has the line idling low. To talk to SDI-12, you would need to use:
Code: |
#use RS232(BAUD=1200, STREAM=SDI12OUT, xmit=PIN_D4, PARITY=E, BITS=7, INVERT, NOINIT)
//setup to not drive the TX line
#use RS232(BAUD=1200, STREAM=SDI12IN, rcv=PIN_D4, PARITY=E, BITS=7, INVERT)
char testbuf;
void test_uart()
{
while(1)
{
testbuf=fgetc(SDI12IN); //get char from PC
setup_uart(1200,SDI2OUT); //enable the transmit - drive the line
fprintf(SDI12OUT,"%c\r\n",testbuf); //output back to PC
setup_uart(FALSE,SDI2OUT); //disable the transmit
output_float(PIN_D4); //ensure line is now floating
}
}
|
This then enables the transmit side only when you want to send, and ensures the line is released when not transmitting. You also need the resistor/capacitor circuit shown in the SDI-12 spec, to ensure the line is pulled down when released. |
|
|
|
|
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
|