No joy with serin2

[Eriswerks]

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.

[mackrackit]

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

[Archangel]

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.

[mister_e]

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

[mackrackit]

7e1 = 24660

[Eriswerks]

If I comment out the SERIN2 command, it loops through "comm" repeatedly. I get "0 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.

[mister_e]

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

[Eriswerks]

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?