Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

RS 232 - USB

Status
Not open for further replies.

atferrari

Well-Known Member
Most Helpful Member
I've just completed an application with RS 232 PIC-PC both ways. Found it quite simple and much less painful than I feared. (Lack of knowledge, of course.)

My questions:

For PIC-PC comms:
a ) Am I jumping too late in a train that will disapear soon :?:

b ) Should I definitely consider USB and forget RS 232?

For PIC-PIC (no PC involved)
c ) Answers for a ) & b ) do they apply here?

d ) Not having handy PIC micros with embedded USB
is it possible to get assembler code able to be adapted in a PIC?
(Am I being crazy, asking for this :?: )
 
USB is GREATLY more complicated that RS232, certainly easily 20-30 times more complicated (if not more) - this applies to both the PIC and PC sides of the USB link.

MicroChip have a number of examples in their datasheets, try looking at them to see what I mean.

Using USB PIC to PIC would be EXTREMELY silly, what possible use could it be?.
 
as a proof-of-concept why not, do it. But USB is extreamly complicated. On Linux/Windows you ca njust use Python and the pyUSB module to extreamly simpify USB (as simple as )

Code:
import usb	# import usb module

bus = usb.busses()	# get available busses

for b in bus:		# list of the busses
	pass

for dev in bus[0].devices:		# list of the bus
	pass

device = bus[0].devices[0]

for c in device.configurations:	# list of the device configurations
	pass

handle = device.open()	# open the device

conf = device.configurations[0]

for i in conf.interfaces:	# available interfaces
	pass

intf = conf.interfaces[0]

for alt in intf:			# available alternate settings
	pass

altset = intf[0]

handle.setConfiguration(0)
handle.claimInterface(0)

#
# use it
#

handle.releaseInterface()	# called automatically on __del__
del handle

however, it is only easy because the hard part is hidden.
on the PIC side you will have to do everything that the pyUSB and USB drivers do (to give you an idea the original implementation of USB into the 2.4 linux kernel took 5pages of code and that was just to get the hub talking).


as to pic->pic, why? USB trasnmits serial data and the only two advantages is that you can have 255 devices from one hub and alot quicker then RS232, with data measured in megabytes the hassle is worth it, for pics? no
 
atferrari said:
d ) Not having handy PIC micros with embedded USB
is it possible to get assembler code able to be adapted in a PIC?
(Am I being crazy, asking for this :?: )
I'm afraid it is crazy. USB currently uses only three data rates. Using any other data rate is noncompliant.

For a compliant USB implementation, it would be interesting to see if a Ubicom chip is fast enough. I don't think any of the normal PICs are fast enough to handle compliant USB at the bit level. The slowest rate is 1.5 Mbps, which leaves you only 666 ns per bit. The protocol is synchronous (no gaps) with a variable packet size, so you need to be checking for the special "end of packet" signal while you're gathering data.

You can cut a lot of corners, but the basic bit level format is oriented towards hardware implementation. Clocking is expected to be extracted by use of PLLs, as there isn't a separate clock signal. For bit density, bits are encoded as transition/no-transition. And bit stuffing is used to keep PLLs in sync. Although software can replace the PLLs, if you aren't oversampling, receiving the bit stream will be unreliable.

And it gets worse if you want to talk to a PC.

If you want USB, use a USB peripheral.

Otherwise, you're better off using SPI, I2C, or some other serial protocol.
 
Just like everyone else mentions here implementing USB with a PIC is rather difficult.... but if it is USB what you want you can always use a RS232-USB converter.


FTDI makes a killer chip. What it is, a chip that accepts RS232 from your PIC and sends it over the USB media. Once it arrives to the PC, FTDI provides you with a USB driver that simulates a RS232 port. This is called a virtual COM port, and it "fools" the PC into thinking that it has another COM port and the driver makes sure to tranform the USB data coming from the PIC, into RS232 data that can be read from the virtual com port. This simplifies things a whole lot.

There is no need for USB for PIC to PIC communications, I would rather use the I2C or RS232 for those. But PIC to PC I would recommend the USB since more and more computers now have only USB ports.

Ivancho
 
ivancho said:
Just like everyone else mentions here implementing USB with a PIC is rather difficult.... but if it is USB what you want you can always use a RS232-USB converter.


FTDI makes a killer chip. What it is, a chip that accepts RS232 from your PIC and sends it over the USB media. Once it arrives to the PC, FTDI provides you with a USB driver that simulates a RS232 port. This is called a virtual COM port, and it "fools" the PC into thinking that it has another COM port and the driver makes sure to tranform the USB data coming from the PIC, into RS232 data that can be read from the virtual com port. This simplifies things a whole lot.

There is no need for USB for PIC to PIC communications, I would rather use the I2C or RS232 for those. But PIC to PC I would recommend the USB since more and more computers now have only USB ports.

As I've mentioned previously, recent reports and tests find that RS232/USB converters tend to be pretty slow, with 9600 baud the maximum you can expect (which is often fast enough anyway). This is because RS232 sends and receives single bytes, USB sends data 'packets', and sending single bytes cripples it's speed.
 
Well FTDI claims that they are able to do 1 Mega Baud rate on RS232 and 3 mega baud rate ib RS422/RS485.
 
ivancho said:
Well FTDI claims that they are able to do 1 Mega Baud rate on RS232 and 3 mega baud rate ib RS422/RS485.

Microsoft claims windows is stable,
NVE claim their mag isolation chip's out-perform opto's

The fact is the engineering dept and sales dept are two different dept with different aims
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top