Serin woes - qualifiers not working

[tekart]

This is pretty basic - but it's driving me nutz.

I have a serin routine that is not responding to the qualifiers. The point of this circuit is to take the serial processing work off of another PIC, so I'm using an 12F509 to wait for a particular serial burst with 2 specific qualifiers. Then it sends a 2mS pulse to the host processor to let it know that valid data arrived. The serial is coming in via a MAX232 - so it's uninverted.

I wrote a test line that just waits for the serial data line to go low - and that works. The data line is clean and stays high between comms - see scope pic below.

The serial burst looks like this:
Tx:0F 03 00 00 00 05 84 E7

Guy

[mackrackit]

so it's uninverted.
Depends on what it is before it hits the 232.

Please post the code from both PICs using code tags.

[tekart]

The serial data is not coming from another PIC - it's from a PC serial port DB-9, which is one reason for the MAX232. So it's pretty standardized format.

[Bruce]

I would lower the baud rate, or use DEBUGGIN, or use an external crystal.

Also change RETURN to GOTO Main.

[ScaleRobotics]

This is pretty basic - but it's driving me nutz.

I have a serin routine that is not responding to the qualifiers. The point of this circuit is to take the serial processing work off of another PIC, so I'm using an 12F509 to wait for a particular serial burst with 2 specific qualifiers. Then it sends a 2mS pulse to the host processor to let it know that valid data arrived. The serial is coming in via a MAX232 - so it's uninverted.

I wrote a test line that just waits for the serial data line to go low - and that works. The data line is clean and stays high between comms - see scope pic below.

The serial burst looks like this:
Tx:0F 03 00 00 00 05 84 E7

Guy

Hey Guy,

I got it to work for me on my 12f683, but I had to change this line, so I could use characters that I can type on my keyboard:



SCADAin,2,200,NoOp,[<font color="#FF0000">&quot;15&quot;</font>,<font color="#FF0000">&quot;3&quot;</font>],X <font color="#000080"><i>' check f&quot;or right qualifiers only
</i></font>


Then when I enter 153x (x=any character or number) your code works, and X=x

[tekart]

Thanks for the effort I appreciate the time you spent . . . but I'm not receiving bytes as ASCII - they come in as numbers, and I can't change that.

Had a long chat with Charles at MElabs and he had me go over all the hardware and also try DEBUGIN. Still not recognizing the qualifiers.

See the screen shot from my LOGIC probe that shows that the serial data is arriving at pin6 (GP1) of the 12F508.

Also see my code with variants on several tests.

Anyone else go a take on this? I JUST need to respond to the qualifier and generate a pulse. I need a relativelty short timeout because other serial data is happening on this line at times. I just need to pick out one (or 2) qualifiers which are the first 2 bytes of the data transmission - they are $0F and $03 (15 and 3 decimal). Pretty darned simple in concept.

Guy

[mackrackit]

What is hitting the PIC?
15 or 0F
3 or 03



SERIN2 PORT.x,MODE,[WAIT("0F"),WAIT("03")]


Notice SERIN2... Never did like the single...

[ScaleRobotics]

Had a long chat with Charles at MElabs and he had me go over all the hardware and also try DEBUGIN. Still not recognizing the qualifier

Hello Guy,

Your code works for me, even with hex. (at least on my 12f683). But, I have to add this at the top of my code. Otherwise, I get no response.



CMCON0 = 7 'TURN COMPARITORS OFF
ANSEL = %00000000 'Set all pins to digital I/O
ADCON0 = %00000000 'Analog converter OFF


Here's what I used for my 12f683:


define OSC 8
OSCCON = %01110000 'set for 8mhz internal
CMCON0 = 7 'TURN COMPARITORS OFF
ANSEL = %00000000 'Set all pins to digital I/O *wont work without this *
ADCON0 = %00000000 'Analog converter OFF


'* uC : PIC12F508 *
'************************************************* ***************

' chip setup
' oscillator = INTRC
' watchdog = enabled
' MCLR = INPUT

X var byte ' dummy variable

' ************** DEBUGIN SETUP ************
define debugin_bit 1 ' incoming data bit
define debug_baud 9600 ' baud
define debugin_mode 0 ' 0 = true

' Pin Assignments
SCADAin var gpio.1 ' data in via MAX232
Ready var gpio.2 ' signal main processor to send data
'I changed from gpio.4 to match my hardware
low ready ' set low

' config
TRISIO = %000010 ' set I/O directions (0 = output, 1 = input)
'OPTION_REG = %01011111 ' 12F508/9 bit 6 disables weak pull-ups
OPTION_REG = %01000010 ' for my 12f683

Main:
' while scadain = 1 : wend ' test code detects presence of serial burst

' debugin 200,Noop,[wait(120)] ' wait for address and command
serin scadain,2,400,noop,[$0F] ' check for right qualifiers only

pause 10 ' wait for serial burst to end
high Ready ' signal main processor to send current data
pause 2 ' with a 2mS pulse
low ready

goto main

NoOp:
return

[tekart]

What is hitting the PIC?
15 or 0F
3 or 03



SERIN2 PORT.x,MODE,[WAIT("0F"),WAIT("03")]


Notice SERIN2... Never did like the single...


Doesn't matter hex or decimal - it's the same binary number sent via serial...
I had not noticed the WAIT feature in SERIN2. But the manual warns that at 9600 baud I *may* need an osc faster than 4MHz. Have not used SERIN2 before and it is giving me compiler ERRORS with the 12F509A.

[Bruce]

Does this work on your 12F509?


DEFINE DEBUG_BAUD 9600
DEFINE DEBUGIN_REG GPIO
DEFINE DEBUGIN_BIT 1
DEFINE DEBUGIN_MODE 0 '1=inverted

X var byte ' dummy variable

' Pin Assignments
SCADAin var gpio.1 ' data in via MAX232
Ready var gpio.4 ' signal main processor to send data

low ready ' set low

' config
TRISIO = %000010 ' set I/O directions (0 = output, 1 = input)
OPTION_REG = %11011111 ' 12F508/9 bit 6 disables weak pull-ups

Main:
debugin 200,NoOp,[wait($0F)] ' wait for address and command

pause 10 ' wait for serial burst to end
high Ready ' signal main processor to send current data
pause 2 ' with a 2mS pulse
low ready

goto main

NoOp:
GOTO Main

END

[tekart]

Bruce,
It WORKS! I had tried variations of DEBUGIN before but must have gotten the setup wrong! THANKS MILLIONS - you have no idea how much time I have put in on this (well, maybe you do...).

Still don't know why SERIN did not work.

Guy

[Bruce]

Hi Guy,

Glad I could help.

One problem was having RETURN in NoOp. The timeout/label option for serin/serin2/debugin use a GOTO to jump to NoOp. Not good since you have no idea what's on the call stack, and no idea just where it's going RETURN to when it lands on this return after only a few mS when it times-out.

Also .. serin/serout2 don't always work as expected at 4MHz for 9600 bps. debugin does.

If you refer back to my 1st post you'll see that I hinted about all of these potential show-stoppers...;o)