View previous topic :: View next topic |
Author |
Message |
harith
Joined: 23 Jun 2014 Posts: 8 Location: Srilanka
|
code working in Proteus but not in PIC |
Posted: Fri Jul 04, 2014 11:30 am |
|
|
I'm doing a mini project to control some AC loads by a RF remote.
I'm using 315MHz transmitter and receiver.
PIC16F876A and PIC16F877A used in two circuits....for connect two PICs i placed a wire to sending pin and receiving pin when i test in Proteus.
I wrote two codes using PICC compiler.
When i add those codes to PICs in Proteus its working well. In practical it is not working...please help me...i don't know why it is....
Code: | /*
Receiver
PIC16F877A
*/
#include <16F877A.h>
#device ADC=16
#FUSES NOWDT //No Watch Dog Timer
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#use delay(crystal=20000000)
#define RXData PIN_B7
//+++++++++++++++++++++++++++++++++
#define Load1 PIN_C0
#define Load2 PIN_C1
#define Load3 PIN_C2
#define Load4 PIN_C3
//+++++++++++++++++++++++++++++++++
#define Load5 PIN_C4
#define Load6 PIN_C5
#define Load7 PIN_C6
#define Load8 PIN_C7
//+++++++++++++++++++++++++++++++++
int a,b,c,d,e,f,g,h=0;
int anu=5;
//++++++++++++++++++++++++++++++++
#INT_RB
void RB_isr(void)
{
if(input(RXData)) //-RB7 da balanawaa
{
delay_ms(2);
if(input(RXData)) //-1 //1
{
delay_ms(4);
if(!input(RXData)) //0
{
delay_ms(4);
if(input(RXData)) //1
{
delay_ms(4);
if(input(RXData)) //1
{
delay_ms(4);
if(!input(RXData)) //0
{
delay_ms(4);
if(input(RXData)) //1
{
delay_ms(4);
if(input(RXData)) //1
{
delay_ms(4);
if(input(RXData)) //1
{
delay_ms(4);
if(!input(RXData)) //0
{
delay_ms(4);
if(!input(RXData)) //0
{
delay_ms(4);
//--------------------------------------------------------------------------------------------------------------------------------
if(input(RXData)){
output_toggle(Load1);
}
delay_ms(4);
if(input(RXData)){
output_toggle(Load2);
}
delay_ms(4);
if(input(RXData)){
output_toggle(Load3);
}
delay_ms(4);
if(input(RXData)){
output_toggle(Load4);
}
//------------------------------------------------------------------------------------------------------------------------------------------------------------------
} } } } } } }
}
}
}
}
delay_ms(10);
}
void main()
{
enable_interrupts(INT_RB);
enable_interrupts(GLOBAL);
output_LOW(Load1);
output_LOW(Load2);
output_LOW(Load3);
output_LOW(Load4);
while(TRUE)
{
}
}
|
Code: |
/
/*
K.G.Harith Anuradha
0715593555
RF Transmeeter
PIC16F876A
--- ---.--- ---.---.--- a...b...c...d..............4ms
---------------interrupt-- --- --- ---.---+databits-------------------
*/
#include <16F876A.h>
#device ADC=16
#FUSES NOWDT //No Watch Dog Timer
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#use delay(crystal=8000000)
#define TXData PIN_C4
#define SW1 PIN_B7
#define SW2 PIN_B6
#define SW3 PIN_B5
#define SW4 PIN_B4
#define Load1 PIN_C0
#define Load2 PIN_C1
#define Load3 PIN_C2
#define Load4 PIN_C3
int8 a,b,c,d=0;
int anu=5;
#INT_RB
void RB_isr(void)
{
delay_ms(20);
//*************************************************************************************************************************
if(input(SW1)){
//---------------------------------------------
output_high(TXData);
delay_ms(4);
output_low(TXData);
delay_ms(4);
output_high(TXData);
delay_ms(8);
output_low(TXData);
delay_ms(4);
output_high(TXData);
delay_ms(12);
output_low(TXData);
delay_ms(8);
//-------------------------------------------------------------
output_high(TXData); // a=1
delay_ms(4);
output_low(TXData);
output_toggle(Load1);
delay_ms(10);
//-------------------------------------------------------------
}
else if(input(SW2))
{
//-------------------------------------------------------------
output_high(TXData);
delay_ms(4);
output_low(TXData);
delay_ms(4);
output_high(TXData);
delay_ms(8);
output_low(TXData);
delay_ms(4);
output_high(TXData);
delay_ms(12);
output_low(TXData);
delay_ms(8);
//-------------------------------------------------------------
delay_ms(4);
output_high(TXData); // b=1
delay_ms(4);
output_low(TXData);
output_toggle(Load2);
delay_ms(10);
}
else if(input(SW3))
{
//-------------------------------------------------------------
output_high(TXData);
delay_ms(4);
output_low(TXData);
delay_ms(4);
output_high(TXData);
delay_ms(8);
output_low(TXData);
delay_ms(4);
output_high(TXData);
delay_ms(12);
output_low(TXData);
delay_ms(8);
//-------------------------------------------------------------
delay_ms(8);
output_high(TXData); // c=1
delay_ms(4);
output_low(TXData);
output_toggle(Load3);
delay_ms(10);
}
else if(input(SW4))
{
//-------------------------------------------------------------
output_high(TXData);
delay_ms(4);
output_low(TXData);
delay_ms(4);
output_high(TXData);
delay_ms(8);
output_low(TXData);
delay_ms(4);
output_high(TXData);
delay_ms(12);
output_low(TXData);
delay_ms(8);
//-------------------------------------------------------------
delay_ms(12);
output_high(TXData); // d=1
delay_ms(4);
output_low(TXData);
output_toggle(Load4);
delay_ms(10);
}
//***********************************************************************************************************************
}
void main()
{
enable_interrupts(INT_RB);
enable_interrupts(GLOBAL);
output_LOW(Load1);
output_LOW(Load2);
output_LOW(Load3);
output_LOW(Load4);
while(TRUE)
{
}
} |
please help me... |
|
|
dyeatman
Joined: 06 Sep 2003 Posts: 1934 Location: Norman, OK
|
|
Posted: Fri Jul 04, 2014 11:46 am |
|
|
Quote: | When i add those codes to PICs in Proteus its working well. In practical it is not working...please help me...i don't know why it is....
|
The main reason is because Proteus does not emulate fully and is full of bugs.
Which is why we don't work with Proteus problems here.
What I see initially is no HS oscillator fuses in the setup so the chip is likely
not even running. Proteus allows this, the REAL world will not.
You really need to plan for an LED to flash to prove the chip is running. _________________ Google and Forum Search are some of your best tools!!!! |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19538
|
|
Posted: Fri Jul 04, 2014 1:47 pm |
|
|
There are several other problems.
The code itself had me retching gently in the corner.
Basic approach is flawed. The interrupt is not really being used at all. There is nothing to handle the setup conditions at the start (reading the port before starting). I'd guess the hardware does not ensure that the receiver has started and is holding the line stable before starting. The whole thing would be better handled with a state machine in a timer, with states designed to handle when things go wrong. As written if a level is missed because of a tiny error in the hardware, the code won't recover.
The code is just a async receiver, based on 250bps transmission. As such could be better handled using the software UART.
Then there is the assumption that data will transmit as it is sent. Unlikely for most simple TX/RX combinations. Data loss is likely, but worse, most require some synchronisation before the first legitimate bits. Proteus does not have such problems. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Fri Jul 04, 2014 2:01 pm |
|
|
other 'concerns' aka PROBLEMS...
ISRs MUST be short with NO delays of any kind ! Just set a flag or two then exit ASAP!
Get rid of the 'RF modules' and connect the PICs with wire and get your code to function. 'RF modules' are KNOWN to NOT be 'user friendly' and have their own 'quirks' so the 'divide and conquer' approach to debugging is required.
As others have said Proteus is well known to NOT be 'functional' in any 'real world' sense. It never has nor will ever be a true simulation of the real world. Heck, you don't even need power or a clock source on a PIC and Proteus says it's OK !!!
hth
jay |
|
|
harith
Joined: 23 Jun 2014 Posts: 8 Location: Srilanka
|
how can i do it |
Posted: Sat Jul 05, 2014 3:13 am |
|
|
thanks for all replies...
so how can i do it...
when interrupt occur it seems like its not coming back to main function.
what can i do for that...
MR.dyeatman,
again i used #fuses HS but not working...
and i put an led to check weather pic is running... its working..
some times when i press buttons it transmit the signal and it turn on the led....
MR.Ttelmah, i cant understand wht u say..please help me to understand..
what it mean by "The interrupt is not really being used at all,reading the port before starting"
MR.temtronic,
but i didnt know that..in interrupts we cant use delays like i used...
then how can i read it...
please help me...
in here i connected 4 push buttons and 4 LEDs{as indicators to know that what lines are on} for the transmeter{PIC16F877A}
and in receiver{PIC16F876A} i used 4 LEDs as loads...
what i send using RF transmitter is is received by RF receiver..{so i can think like it is connected with a wire }
so how can i write a code for it...please any one.. help me... |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19538
|
|
Posted: Sat Jul 05, 2014 9:21 am |
|
|
Post a part number for the RF modules. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Sat Jul 05, 2014 11:01 am |
|
|
1) CCS supplies a nice 'code snippet' in the FAQ section
(I think) on how to read PORTB4..7. EASY to understand when you see it.
2)Get your xmit-rcv programs running BEFORE connecting the 'RF modules'. The modules 'should' be transparent to your code (ie look like wire) BUT if you don't configure them right, either in hardware of software it'll NEVER work and you will NOT know where to start to debug the project.
Keep it simple...wire your transmitter PIC to your receiver PIC and get them working 100% THEN add the RF modules.
3) If you don't do #2 you can waste hours, days, weeks of your life going around in circles.
hth
jay |
|
|
harith
Joined: 23 Jun 2014 Posts: 8 Location: Srilanka
|
parts |
Posted: Sat Jul 05, 2014 7:18 pm |
|
|
MR.temtronic,
yeah i have wired my transmitter PIC to receiver PIC thats how i check the code... i thought to connect rf modules after that...but i can't workout the code...
MR.Ttelmah,
I'll try that code snippet and tell you....
I'm using transmitter XY-FST , receiver XD-RF-5v 315MHz... I think it will not affect to the code weather what modules using.. because i tried it with a single wire to test... |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19538
|
|
Posted: Sun Jul 06, 2014 12:54 am |
|
|
No, the modules matter massively.
Some have their own error checking, and 'warrant' that the output will be off when they are not receiving data. Others are much more basic. This affects enormously how your code needs to behave.
Your approach makes what you want to do harder than it should be....
Much easier to use one of the FM RS232 modules, which then means you can send a message, as opposed to trying to use a pulse train as you are.
Big problem with these is they are AM modules. As such you _will_ get random pulses from the modules, when things happen nearby (dimmers switch, motors start etc.. I had a 'nasty feeling' this was likely to be the case, since these are the cheapest type of modules around. They do _not_ simulate a 'wire' at all closely...
However the modules support of to 10Kbps, so forget your current approach entirely. Use #use RS232, and send a byte stream.
Do something like AA, 55, STX, SWITCHES
As a four byte stream.
Suggest 4800bps (as nicely inside the supported rate).
Have the receiver ignore anything till it sees 'STX', then take the next byte as the pattern required. ideally add a checksum as well, but depending on your accuracy required, the byte itself may be acceptable.
Very much simpler than trying to fiddle around with timings. |
|
|
harith
Joined: 23 Jun 2014 Posts: 8 Location: Srilanka
|
thank you all |
Posted: Thu Jul 24, 2014 5:53 pm |
|
|
thank you all ppl helped me... i made it..now it works fine... |
|
|
|