Serial port problems using Visual Basic

[123bally]

Appreciate the forum is not for VB.net support but someone may be able to throw some light on this issue.

I have a PIC18f4431 programmed using ccs to receive a series of parameters over rs232. It looks for a character or string sent from the PC and returns a character to indicate acceptance.
The command sequence coming in is something like this:

's' arrives - "E" sent out
'1' arrives - "T" Sent out
'1500' arrives - "L" Sent out
'1000' arrives - "A" sent out
'100' arrives - "C" sent out

I have tested this with Hyper terminal to drive it on Win xp and it works 100%

When I run it on xp with VB.net application my application will hang on a readline instruction. Here's the strange thing, the same VB.net app works fine when run on my win7 machine at work???

At this point I should point out the VB.net app is incredibly simple - press a button and send a character - then use readline to wait for a string response terminated with a new line. I have been on it for days now and I just can't see why this won't work.

Am I missing anything about the way hyperterminal and CCS or the PIC are operating??

Any help gladly appreciated.....

[asmboy]

got HW flow control turned on in either ? ( and don't know it)

or are you using USB mediated RS-232 _ in which case see above PLUS
win API differences between the two OS's of windows.....

i have not seen any PC with an OS newer then about WIN-ME that actually had a true - backplane connected RS-232 capability .


in my practice - its all become USB mediated "virtualized" RS-232 via the
WIN API && not serial hardware.

and the opportunity for failure has manifested in so many more ways since that change.

[Ttelmah]

As standard, the terminal applications always open the port, and then set DTR, even if hardware flow control is not enabled, to show that they have connected. This in fact is used extensively in the USB libraries as well, often triggering the device initialisation.

I'd suspect, like asmboy, that the w7 machine has hardware flow control enabled, so is automatically doing this when the port is opened.

Best Wishes

[123bally]

Thanks for the replies guys....

What you are saying makes sense, and having tested it on another win7 machine I found it doesn't work on that one. The VB app has hardware flow turned off, but god knows what the usb - serial adapters are doing in addition behind the scenes. So given 3 in 4 PC's have not worked I am going to find an alternative approach. I simply don't have the time (or energy!) to figure this out.

I have now implemented a VB application that sends the data out without bothering to look for a response. Then having sent data I put the application into a serial monitoring mode. By using a small delay on the micro this monitoring mode then captures a message confirming the parameters that have been set.

Its crude but it works allowing me to get on to other important hardware features.

Thanks for your responses,

Bally

[mdemuth]

There might also be some junk left in the receive buffer.
I always put "serialPort1.DiscardInBuffer();" before writing the command.
Then wait a little and look whats in the receive buffer.

[Ttelmah]

Make your VB program set DTR.

In the serial port parameters, set the variable 'DtrEnable' to 'True'. You'll find it'll then start working.

Best Wishes

[123bally]

Hello all

Thanks for continued support. I got pretty excited about the DTR enable parameter but unfortunately it didn't help. So I have written a couple of bits of software to try to break the problem down. Here's what I have found:

The issue is with data coming from the PC to the PIC - I wrote some software that echos the string sent back from the PIC. What I saw was data would occasionally miss. For example sent 1000 (+CR) sometimes got back 100 or 1000 or nothing (clearly had missed the CR).

When I sent strings from the PIC to the PC I got reliable data (I should point out the VB code is simply responding to a byte so was not looking for end of line / CR)

I then tested just sending out single characters and got reliable results. Considering Hyperterminal for a moment I believe this is how HT works - sends a key press instantly - so its more akin to sending single characters compared to the string I send from VB. - This for me explains the difference in why HT works and VB doesn't.

So I did something a bit unorthodox and got an interesting result, I changed the baud rate in the RS232 fuse to 9550 - thinking that maybe its a timing issue over a sequence of several bytes (as it seemed to be 3rd,4th or 5th string characters that missed). I now have much more stable results - in fact it hasn't gone wrong at all (yet!) I then changed it to 9650 and it fails completely.

I tested this on a 2nd PCB and again the value of 9550 produces stable results. I also tested it on2 xp machines and 1 win 7 - all fine. I have never had issues with hardware like this before but then again I have never fed serial data from anything other than HT (byte at a time)

I am using a 20Mhz crystal (HC49/S) + 22pf caps.

It's great I have a much more stable system but I need to understand why and more importantly the best way to deal with this issue.

I appreciate your comments....

Bally

[mdemuth]

Are you using the HW UART? How does the receive routine looks like?

[123bally]

HI

Yes Hardware UART being used (Pins C6 and C7). I am using a MAX 3232 chip to interface.

Receive routines are based around calling GetC and GetS functions:

[Ttelmah]

The key potential problem is how long things may take.
Now you haven't said your CPU clock rate, or what you do with the long value once it is received, but (for instance), if your chip is running at 8MHz, and the 'long' value is perhaps several thousand in size, 'atol', can easily take several hundred uSec to process the string. If you take any significant time after this (printing results for example, or sending data to another interface like I2C), you can easily run out of time, and then characters will be lost....
This is why you really should consider using interrupt driven serial (ex_sisr.c), rather than gets.

Best Wishes

[gpsmikey]

You indicate that you are using a 20 mhz crystal - that does not divide evenly to give the 9600 baud you are looking for. There are a number of crystals in that range that do divide down correctly, you might want to give one of them a shot and see if that works the problem for you - typically at higher baud rates, things are less tolerant of slight variations in timing (hey, I remember when 110 baud was fast !! ). Here is a list of some of the common crystals that may give you a starting point ...
http://en.wikipedia.org/wiki/Crystal_oscillator_frequencies

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[123bally]

Hi Ttelmah

Yes CPU is running at 20MHZ, I appreciate your comments, however the time taken to process the ATOL is not an issue in this particular application as the PC is waiting to hear from the PIC before it sends anything else. For example the PC sends string "1000", and waits for char "L" to be received before sending any more data. Thus the PIC has as long as it needs to complete the ATOL and store the value for later use.

gpsmikey great link, thanks - have that bookmarked now. I guess I assumed the compiler would give an error for BAUD and OscFreq mismatches, but I guess its tolerated within a few %. As RS-2323 has always worked for me at 20MHz I guess I never questioned it in detail. I really like your line of thought here and I definitely have nothing to lose by trying it.


Thanks Guys...

[gpsmikey]

Also make sure both sides are using the same number of stop bits - that can result in strange things that work one character at a time, but not with a string of characters (how do you think I learned that? )

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[Ttelmah]

I still don't 'like' not buffering the serial. Though 'waiting' appears to solve the potential problem, it doesn't, if unexpected data gets sent (line feed and carriage return for example). It is just bad practice. Make the serial 100% reliable, receiving characters, sending handshake if buffering gets full etc., _first_.

Then, yes the compiler will complain if the baud rate is badly out of spec, but remember that the serial port on a PC, is not perfect. It is quite common to find that this is a couple of percent 'out of spec', and the PIC is also perhaps a couple of percent off. Neither is a problem "on it's own", but if the timings happen to be in the opposite direction, suddenly the error is large enough to be a problem....

Best Wishes

[123bally]

Update:

Thanks to GpsMikey: I changed out the xt for a 19.2MHz and the problem is solved. Tested on 3 PCB's and 3 PC's all good!!! I think I owe you a beer!

Ttelmah, I appreciate your sugestions and certainly agree that the code would benefit from some better practices. With that in mind I have scheduled some time later in the project to revisit the way I get serial data with a view to implementing a buffering technique.

Guys you have been great....

Thanks again

Bally