Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Is communication to PC at 921kbps even possible.

Status
Not open for further replies.

x3.exe

Member level 1
Member level 1
Joined
Sep 8, 2009
Messages
33
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Location
Bradford
Activity points
1,653
I have posted quite a lot of topics, asking people for advice regarding interfacing uC to my laptop. Most of the answers were : use rs232 cable connection, cause it is easy to implement and monitor and bla bla bla, and the others were totally stupid. The only problem with this solution is that serial comm ports of most laptops can receive or send data at maximum 115kbps, and as far as I understand this limitation comes from the PCI card in my laptop which cannot be replaced easily. For my project I need data rates of approximately 512kbps. So I asked for alternative uC to PC interface option. And the replies were: use USB , cause it is fast and there are plenty of USB ports on every modern laptop. Seems to be a good solution, but only up to the point where you try to find some software to monitor the data flow to the PC port, like windows hyperterminal used for serial comm port monitoring. And after hours of googling I found that there is no need to search for such software, as all terminal emulating programs can still be used with USB ( sounds really reassuring), as with proper drivers they can represent usb connection as a virtual comm port, which again is limited to 115kbps( What the hell?!!). So what's the point in using USB connection in that case, as there is absolutely no increas in data rates?

Shortly about the system I am trying to develop: it is basically a microcontroller with four analogue inputs from four sensors, which are converted to digital form via built in ADC (sampling each channel at 8khz) and then stored on the MMC card. All the data then needs to be transmitted to PC as fast as possible. Uart of the microcontroller can operate at 921Kbaud max. Right now, with data throughput of the uC to PC link limited to 115kbps, I have to wait for more than a minute to get the data sampled over 10seconds. Ideally all samples from ADC need to be transmitted to PC in real time, so speeds of around 921kbps are more than enough. Can anyone advise me on how to achieve this speed?

Thanx in advance.
 

x3.exe said:
as with proper drivers they can represent usb connection as a virtual comm port, which again is limited to 115kbps( What the hell?!!). So what's the point in using USB connection in that case, as there is absolutely no increas in data rates?

The point is that, given a natively-USB aware embedded device (as opposed to one which uses a serial-USB converter hooked up to one of its ow UARTs) on the other end of the USB cable, the baud rate you set at the PC end of the cable is irrelevant - the actual transfer rate will be determined by the speeds at which the sending device can spit out data and the receiving device can accept it, up to the physical limits of the particular type of USB connection being used.
 

    x3.exe

    Points: 2
    Helpful Answer Positive Rating
hi,

From the description of what you are wanting to do, perhaps this usb data card project will help.

**broken link removed**
 

they can represent usb connection as a virtual comm port, which again is limited to 115kbps
Completely wrong, as Chris said. You can easily achieve 1 or 2 Mbps, with good programming near to full USB payload.
 

    x3.exe

    Points: 2
    Helpful Answer Positive Rating
ChrisC said:
x3.exe said:
as with proper drivers they can represent usb connection as a virtual comm port, which again is limited to 115kbps( What the hell?!!). So what's the point in using USB connection in that case, as there is absolutely no increas in data rates?

The point is that, given a natively-USB aware embedded device (as opposed to one which uses a serial-USB converter hooked up to one of its ow UARTs) on the other end of the USB cable, the baud rate you set at the PC end of the cable is irrelevant - the actual transfer rate will be determined by the speeds at which the sending device can spit out data and the receiving device can accept it, up to the physical limits of the particular type of USB connection being used.

Glad to hear that I am totally wrong, but what do I need to install on the PC side in order to receive data at 921kbps? other drivers? other software to replace hyperterminal?
Forgot to mention that at the moment connection to PC from microcontroller is established through PIC18F with USB interface, which is a part of my development board (16-bit 28 pin starter board). The driver was also provided with the board. So I guess I will need another driver , is it right? And if the connection is established without emulating the serial com port, how do I see the data coming to the port in order to verify that it was transmitted correctly?

I know that I am asking too many questions, but I am really stuck at this point of my project and I need some guidance right now. Hope you understand that and will be able to help me a bit more. Thanks in advance.

Added after 2 hours 11 minutes:

FvM said:
they can represent usb connection as a virtual comm port, which again is limited to 115kbps
Completely wrong, as Chris said. You can easily achieve 1 or 2 Mbps, with good programming near to full USB payload.

Well, when I connect the board to my laptop it appears as com 9 in Realterm, it functions properly when baud rate is set to 115.2Kbaud, and freezes completely when I try to increase the baud rate. What else can cause it except for UART FIFO buffer's overflow? I have read on the internet that virtual com ports are almost the same as the real ones, so all the limitations of the real ones should also apply to virtual com ports. Or am I completely wrong with that statement? I would be really grateful if you could answer that question of mine.
 

may I suggest you to use something like this device (CY7C68013A)/board:
http://www.wb6dhw.com/HSUSB.html
you will need to spend SOME time on it but the results can be really good.

Other links similar to the previous one:
http://www.triplespark.net/elec/periph/USB-FX2/

Or if you do not want to spend too much time developing the firmware, you can buy a USBee SX or ZX: http://www.usbee.com/sx.html and using the clock input as "strobe" you will be able to sample your data at really good speed.
Please remember that on your micro you will need an 8 bit output port+1 bit as strobe...
 

Thank you for this info, I appreciate your help, but what I need at the moment is probably a UART to USB bridge circuit, which would allow me to interface my uC, which doesn't have a built-in USB interface to my laptop. If you could recommend some good boards which I could use for this purpouse, I would be very grateful ).
 

As already said, that the PC side baud setting has no actual meaning for a virtual com port. If I remember right, I have set it to different values in my VCOM applications without detectable effects. Thus I don't understand, what's the problem with your terminal in this regard. You may want to make a different test: Check if 9k6 gives a different speed than 115k.

Generally, three parts have to be considered in virtual com (USB CDC) application: The PC side software, the settings in the *.inf file and the processor firmware. For the *.inf file, it should set Class=Ports to involve minimal overhead on the processor side.

The throughput strongly depends on the I/O handling on the PC and uP side. A possible fault is sending single characters rather than full 64 byte packets. A terminal program is often using single byte IO, possibly also in file transfer if it's poorly designed. This doesn't matter much with a real UART, but can mean orders of magnitude with vcom or an USB to RS232 converter. Similar trapdoors exist on the uP side.
 

    x3.exe

    Points: 2
    Helpful Answer Positive Rating
x3.exe said:
And if the connection is established without emulating the serial com port, how do I see the data coming to the port in order to verify that it was transmitted correctly?

The connection IS established by emulating a serial port - that's the whole point of using virtual COM ports - but since the connection is, at the hardware level, actually a USB connection, all of the hardware-specific limitations of a real COM port disappear. So at the software level, any half-decent COM port aware application should be able to send/receive over a virtual COM port connection in the same way as they would use a real COM port connection.

If the app is a bit brain dead and relies on the baud rate setting to throttle the incoming data, then it might have problems running on a virtual COM port where this throttling doesn't exist. But so far I've yet to come across an app where this was an issue - even the terminally useless Hyperterminal seems to be able to handle virtual COM ports at least as well (which isn't saying much, admittedly) as real COM ports...


In short, if your virtual COM port has been set up correctly by the low-level drivers, then in your PC applications you can simply treat it like you would any other COM port, using the same function calls to set up and service the comms link as if you were writing to something hanging off a real RS232 port. The only thing you need to remember is - as mentioned above - that your incoming data may be hitting you a lot faster than you'd expect.


Well, when I connect the board to my laptop it appears as com 9 in Realterm, it functions properly when baud rate is set to 115.2Kbaud, and freezes completely when I try to increase the baud rate. What else can cause it except for UART FIFO buffer's overflow?

There is no UART in this connection, remember. As FvM suggested, try lowering the baud rate and see if that actually does slow down the incoming data - for a properly implemented virtual COM connection, it shouldn't...
 

    x3.exe

    Points: 2
    Helpful Answer Positive Rating
Thank you very much for your detailed answers. From what I understood, the cause of the problem is probably not on the PC side, but in the UART to USB bridge provided on the board, probably some buffer overflows happen in PIC18F when receiving data through UART from PIC33FJ. The bad thing is that I can't verify this assumption, as no detailed documentation was provided by microchip about that UART to USB bridge. I will try to replace it with another one and see if it works. By the way, do you know any easy ways to enable my PIC33FJ to communicate to PC via USB, without using uC with native USB interface (simply don't want to spend more money on buying another development board in order to program the 18F uCs), any ready to use UART to USB bridge boards?
 

Ahh, so you're not using a PIC with native USB support... Indeed, this could well be the source of your problems, because now even though you've still got a virtual COM port on the PC end of the cable, at the other end you're going through a physical one, with all the usual limitations therein.

Unfortunately my only experience with using virtual COM ports to talk to embedded devices has been with ones which have native USB support, so I don't have any experience with USB-UART bridge devices. One of the guys I used to work with recently was keen on the Prolific PL2303, so you might want to look at that.
 

    x3.exe

    Points: 2
    Helpful Answer Positive Rating
An "UART to USB" bridge of course isn't a true virtual COM port, it's also real UART with a specified baudrate, that can't be overriden. The achievable speed is also limited by the available baud rates at the uP side. That's not a suitable way to achieve high speed, I think. A USB to parallel interface (e.g. FTDI FT245) is the usual solution to get a high throughput without USB hardware at the uP.
 

    x3.exe

    Points: 2
    Helpful Answer Positive Rating
**broken link removed**

here is an alternative
an embedded dos computer with ethernet conection

but a little expensive
 

FvM said:
An "UART to USB" bridge of course isn't a true virtual COM port, it's also real UART with a specified baudrate, that can't be overriden. The achievable speed is also limited by the available baud rates at the uP side. That's not a suitable way to achieve high speed, I think. A USB to parallel interface (e.g. FTDI FT245) is the usual solution to get a high throughput without USB hardware at the uP.

By high speed I meant a speed which is higher than the one that can be achieved using a communication link using a combination of a MAX232 chip and a rs232 cable (that is 115kbit). For my project I only need 1Mbit, which is the maximum data output rate of the UART of my microcontroller.

Anotherbrick, thanx for the info, but I'd rather prefer a cheaper way to add usb interface to my uart uC.
 

It's PIC18F2450\ML.

When I send data from my microcontroller, which is PIC33FJ128GP802, to my laptop at baud rate settings above 115.2Kbaud, no data is transmitted to the laptop. When I repeat the process with the baud rate set to 115.2 or below that value, everything works fine. When receiving data from laptop at baud rates above 115Kbaud, I can receive the data, but it is different from what was sent. For example, when I send a set of ASCII characters "a" which is 61 in hex, I receive E1 instead. So I assume that such behaviour can be explained by UART receiver and transmitter buffer overflows on the PIC18F2450. Maybe the maximum data throughput of this bridge is limited to 115Kbps. Can't say for sure yet.
 

Sorted it out. For people who have faced or will face similar problem : It appears that most PIC18F microcontrollers have UARTs which can operate at maximum baud rate setting 115.2Kbaud. PIC24 series microcontrollers have UARTs capable of operation at up to 921Kbaud. So it is the UART to USB bridge which is limiting the data transfer rate. So that's why UART to USB bridge via PIC18F isn't recommended for systems which require fast communication with PC.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top