Oscillator stops when touching with a wire

[falingtrea]

in the 485_receive part of your code you have a debugin without a wait value. I would put timeouts in all your serial communication calls just to be safe.

Another thing you can do is output some debug messages to the serial port showing where the program is. Once it locks up you can look at the last message and see where the code was when it died.

[Wilbert Ingels]

Hi Tim and Jerson,

I'm working in 2 modes: Live mode and initialization mode. In live mode, the processor will wait endless untill he receives "ST" with instructions from the bus master. In initialization mode, he will look at his inputs and also looks if broadcast information is received on his RS485 bus.

I've tried your suggestions but he's still going into a endless loop when a spike arrived on the bus. It looks like when one bit arrives, the timeout value doesn't count untill a full byte is arrived. He only succeed to release (via timeout) when information flows again on the RS485 bus (and bytes are being received).

It seems that timeout only works when full bytes arrives. If a single bit (spike) arrives on the RS485 network, the debugin timeout statement is not working ...

Does serin2 works different than Debugin (-> timeout bit versus byte)?

Any other suggestions?

Many thanks guys !!

Wilbert

[skimask]

Why not "SERIN" all of your characters into a 'sliding buffer string' and keep that in a tight loop. You can keep track of it and keep checking if the beginning of that 'sliding buffer string' contains the "ST" that you're looking for. When it does, you save the data and act on it accordingly.
That way, you should be able to avoid the timeout and glitch problems that you're having.
I thought I had a good idea for you...lost it...can't find it again

[Wilbert Ingels]

Hey Skimask,

Thanks for your reply !

I'm still struggling how to do it. If i use a tight loop with timeout which receives character by character, i'm afraid if only one bit is send (my famous glitch ), the timeout statement won't work and the endless loop will start (untill additional information is received)

I'm going to try it and will keep you in touch. If you remember you other suggestion, you're more than welcome

Take care

Wilbert

[Wilbert Ingels]

If i look in the manuel on page 135 (serin2) "if the serial input pin stays in the idle state during the timeout time, the program will exit the SERIN2 command and jump to label". In my case, the input pin doesn't stay idle because it received one glitch ...

Same for Debugin on page 58 ...

Hum, i don't see it yet how i can solve it

[mister_e]

Pull-up or pull-down resistor is an easy to test Solution?

[Ron Marcus]

It sounds like static electricity is the culprit here. I understand touching an input, but the ground should be somewhat immune to the phenomena. It sounds like there is a ground loop in the connections. Look for multiple lines connected to ground in the same run of cable. Touching one will cause an imbalance. So if the shield is connected to ground, and another line in the cable is, this could cause a problem. The simplest fix is to not connect the shield on one end of the cable. While it sounds counter intuitive, it might be the cause, or one of them.
Ron

[skimask]

If i look in the manuel on page 135 (serin2) "if the serial input pin stays in the idle state during the timeout time, the program will exit the SERIN2 command and jump to label". In my case, the input pin doesn't stay idle because it received one glitch ...

The fix might be something as simple as:

loop:
datagood = 0
SERIN2 (((your code here with the shortest timeout possible, timeoutlabel, etc.etc....)))
datagood = 1
goto overtimeoutlabel
timeoutlabel: if datagood = 0 then goto loop  'data was bad, try again
overtimeoutlabel: continue code here....

if it does glitch, you check 'datagood'. If datagood is 0, then it glitched or didn't receive what you wanted and try again

Aside from that, I agree with the other guys, ya gotta find the root cause of the glitches...

[Wilbert Ingels]

Hey Guys,

Thanks for the feedback !

Yesterday, i've changed the RS485 chips. I was using SN75176 and i've changed them for MAX481 and the glitched are gone. It seems that SN75176 is more sensible and thus in my case less usable in my application. The MAX481 untill now never gave one glitch. I'm working now on the timing aspects because these seems different between SN75176 and MAX481.

I've also went into more detail in how PBP works. I understand the little drawbacks (in terms of serial communication) of the language better now but i must say that, the longer i work with PBP, the more enthusiastic i am. It is a great language and a fantastic tool.

Take care

Wilbert