RS232 over USB, PL2303

[Mosaic]

Two questions:
1) If a PIC circuit has it's own 5V pwr then it is possible that there is a small voltage difference between the 5V supplied by the PL2303 usb connector and the built in PIC supply. Is it advisable to include a small resistance (2-10 ohms) in the 5V connection between the PIC supply and the incoming PL2303 5V line to limit current flows due to the voltage difference?

2) I am running 9600 baud using a 16F886 USART., uploading ascii data. I am getting 'lost' characters, perhaps 3% average loss.Quite random lost chars. I can resend from the PIC over and over and keep losing different chars. Should I drop the speed to 4800bps? Or can I implement some kind of protocol?

Thx
Ancel

 

[NorthGuy]

If PIC's ground is floating (e.g. a battery or an isolated PSU with a transformer), you can simply connect it to USB ground.

If PIC's supply is already grounded, you cannot connect them together, but you can isolate PIC from USB with some sort of isolator.

 

[ronsimpson]

Don't connect the two 5 volt supplies together.

There should not be a speed issue. You can try a slower speed.
Maybe your baud rate is off by some small amount. Are you using a XTAL or the internal oscillator?

 

[Mosaic]

Ok, so shall I leave off the 5V supply and just connect gnd & data pins?
Yeah the baud rate is off by 0.16% - internal oscillator.
Note table 12-5 in the datasheet - 2Mhz internal clock.
Could that be the prob?

 

[KeepItSimpleStupid]

There is the ^S/^Q protocol which is sometimes implemented as "resume any character" and the RTS/DTS protocol.

Lower, the baud rate first.

 

[Mosaic]

The PL2303 is just 4 pins to the PIC (3 pins without the 5V)....no RTS/DTS or am I missing something?

 

[large_ghostman]

Dont know if that chip has one, but could you use OSCTUNE to adjust the OSC a little to shave a bit off the error?

 

[Mosaic]

There is an osctune....will have to investigate whether the % change is worth it.

 

[KeepItSimpleStupid]

https://www.google.com/url?sa=t&rct...otqKDpoINF_mtpw&bvm=bv.61535280,d.dmQ&cad=rja

PDF page 11, there is an RTS and CTS signal available for use.

 

[large_ghostman]

sometimes even a fraction helps! and dosnt take any pins, but if you have other time sensitive bits in there, then it can all get a bit

 

[Mosaic]

osctune can do up to 12% correction. I am examining this app note
https://ww1.microchip.com/downloads/en/AppNotes/00244A.pdf

To develop a calibration method.

Running at 4800 bps is a bit more stable but still has probs, so I might be on the border of the RS232 tolerance.

 

[ronsimpson]

If you are off by 1% at 9600 then you will also be off by 1% at 4800 and 2400 and 1200 etc.

You could add 1 to you counter, or substrate 1 count and see what happens.

 

[large_ghostman]

Probably not going to help, but are you waiting for the OSC to become stable etc before flying off into the main main() code?
I have never tried to calibrate the internal OSC but I have used OSCTUNE to tweak it a bit when getting rs232 errors, now I have odd value crystals that give me 0% error on all kinds of frequency. But I still stick with the internal OSC for some reason or other.
I found the RS232 really frustrating, there are loads of post on here from me, crying about it not working!!! then one day bingo. It just started working and normally works first time now. only thing I do different is use a little program to work out the settings and give me the error factor.

 

[ronsimpson]

I can't find it now but there is a good explanation of how error in frequency causes trouble. I don't want to bring this up from memory. Can someone find a paper on error for baud rate frequency.
EDIT-------------
From a data sheet
"What is a small enough error? In general, a frequency error of 0.8% or less should be no cause for concern. However, a frequency error of 2.0% or higher should be looked at carefully. Errors between 0.8% and 2.0% involve some judgment."
Edit------------
From MicroChip Forum
"In this attached application note (UART CRYSTAL OSCILLATOR DESIGN GUIDE) please see section 9 -- Required Clock Accuracy (on page 10).

Luckily with PIC's, there are only two character lengths (which includes the start bit, data bits, parity bit if applicable, and the stop bit) to be concerned with: 10 bits or 11 bits.

If your UART setup is 8N1, the formula yields: +/- 5.26 % (character length is 10 bits)

If your UART setup is 8O1, 8E1, or 9N1 the formula yields: +/- 4.76 % (character length is 11 bits)

If UART "A" does not physically share the same baud rate clock as your UART "B" (which is often the case) you might want to consider dividing this maximum allowable deviation percentage by two to be ultra-conservative and safe (in case the UART "A" is at one extreme of the error range and UART "B" is at the other extreme of the error range). In other words, if your UARTs "A" and "B" are set up as 8N1 (total character length = 10 bits), and given the formula in the application note, select the clock such that the maximum baud rate deviation from ideal is: +/- ( 5.26 / 2 ) which is +/- 2.63 %.

Please also note that this (dividing the total error budget equally among UART "A" and UART "B") is being extremely safe and conservative -- especially if the other UART that the PIC is connected to is on a PC (personal computer). It has been my experience that most UARTs in PC's and on serial port add-in cards use a crystal or clock oscillator frequency such that the "standard" baud rates are "spot on" for all practical purposes (0 % error in theory). But in reality, these crystal or clock oscillator frequencies will obviously not have 0% error over temperature and operating voltage, but rather might be typically in the 50 PPM to 300 PPM range -- which is obviously far, far, less than +/- 2.63 %.

So what does this really mean? Well, if your UARTs are using 8N1 and one of the UARTs is in a PC, you most likely would not have to divide the maximum baud rate deviance in percentage (in this specific example +/- 5.26 %) by two. So instead of limiting the baud rate deviances of the PIC's UART to half of +/- 5.26 % and the PC's UART to half of +/- 5.26 %, you could limit the baud rate deviance of the PIC's UART to say, +/- 4.26 %, and the PC's UART to +/- 1.26 %. This shifting of the error budget more on the PIC side assumes that you have chosen a PIC Fosc that does not produce a "spot on" baud rate.

This is just a hypothetical example of spreading the error between the PIC and the PC, but ultimately it is up to you to make the calculations and the final decisions. I hope this all makes sense.

Best regards,

Ken Pergola

 

[Mosaic]

Well the PIC claims a 0.16% error once the Fosc is good. I haven't checked the Fosc yet. But with hardware USART combined with occasional errors (2-3%) at low baud => a borderline Fosc.
Still coding a bootup cal. for OSCTUNE that saves to EPROM . I expect to use a 20Khz ref frq. off a function gen. Using 8N1.

 

[Mosaic]

Well that was a fail...the cal code found the chip to be perfectly accurate.
Which leaves me stuck.
The PL2303 cable I have only supplies 4 wires , 5V, gnd and data tx/rx.

Can flow control be embedded in just those 4 lines from the PIC USART? I could use some advice on that.
Last time I fooled with rs232 was with a 25pin null modem cable in the last century - to play WARcraft 2 PC to PC!

 

[Mosaic]

Update:
The 16f886 OSC clkout is spot on # 500Khz....2Mhz Fosc. Not surprising the OSCTUNE firmware I built came up with zero adj.
Still unsure how to proceed with getting flow ctrl on the PL2303 USB serial cable.
Has anyone done RS232 flow control over these cables?

 

[NorthGuy]

Flow control shouldn't matter at 9600 baud. 40MIPs PIC is capable of uart communications at 2000000 baud, may be even faster. IMHO, the bad ground theory is what you should look at.

 

[NorthGuy]

Another possibility is a software bug - lost interrupts or similar.

 

[Mosaic]

I'm polling the TXIF to stuff TXREG. The terminal prg is showing a lot of framing errors. From the data rec'd I can see some ascii being concatenated etc. and missing commas.
The Proteus sim loses no data though.. I tried pullups and pulldowns on the TX line...no help.

Perhaps if someone could share some asm UART code I could try it and start isolating from there.