CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

PIC16F877A interfaces with Visual Basic2008/Computer

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
sfchew7



Joined: 02 Nov 2011
Posts: 8

View user's profile Send private message

PIC16F877A interfaces with Visual Basic2008/Computer
PostPosted: Wed Nov 02, 2011 3:14 am     Reply with quote

I am using PIC 16F877A and I want to interface with pc.
How should I write the code?
Is it like this?
And the coding is correct?
What I want is when the computer sends me "1"
Then I will turn on the 3 leds.
Thanks
Code:
 #include "16f877A.h"
    #fuses HS,NoPROTECT,NoWDT,put,brownout
    #use delay(clock=4000000)
    #use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7,ERRORS)
    char chr;

    void main()
    {
      a=1;
       printf("\n\rThis is a demo");
       
       while(1)
       {
         // if(kbhit())  // check if there is a char ready to fetch
         // {             
             chr=getc(); // get one char from USART 
             putc(chr); // here we echo the chr we received           

             if (chr=='1')
         {
            output_high(pin_d5);
            output_high(pin_d6);
            output_high(pin_d7);
                        }



      //   }
      
       }
    }
temtronic



Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Nov 02, 2011 5:23 am     Reply with quote

Looks good so far..try it in the real world, see what happens.
Just be sure to put current limiting resistors in the LED pins !
As well, you'll need a MAX232 or MAX488 in the RS232 circuit for proper level conversion.
At least you've got 'errors' in the use rs232 declaration ! That'll keep the PIC from 'hanging up'.
sfchew7



Joined: 02 Nov 2011
Posts: 8

View user's profile Send private message

PostPosted: Wed Nov 02, 2011 9:30 am     Reply with quote

I have tried this code in real circuit and it cannot work.
I am using 4 capacitors, 1 max 232 ic, 1 pic16f877a.
When the PIC used "printf and putc" function, my computer can receive
the data. However, when I want to get data from my PC to my pic, it failed.
Ttelmah



Joined: 11 Mar 2010
Posts: 19552

View user's profile Send private message

PostPosted: Wed Nov 02, 2011 10:16 am     Reply with quote

Then look really carefully at the receive wiring. Start at the connector. Right pin on the DB9?. Is it making good contact?. Then work through. This needs to go to pin 8, or pin 13 of the MAX232. Then (if pin 8), pin 9 of the MAX232 needs to connect to pin C7 on the PIC, or if you use pin 13, then pin 12 of the MAX232 needs to go to pin C7 of the pin. Check every connection three times. Test with a meter. Does pin C7 on the PIC go high when everything is turned on?.

You need to look for whiskers shorting lines to something else, or a poor connection.

Now, though this isn't your problem, since the transmit side works, the MAX232, requires 1uF capacitors. It is the MAX232A that works with 0.1uF capacitors. However I suspect you have the 'A' part....

Also how is your program setup to send?. Depending on the exact version of VB you are using, and the settings, it may not actually send a character, until the CR code is sent, or the buffer is full.
Try with a simple terminal program, rather than VB. If it then starts working, this is the problem.

Best Wishes
sfchew7



Joined: 02 Nov 2011
Posts: 8

View user's profile Send private message

PostPosted: Thu Nov 03, 2011 6:48 am     Reply with quote

But the problem that I am facing is, I can run it perfectly in my simulation and my friend pc (win7). However, the data cannot be transmitted from pc to pic by using my pc (win XP). Have you ever seen this problem before?
What can I do to solve this problem ?
Thanks
temtronic



Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Nov 03, 2011 7:04 am     Reply with quote

Seems like you've narrowed it down to your PC.... IF the VB program is the exact same one on both PCs(you did copy it, NOT rewrite it ?)


Though very rare, you may have blown the RS232 interface chip of your PC.
I suggest making a very simple 'loopback' connector(pin 2 tied to pin 3) and run a terminal program(realterm , even Hyperterminal).Be sure to select 'no flow control' !. Any key pressed on the PC keyboard should then be displayed on the PC screen. Removing the loopback connector will stop the displaying of keypresses.If this fails,recheck the terminal options to be sure 'no handshaking' has been selected. If it truly fails this test, then the RS232 interface chip is blown.
If it passes then your VB program has a problem or some other application has 'hijacked' the comport transmitter side(how ? I don't know as I'm not in front of your PC.)
Douglas Kennedy



Joined: 07 Sep 2003
Posts: 755
Location: Florida

View user's profile Send private message AIM Address

PostPosted: Thu Nov 03, 2011 7:50 am     Reply with quote

The code you have is a simple receive a char and transmit the char received (echo). This works because it is one in one out. Now as things get more complicated more in than out or the reverse you will become aware that RS232 is asynchronous and that buffers are required. The PC has very large default buffers the PIC doesn't unless you program them. It is mostly a waste of time to proceed beyond the simple echo stage unless you start using interrupt driven circular buffers. CCS has a good example of programming a circular buffer. The receive is more critical since the PIC is a slave on receive. On the transmit the buffer is often less critical but a transmit without a buffer and an interrupt will be blocking.....ie nothing much else is going on in your pic as far as your code until the printf type statements are fully executed. The rs232 baud rate is very slow relative to the speed of the PIC.

Just in case
Are you using a usb rs232 interface and your friend (win7) isn't?
sfchew7



Joined: 02 Nov 2011
Posts: 8

View user's profile Send private message

PostPosted: Thu Nov 03, 2011 8:59 am     Reply with quote

temtronic wrote:
Seems like you've narrowed it down to your PC.... IF the VB program is the exact same one on both PCs(you did copy it, NOT rewrite it ?)


Though very rare, you may have blown the RS232 interface chip of your PC.
I suggest making a very simple 'loopback' connector(pin 2 tied to pin 3) and run a terminal program(realterm , even Hyperterminal).Be sure to select 'no flow control' !. Any key pressed on the PC keyboard should then be displayed on the PC screen. Removing the loopback connector will stop the displaying of keypresses.If this fails,recheck the terminal options to be sure 'no handshaking' has been selected. If it truly fails this test, then the RS232 interface chip is blown.
If it passes then your VB program has a problem or some other application has 'hijacked' the comport transmitter side(how ? I don't know as I'm not in front of your PC.)


yes the code is same on both pc, just my friend was using COMPORT10 just now and I was using COMPORT3 and COMPORT4 just now. PrintF and putc definitely no problem at all but the biggest problem is just the "getch".
I installed the LED on the transmitter pin so that whenver the data is transmit from PC TOpic then it will blink. When I used my pc , it didnt blink at all but it blinked when using my friend pc.
Now. I have asked my another friend who is using win7 to try the same code and same circuit also but he got the same problem with me.

There are 3 PCS
2 windows 7 and 1 windows XP
why only 1 windows 7 PC can work ? I have no idea.
thanks
sfchew7



Joined: 02 Nov 2011
Posts: 8

View user's profile Send private message

PostPosted: Thu Nov 03, 2011 9:03 am     Reply with quote

Douglas Kennedy wrote:
The code you have is a simple receive a char and transmit the char received (echo). This works because it is one in one out. Now as things get more complicated more in than out or the reverse you will become aware that RS232 is asynchronous and that buffers are required. The PC has very large default buffers the PIC doesn't unless you program them. It is mostly a waste of time to proceed beyond the simple echo stage unless you start using interrupt driven circular buffers. CCS has a good example of programming a circular buffer. The receive is more critical since the PIC is a slave on receive. On the transmit the buffer is often less critical but a transmit without a buffer and an interrupt will be blocking.....ie nothing much else is going on in your pic as far as your code until the printf type statements are fully executed. The rs232 baud rate is very slow relative to the speed of the PIC.

Just in case
Are you using a usb rs232 interface and your friend (win7) isn't?


Yes I am using a usb rs232 interface and my windows is windows XP whereas my friend is using Win7. I set the Baud rate to 300 but it does not work in my windows XP too. So I must use interrupt ? thanks
Douglas Kennedy



Joined: 07 Sep 2003
Posts: 755
Location: Florida

View user's profile Send private message AIM Address

PostPosted: Thu Nov 03, 2011 12:33 pm     Reply with quote

Well not all USB 232 devices meet the rs232 standard. Now suppose your device doesn't (when sending chars from the PC to your rs232 level shifter)
and doesn't drive the rs232 voltage to the the specs that your RS232 chip (eg Max232 requires). When the PIC sends it drives the TTL levels correctly so your level shifter( Max232) does its thing and the PC understands. When the PC sends the usb to rs232 interface falls short and your level shifter doesn't get the signal it needs to shift to 5v as well as invert and send the data to the PIC rx pin.

Now I have seen this happen with laptop rs232 ports versus desk tops.
There is a good probability that if your circuit worked with one PC then it is not your circuit. Next you have made sure the protocol ( Xon Xoff hardware hand shaking is off on all PC's). That makes the PC hardware a possibility.
If a usb virtual RS232 device is in the failing loops that may be the issue.
Next its out with the scope to see the 0 to 1 transitions.
The interrupt driven circular buffer is not in your error path yet but it soon will be if you send large chunks of chars....without buffering the PIC will probably start missing chars.
temtronic



Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Nov 03, 2011 12:57 pm     Reply with quote

Well another piece of the puzzle is shown, you're NOT using 'normal' or 'old school' comports! Old guys like me, assume a comport to be a real UART with a DB25 or DE9 connected to it NOT a USB<-> Serial 'dongle' and a ton of code to make it work,well sort of....
Be aware that not all USB<-> serial dongles will work on every PC. I have 3 here, only ONE works on my XP pro machine.Could be the hardware, could be the driver, bottom line I installed a real PCI RS232 card and IT works, 100%.
That being said, put a loopback test connector on the dongle and see if it'll echo.
Also your PIC program looks for an ASCII '1', be sure your PC program is transmitting that and NOT a decimal '1' which is ASCII for Start of Heading.
As a test, instead of echoing the PC character, add 1 to it and echo that back. PC sends an 'A', PIC sends back a 'B', just to confirm things are correct, and be sure to disable 'local echo' on the PC otherwise you may think things are correct but really aren't.
sfchew7



Joined: 02 Nov 2011
Posts: 8

View user's profile Send private message

PostPosted: Sun Nov 06, 2011 8:22 pm     Reply with quote

temtronic wrote:
Well another piece of the puzzle is shown, you're NOT using 'normal' or 'old school' comports! Old guys like me, assume a comport to be a real UART with a DB25 or DE9 connected to it NOT a USB<-> Serial 'dongle' and a ton of code to make it work,well sort of....
Be aware that not all USB<-> serial dongles will work on every PC. I have 3 here, only ONE works on my XP pro machine.Could be the hardware, could be the driver, bottom line I installed a real PCI RS232 card and IT works, 100%.
That being said, put a loopback test connector on the dongle and see if it'll echo.
Also your PIC program looks for an ASCII '1', be sure your PC program is transmitting that and NOT a decimal '1' which is ASCII for Start of Heading.
As a test, instead of echoing the PC character, add 1 to it and echo that back. PC sends an 'A', PIC sends back a 'B', just to confirm things are correct, and be sure to disable 'local echo' on the PC otherwise you may think things are correct but really aren't.

hmm. means I need to do a loop back test first? loop back testing is just short the pin2 and pin3 of the db9 ? thanks
sfchew7



Joined: 02 Nov 2011
Posts: 8

View user's profile Send private message

PostPosted: Sun Nov 06, 2011 8:25 pm     Reply with quote

Douglas Kennedy wrote:
Well not all USB 232 devices meet the rs232 standard. Now suppose your device doesn't (when sending chars from the PC to your rs232 level shifter)
and doesn't drive the rs232 voltage to the the specs that your RS232 chip (eg Max232 requires). When the PIC sends it drives the TTL levels correctly so your level shifter( Max232) does its thing and the PC understands. When the PC sends the usb to rs232 interface falls short and your level shifter doesn't get the signal it needs to shift to 5v as well as invert and send the data to the PIC rx pin.

Now I have seen this happen with laptop rs232 ports versus desk tops.
There is a good probability that if your circuit worked with one PC then it is not your circuit. Next you have made sure the protocol ( Xon Xoff hardware hand shaking is off on all PC's). That makes the PC hardware a possibility.
If a usb virtual RS232 device is in the failing loops that may be the issue.
Next its out with the scope to see the 0 to 1 transitions.
The interrupt driven circular buffer is not in your error path yet but it soon will be if you send large chunks of chars....without buffering the PIC will probably start missing chars.

you mean I need to install a virual rs232 device to try it ? thanks
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group