PIC HANGS with SERIN and Timeout? [Archive]

koossa

- 15th January 2008, 15:34

I'm struggling for hours now.
I use the following code and added an LED Blink for debug purposes,
but only gets one blink and then it hangs (on the serin2).
I have also tried serin.
Using Pic16F877 and have 2 PIR Sensors,
one on SENSORPIN1 and one on SENSORPIN2.

Any ideas?

<code>

   Include "Modedefs.bas"

   DEFINE   OSC 4 ' Set the Xtal frequency

   N2400   CON 16780
   P0   VAR PORTB.6
   P1   VAR PORTB.7
   SENSORNUMBER   CON 0
   SENSORPIN1   VAR PORTB.4
   SENSORPIN2   VAR PORTB.5
   LEDPIN   VAR PORTD.1
   SENSORSTATUS   VAR BYTE
   DATARECEIVED   var byte
   CCP1CON = 0
   ADCON1 = 7

Main:
   OUTPUT LEDPIN
   input SENSORPIN1
   input SENSORPIN2
Loop:
   IF (SENSORPIN1 = 1) OR (SENSORPIN2 = 1) THEN
      SENSORSTATUS = "1"
      HIGH LEDPIN
      PAUSE 1000
      LOW LEDPIN
      PAUSE 1000
   ENDIF

   OUTPUT P0
   INPUT P1
   LOW P0

   ' ============ LED BLINK FOR DEBUG PURPOSES =================
   HIGH LEDPIN
   PAUSE 100
   LOW LEDPIN
   PAUSE 100
   ' ================================================== =========

   SERIN2 P1, N2400, 10, Loop,[wait("T"),DATARECEIVED]

   ' ============ LED BLINK FOR DEBUG PURPOSES =================
   HIGH LEDPIN
   PAUSE 100
   LOW LEDPIN
   PAUSE 100
   ' ================================================== =========

   if (DATARECEIVED = SENSORNUMBER) then
      OUTPUT P1
      SEROUT2 P1, N2400, ["R",SENSORSTATUS]
      SENSORSTATUS = "0"
   endif

   ' ============ LED BLINK FOR DEBUG PURPOSES =================
   HIGH LEDPIN
   PAUSE 100
   LOW LEDPIN
   PAUSE 100
   ' ================================================== =========

   Goto Loop
end
</code>

Thank you!!
koossa

skimask

- 15th January 2008, 18:58

I'm struggling for hours now.
I use the following code and added an LED Blink for debug purposes,
but only gets one blink and then it hangs (on the serin2).
I have also tried serin.
Using Pic16F877 and have 2 PIR Sensors,
one on SENSORPIN1 and one on SENSORPIN2.
Any ideas?
koossa

I think this is going to tie back into that IDLE state thing, not sure off the top of my head.
Do a search on the IDLE. Seems to me, if the pin is IDLING in the wrong state, SERIN will hangout waiting for something that ain't comin...

In the meanwhile, try using a timeout in the SERIN command and see what happens.

koossa

- 15th January 2008, 19:04

Skimask, thank you very much for your feedback.

I have taken a look at the idling thing, but don't understand it.

I have also tried both SERIN and SERIN2 with timeout (10 milliseconds)

Koossa

skimask

- 15th January 2008, 19:08

I have taken a look at the idling thing, but don't understand it.
I have also tried both SERIN and SERIN2 with timeout (10 milliseconds)
Koossa

Well, I've never had the idling problem myself, so I can't really comment.
About all I can suggest is to read the threads again (there's one by Melanie that's especially long and useful) and you're answer will be in there somewhere.
If I would have to guess, I would say that your input pin is just sitting there at a low logic level. If it is, pull it high and see if the timeout works.
If it's sitting high, pull it low and see if the timeout works.

mackrackit

- 15th January 2008, 19:10

I do not use spaces in the SERIN2. Try:

SERIN2 P1,N2400,10,Loop,[wait("T"),DATARECEIVED]

And maybe use 16780 instead of N2400? And DEC before DATARECEIVED.

Maybe

skimask

- 15th January 2008, 19:13

I do not use spaces in the SERIN2. Try:

SERIN2 P1,N2400,10,Loop,[wait("T"),DATARECEIVED]

And maybe use 16780 instead of N2400? And DEC before DATARECEIVED.

Maybe

I haven't had a problem with spaces in PBP2.50, had problems back in 2.42 I think it was.
I've got a program that has about 50-60 different SERIN2 lines and they all look like:

SERIN2 serialinpin , 84 , 5000 , baddata , [ WAIT ( ">" ) , STR string\255 ]

Lots of spaces, etc.etc.etc...like I said, the older PBP, broke, newer, good.

mackrackit

- 15th January 2008, 19:17

COOL ,Now I need to upgrade. I am still at 2.47.

skimask

- 15th January 2008, 19:18

COOL ,Now I need to upgrade. I am still at 2.47.

I tell ya, in my little world, it's those LONG's that make all the difference.

koossa

- 15th January 2008, 19:22

Thank you for your replies!!
I Think this is it!!

http://www.picbasic.co.uk/forum/showthread.php?t=1944&highlight=idle

mackrackit

- 15th January 2008, 19:23

I tell ya, in my little world, it's those LONG's that make all the difference.
I just came out of a four hour meeting with one of those as Dilbert says Pointy Haired Bosses. So my brain is still a bit dead...

What are you talking about? "LONGs" ?

skimask

- 15th January 2008, 19:49

I just came out of a four hour meeting with one of those as Dilbert says Pointy Haired Bosses. So my brain is still a bit dead...
What are you talking about? "LONGs" ?

LONGs = double words, 32 bits (31 bits + sign) math, no more DIV32 (not included in PBPL because PBPL will do 32 bits)...
Check the melabs website for the upgrade info.

skimask

- 15th January 2008, 19:50

Thank you for your replies!!
I Think this is it!!
http://www.picbasic.co.uk/forum/showthread.php?t=1944&highlight=idle

That be the one...I'm fairly sure anyways...

mackrackit

- 15th January 2008, 19:59

LONGs = double words, 32 bits (31 bits + sign) math, no more DIV32 (not included in PBPL because PBPL will do 32 bits)...
Check the melabs website for the upgrade info.

That is something to get excited about. I really need to keep up with things.
Thanks again!

Ron Marcus

- 16th January 2008, 18:30

I haven't had a problem with spaces in PBP2.50, had problems back in 2.42 I think it was.
I've got a program that has about 50-60 different SERIN2 lines and they all look like:

SERIN2 serialinpin , 84 , 5000 , baddata , [ WAIT ( ">" ) , STR string\255 ]

Lots of spaces, etc.etc.etc...like I said, the older PBP, broke, newer, good.

This may be a moot point, but, I recently had the hang situation with a GPS unit interface. The unit's serial output would go to ground when the unit was put into sleep. I did a little loop that would sense if the line went high at all over a hundred mS period. If not,I would skip the Serin line. It works quite well without any hardware changes.
Ron

koossa

- 16th January 2008, 18:34

Thank you Ron, I will keep that in mind!

koossa

- 18th January 2008, 06:53

I'm a real beginner with PICS and don't understand the posts about idling that good.

If I connect he Serin Pin to ground it don't hang anymore, or if I rather use the "True" and not "inverted" state.
Is any one of these a reliable solution?

ardhuru

- 18th January 2008, 07:53

Sorry to jump in late. Just tie a 4.7 K between the serin pin and ground; should solve the problem.

Regards,

Anand

koossa

- 18th January 2008, 07:55

Thank you Anand, I will do!!

skimask

- 18th January 2008, 14:08

Sorry to jump in late. Just tie a 4.7 K between the serin pin and ground; should solve the problem.

Oh...hey...good point...no kidding.
Jeez, sometimes the simplest fixes are the best.
And if tying it to ground doesn't work (which it should), tie it high, or maybe use a 10K instead of a 4.7K, or maybe a 1K. Might take a bit of experimentation. But I don't see why 4.7K shouldn't work just fine.

Bruce

- 18th January 2008, 17:13

I would try to find or fix the problem VS using the external resistor. Especially if you're using the same pin for sending & receiving serial data.

If the other device is holding its pin at logic 1, and you do make it through to your SEROUT2 routine in the lower section, you have a potential short between two pins.

The idle state just means the serial input or output pins are held at the idle logic level during periods when no serial data is being transmitted or received.

For inverted, the TX output should idle at logic 0. And the RX input should be held at logic 0 by the sending device for the SERIN2 timeout/label options to work.

PBP times the idle logic on the RX pin for the duration of the timeout period. If it sees noise, or a steady non-idle logic signal on the RX pin, the timeout period gets reset, and it never exits to the label.

If you're using two PIC's talking together on a serial network type connection with the same pins on each side being used for TX & RX, then you might want to use one of the open baud modes.

If you use SEROUT2/SERIN2 then use mode # 49548, and use the pull-down resistor on the serial network TX/RX pins.

For inverted, open baud mode, the resistor holds the pin that's transmitting & receiving on the serial network at the idle logic level. Each PIC will TX a logic 1 only. Logic 0 for data bits and the idle state is handled by the pull-down resistor.

For true mode you would use a pull-up resistor on the serial network pins, and each PIC would output only logic 0 when transmitting serial data. Logic 1 gets handled by the pull-up resistor. Open baud modes are really handy for single pin serial networks.

skimask

- 18th January 2008, 17:33

I would try to find or fix the problem..........
Should sticky this in the FAQ's somewhere...
Like I said, haven't had the problem myself, but I'm sure that day is coming...