PIC16F877A interfaces with Visual Basic2008/Computer

[sfchew7]

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

[temtronic]

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]

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]

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]

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]

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]

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]

[sfchew7]

[Douglas Kennedy]

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]

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]

[sfchew7]