No joy with serin2

Hello folks... I am using a 16F690 to attempt to read the serial output of a sensor module. It's a sonar module from Maxbotix that is supposed to output an 8-bit distance in inches preceded by an ASCII "R" at 9600 baud inverted.

Below is my code. It just times out and jumps to "comm" every time. I've tried several different variations on the serin command with the same result.

----------
@ DEVICE INTRC_OSC_NOCLKOUT, MCLR_OFF,WDT_OFF,PROTECT_OFF
Include "modedefs.bas"
DEFINE OSC 8
ADCON1 = 7 '
ANSEL = %00000000


OSCCON = %01110000 ' 8MHz

distance var byte
distance = 0

TRISC.5 = 0 ' output
TRISC.4 = 1 ' input
TRISC.2 = 1 ' input

range:
'SERIN PORTC.2,N9600,["R"],distance
SERIN2 PORTC.2,16468,1000,comm,[wait ("R"), DEC distance]
pause 100


comm:
SEROUT PORTC.5,N2400,[#distance,10,13]
SEROUT PORTC.5,N2400,["ok",10,13]
goto range
----------

Is there something I'm missing in my configuration? All those configuration bits are definitely my weak point - I always end up with more questions than answers when I read about them in the datasheets.

Here's the FAQ for the module if you're interested: http://maxbotix.com/MaxSonar-EZ1__FAQ.html

It would be my guess the PIC is not getting a signal. Try connecting the sensor to a terminal program to verify it works as expected.

I don't see anything really obvious, you have properly disabled the ADCs, comparator are already disabled at POR, config fuse seems to be good.

Well, the led Blink is always welcome. This way you'll see if your device programmer program the config fuses.

Did you also tried with DEBUGIN?

What happen if you remove the timeout delay?

Any schematic of your current setup?

Also, from the datasheet

Quote:

---

TX, – When the *BW is open or held low, the TX output delivers
asynchronous serial with an RS232 format, except voltages are 0-
Vcc. The output is an ASCII capital “R”, followed by three ASCII
character digits representing the range in inches up to a maximum
of 255, followed by a carriage return (ASCII 13). The baud rate is
9600, 8 bits, no parity, with one stop bit. Although the voltage of 0-
Vcc is outside the RS232 standard, most RS232 devices have
sufficient margin to read 0-Vcc serial data. If standard voltage
level RS232 is desired, invert, and connect an RS232 converter
such as a MAX232

---

To me, it mean that it's output is not inverted... huh?

Thanks for the responses.

I just tried hooking the sensor up to Hyperterminal, 9600 8N1, and it seems to work fine. I get a steady stream of results in the format "R123." I tried 9600 true instead of inverted on the PIC just to see, but got the same absence of results.

I haven't tried using DEBUGIN before. Reading the description, it it seems like SERIN2 plus an ability to disable interrupts. What can DEBUGIN do for me? :)

When I tried running this without the timeout, it would hang at the point of the SERIN2 command, and I never got a peep out of SEROUT.

My circuit is a bit ugly at the moment, just something thrown together for testing purposes. I'm using the PICKit2 proto board with the sensor plugged into the headers via a breadboard and the serial connection to the PC wire-wrapped on the proto board. I'm attaching a photo of the setup. It output to Hyperterminal with the same breadboard connections.

Is there any way the carriage return the sensor sends at the end of each reading could be confusing SERIN2? Do I need to tell it to ignore/drop the last character somehow? The manufacturer's FAQ has code examples for a couple other BASIC languages, and I thought they were just ignoring the carriage return, but maybe not. Here's their BS2 code:

FOR xX = 1 TO 5
SERIN pMaxRecv\pMaxClock, 16468, [WAIT ("R"), DEC xDist]
DEBUG DEC5 xDist, " "
PAUSE 50
NEXT
DEBUG CR

The SERIN looks the same as mine, but I'm not sure what they are doing with the DEBUG command.

I did not notice in the first post that you are using the internal OSC. Sometimes it is not stable enough.

Try sending something to the terminal from the PIC with out the senor as a trigger.

press a button
send a serial string

Hello Eriswerks,
If I read this correctly SERIN2 PORTC.2,16468,1000,comm,[wait ("R"), DEC distance],
PortC.2 = DataPin, 16468 = Mode, 1000 = timeout, comm = parity label . . .
shouldn't it read . . . SERIN2 PORTC.2,16468,comm,1000,[wait ("R"), DEC distance] ?
I do not know if it makes the difference, the book specifies this order though, in fact if you want 8N1 input, loose the parity label altogether. "I THINK" it is trying to receive 7E1 with the label in place . . .from the book "If parity is selected, the data is received as 7E1(7 data bits, even parity and 1 stop bit)." thereby sending it to comm as a result of the error generated by the parity mismatch.

mmm... sure of it? mine says
SERIN2 DataPin{\FlowPin},Mode,{ParityLabel,} {Timeout,Label,}[Item...]

7e1 = 24660

If I comment out the SERIN2 command, it loops through "comm" repeatedly. I get "0 <crlf> ok" out of it in Hyperterminal, so it looks like the serial out is working fine. Do you think the internal oscillator is accurate enough for the 2400 baud serial out, but not up to snuff for the 9600 baud serial in? Maybe I should add a crystal to my proto board and see if it helps.

Use DEBUG/DEBUGIN, see if it works better.

I'm not a fan of the internal OSC for serial comm... yes some use it and have no problem with.. i know.... i know... ;)

Use 8MHz internal, then test it with 4MHz internal... maybe, maybe maybe. Last resort, fine tune the internal OSC with OSCTUNE register :eek:

Well, finally I've got this thing working. I got suspicious of Microchip's prototype board and just breadboarded the whole thing, and it worked perfectly.

I think I will go with an external ceramic oscillator for the final circuit, for the sake of reliability. If I hook up a 20mhz oscillator, all I need to do is set @ device EXTRC_OSC_NOCLKOUT, define OSC 20, and get rid of the OSCCON completely, right?

_HS_OSC

For the config with 20 mhz external.

Yes

DEFINE OSC 20

Thanks, I appreciate the help.