Help PLEASE - Stuck on a project! 16F877A

[Megahertz]

Hello, I am trying to make a system which should allow an operator to call for assistance from other departments. I have one code for my 16F877A for operator unit (RF Tx & Rx attached) & other code for another 877A for the department (RF Tx & Rx attached). There are 15 operators in total and 3 departments.
If I can make the system work for 1 department, other two should be less pain.
Working:
When operator presses the button for assistance, corresponding LED in the department unit should glow, sending a confirmation signal to operator unit, once this confirmation is received, led at operator unit should blink. When anyone leaves the department to attend the operator, he presses a corresponding button at the department unit, which sends another signal to the operator unit making the blinking LED at operator unit to get stable. Then when work is finished at the operator’s machine, the operator presses the second button which sends another signal to the Department’s unit switching OFF the LED there and waits for the confirmation signal to arrive before it switches OFF its own led as well.

Problem:
Upto the knowledge I have, I have made this and tested the system many times and it works up till the person leaves the department and led at operator unit gets stable. After that system behaves erratically. I have even tried to arrange the code in such a way so that operator unit keeps sending the signal automatically if it does not receive the confirmation signal in a certain time. But the system fails most of the time and cannot put the led off at the department unit, despite of repeated signals from the operator unit.
I attach the code for reference. Hope to find an answer soon.

[Megahertz]

Anyone please?

[Megahertz]

It seems that RX unit at MC Room hangs up when LED OFF siganl is transmitted, because when I interrupt the power supply of this unit and reconnect it, the LED gets off at MCH unit, which indicated to me that RX may hang up, and only receives signal from the MCH unit once reset takes place. Because the MCH unit is repeating the LED off signal all the time, the MC Room only captures it on reset.

Is it possible that using DT_INT could be the problem?

[Darrel Taylor]

Is it possible that using DT_INT could be the problem?

No, but using them the wrong way sure will.
Sitting in the interrupt handler sending serial data and pausing in a loop will stop anything else from happening in the main loop.

By the time you exit the handler, the timer has overflowed again, and it'll jump right back to the handler again for more loops pauses and DEBUG output.

Interrupts are meant to handle things immediately and fast.
Not to trigger a long series of statements that take longer than the period between interrupts.

Get in, do what you need to respond to the interrupt, then GET OUT.
Let the main loop handle any pauses and debugs.

99.9% of the time, there should never be a PAUSE in an interrupt handler.

And you should use the USART for serial data, not DEBUG/IN.

[Megahertz]

Thanks for the answer. I can see some light now at the end of the tunnel.
Few questions I have, please try to answer them:
1) My MCroom code sits at DEBUGIN statement at all times. And I have learnt that after the interrupt is handeled, program resumes from from the last statement which it was executing, which in my case is DEBUGIN. So how can I send

if z>0 THEN
     for x=1 to 30
       DEBUG "MT3",z,"C"
       Low Tx : Pause 10
     next x
     Low BUZ : z=0
 ......

this signal if I do not put it in interrupts.

2) I have used one calculator I found here in forum only to see what is the duration of interrupts. It comes to every 524mSec for TMR1 @ 16bit @ 1:8 prescaler. Based on that the MCRoom code only uses 300mSec for debug statement and that too only once. OK, I agree if I put pause statements in the ISR code, timer will runout again. but pause is only used once when the DEBUG is used in MCRoom code ISR, why it kind of hangs permanently after that?
Because MC1 code is repeating that signal continuesly after certain interval. I cannot understand why the MCroom is unable to catch the LED OFF code later

I hope I have explained my point, and apologies if confusion is still lingering. Please ask me for any clarification if needed.

P.S: I don't have any knowledge about USART, I am a product design student actually and try to learn programming because I find it very interesting. I will learn about USART soon and apply it to these codes. I hope I can make this code work using DEBUG for now.

[mackrackit]

P.S: I don't have any knowledge about USART, I am a product design student actually and try to learn programming because I find it very interesting. I will learn about USART soon and apply it to these codes. I hope I can make this code work using DEBUG for now.

Using the USART in PBP is not much different than using DEBUG or SERIN2, same syntax.
Look to the PBP manual under HSERIN for starters and at the bottom of this page is an example to play with.
http://www.melabs.com/resources/samples-pbp-general.htm
The hardest thing with the USART at the beginning is setting it up.
For that this is a handy tool
PicMultiCalc
http://www.picbasic.co.uk/forum/atta...achmentid=2957

[Megahertz]

Hi Mackrackit, thanks for the answer.
Can you please explain briefly what excatly is USART (HSERIN) and how is it different to SERIN, If I attach the TX pin to my RF receiver and use HSERIN, will it still work as normal, does data comes differently when HSEROUT/HSERIN is used.
I also want to ask that when using the debug statement, because of the noise at the RF receiver, even if there is a timeout, 99% of the time it does not work. When used with USART command, can this problem be sorted?

[mackrackit]

The main difference is SERIN2 is all software(bit banging) while USART is done in the on chip hardware.

SERIN2 has the advantage of being able to be used on just about any pin and can be setup for Inverted or True mode.

USART has the advantage of running in the background and can be used as an interrupt trigger.

Sometimes considered a disadvantage the USART is True mode only so depending on the application an inverter chip might be needed (MAX232 type).

Data with both types can be a standard 8N1.

To be honest I have not really looked at your code but I will guess some sort os simple checksum would solve the noise problem. I will take a look at it later.

Reliable RF can be used with bit banged serial, Bruce has a nice example in the Code Example section.

[mackrackit]

Possible pointers...

Finally had a chance to look at your code and I am wondering exactly what your are trying to accomplish with the interrupts and you are receiving a string into var P but I do not see where P is used.

A couple of things that might help you.

Like Darrel said about interrupts, get in and out as fast as you can.
That being said I think I would use the interrupt to receive data. This can be accomplished using DT's instants if you use the USART. I have only used DT's intants for this a time or tow and they worked great, thanks Darrel! There are examples on how to set it all up on his web site.

The only thing you would be doing inside the interrupt is receive data. The data will be processed else where. Using USART and interrupts you should not miss any data.

Now for the RF.
If you are using radio modules like the ones found at rentron.com then they need to be "trained" to receive data. This is done by sending a bunch of 0s and 1s. There is some controversy about this but sending $A5 first seems to work well. Also send a SYNK byte, this will take place of your MT3. You will wait for the SYNK.

TRAIN = $A5
SYNK = $7E
HSEROUT [TRAIN,SYNK,"your data will be here"]

In the receiver side, the interrupt will be triggered when the USART "hears" something. If the SYNK is not received then exit the interrupt. If SYNK is good save the data then exit the interrupt.

That might be enough to make it work but you may also want to add a simple checksum.

A quick and dirty way is to take the value you are sending, 41, and multiply by 3 before you send. That value would be saved into a VAR CH_SUM, = 123. Send 41 and CH_SUM.

When you receive save 41 to your code VAR and save CH_SUM also. Before you act on the data divide CH_SUM by 3 and check to see if it equals "code". If not you have had a bad transmission.

There are several ways to do this, the above is just one to give you some ideas.
Hope my babbling did not confuse the issue.

[/code]

[Megahertz]

Thanks Dave, I am very thankful to many members here, because I have learnt a lot from this forum and now the checksum method, which you have explained very simply.

I have taken the advises above and changed the code and freed the MCRoom's ISR.
During my earlier attempts, I tried to make the code work by sending an 1 string byte, but it didnt worked so I changed it, but left the receiving string variable as it is.

It is not working currently, but it seems I am near as ISR is not handling much complicated stuff like pause or DEBUG.
The code at machine now (MCH1.txt), keeps sending signals and waits for the answer from the MCroom.
The MCroom should switch the LED ON and buzzer ON when mch reports a problem. I have tried to put everything in a loop, but it is not working.
Is it ok to put things in loop like I have done?
I am attaching the codes I have amended.

[Megahertz]

I was looking into the PIC calculator. I would like to incorporate USART into the code as advised.
I have got few statements from the PIC calculator which are:

DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 20h ' Enable transmit, BRGH = 0
DEFINE HSER_SPBRG 12  ' 4800 Baud @ 4MHz, 0.17%
DEFINE HSER_CLROERR 1 ' Clear overflow automatically

and also

RCSTA = $90 ' Enable serial port & continuous receive
TXSTA = $20 ' Enable transmit, BRGH = 0
SPBRG = 12  ' 4800 Baud @ 4MHz, 0.17%

I would like to ask, if these are the only statements which I need to put in the code and then replace DEBUG with HSERIN & HSEROUT and also use my simple RF modules on TX & RX pins of my PIC instead of the ones I am using now?
I mean would these statements be correct?

HSEROUT "MT3",code,"S" & HSERIN [WAIT("MT3"),code,STR string\1\10]

Also Dave, to answer your question -

If you are using radio modules like the ones found at rentron.com then they need to be "trained" to receive data.

. I am using simple RF modules and not any special kind.

[mackrackit]

Is it ok to put things in loop like I have done?

The code in the ISR still looks a bit long. Maybe put that stuff in the START label being you are looping back to it. Have a GOSUB in there to TOGGLE FAST.
In the end I think the only thing you want in the ISR is the serial receive.


From the PicMultiCalc program the copy defines is what you want at the beginning of your code for this.

Your HESER statement is not quite right. Look at SERIN2/SEROUT2 for examples on the syntax, it is the same as HSERin/out. Basically you need [ ] at the beginning and end.

Now I am going to suggest that you leave your code for a bit and and work on some simple test codes to make sure you have everything working. I am sure you did that at the beginning of this project but several things are changing now, adding new "stuff" and restructuring the code.

RF is difficult at best so start with wires. Do the HSERIN in the ISR and just simply have it do one thing, light an LED. Then work on feed back from the receiver.

Which brings up another thing. If I am following this correctly the RF is two way. ZUnless you have a two way module you will want to kill the power to the transmitter when you are receiving. I do not see this in the code but maybe it is there.

[Megahertz]

The code in the ISR still looks a bit long. Maybe put that stuff in the START label being you are looping back to it. Have a GOSUB in there to TOGGLE FAST.
In the end I think the only thing you want in the ISR is the serial receive.

I didn't knew about this. I just want to confirm again, that I can put gosub kind of statements in the ISR, where it can point to labels outside the ISR?

Which brings up another thing. If I am following this correctly the RF is two way. ZUnless you have a two way module you will want to kill the power to the transmitter when you are receiving. I do not see this in the code but maybe it is there.

I have tried to give enough pause to the TX before transmitting, so that Rx can finish listening to the code.

One more question for now, any advise as to why this stament in the code (MCroom) is not working when code received is 1:

	for x=1 to 4
		if code=x then
			High PortC[x+3] : Y=1 : buzzer[x]=1: goto snd
		endif

Port C.4 should get high when code is 1, but it is not.

[mackrackit]

I didn't knew about this. I just want to confirm again, that I can put gosub kind of statements in the ISR, where it can point to labels outside the ISR?

That is not what I was trying to say.
Your code loops back to START: regularly, have a GOSUB in there that will take you to the routine that WAS in the ISR. Looks like that routine is for setting the LEDs and I bet your code will run fast enough that if the LEDs are set/changed through every loop it will be fine.

Some of the transmitters are transmitting a carrier wave all of the time when they are powered up. Could be "jamming" the receiver.


High PortC[x+3]
That is interesting... never tried that but I do not think it will work.
Maybe if the . is put in after C ???

[Megahertz]

Back to scratch now. Just trying to do it for one machine with new approach. MCH reports the problem, LED goes high at MCroom, along with the buzzer, Ackn... signal is sent and led blinks at MCH as well.
BUT only for few seconds and then it goes off. I also put a statement High BUzz: pause 100 : low buzz to see if valid signal comes, it does keeps comming at mcroom.
Looking at my new code will explain better what I am trying to do. Any advise?

[mackrackit]

Any advise?

Re-read post 4 and 9 ???

[Megahertz]

Re-read post 4 and 9 ???

Hi, I have arranged my hardware accordingly to use USART, trying to understand and blink an LED first.
My Rx code is :

DEFINE OSC 4
Include "modedefs.bas"
INCLUDE "DT_INTS-14.bas"     ; Base Interrupt System
INCLUDE "ReEnterPBP.bas"     ; Include if using PBP interrupts
 
@ __Config _XT_OSC & _WDT_ON & _PWRTE_ON & _BODEN_ON & _LVP_OFF & _CP_ALL & _CPD_ON
 
Pause 50
'-------variables declared-------------------------------------

code1 var byte
code2 var byte
a var bit
b var bit
c var bit
d var bit
e var bit
f var bit
g var bit
h var bit
a=0 : b=0 : c=0 : d=0 : e=0 : f=0 : g=0 : h=0
'-------------------------FUSES SET----------------------------
PAUSE 50
ADCON1=7
CMCON=7
CCP1CON=0
OPTION_REG=%10000000
TRISA=0 : PORTA=0
TRISE=0 : PORTE=0
TRISB=0 : PORTB=0
TRISC=%10000000 : PORTC=0
TRISD=0 : PORTD=0
@ ERRORLEVEL -306

;-----------HSERIN & OUT------------------
DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 20h ' Enable transmit, BRGH = 0
DEFINE HSER_SPBRG 12  ' 4800 Baud @ 0.17%
DEFINE HSER_CLROERR 1 ' Clear overflow automatically

RCSTA = $90 ' Enable serial port & continuous receive
TXSTA = $20 ' Enable transmit, BRGH = 0
SPBRG = 12  ' 4800 Baud @ 0.17%

'------INTERRUPT DECLARED--------------------------------------------------------------
ASM
INT_LIST  macro    ; IntSource,        Label,  Type, ResetFlag?
       INT_Handler    TMR1_INT,  _ToggleFast,   PBP,  yes
       INT_Handler    RX_INT,  _RX,   PBP,  yes	   
   endm
  INT_CREATE               ; Creates the interrupt processor
ENDASM
T1CON=%00110001
 
@   INT_ENABLE   TMR1_INT
@   INT_ENABLE   RX_INT

;------MAIN PROGRAM START-----------
start:
	HIGH PORTB.7
	PAUSE 50
	LOW PORTB.7
	PAUSE 100
Goto start


'---[INT - interrupt handler]---------------------------------
ToggleFast:
	Toggle PortB.6
@ INT_RETURN


RX:
		TOGGLE PortB.5
		HSERIN 100,close,[WAIT("MT3"),code1,code2]
	close:

@ INT_RETURN

'---------end--------------------

Nothing is comming from Tx currently because I wanted to see first if both interrupts are working fine.
This is what happens:
LEDs are connected to PortB.7,6 & 5. When power is applied, PortB.7 blinks, PortB.6 blinks but when PortB.5 blinks, normally PIC hangs for few seconds and then normal erratic behaviour happens because of the interrupts, then again PIC hangs for few seconds.
My TX module connected to PIN25 is also getting very hot, even though I am not using it in the above code. Is this overall behaviour normal, I am using this feature for the first time, am I doing it right?