It seems that the MBED serial port can only be set to max at 115200 baud.

The MBED mass storage interface appears to run at some 40Kb/s which is 5-10 times faster (includes overhead required when writing a file).

Is there any hope that the MBED firmware and Windows driver could be upgraded to get higher speed?

Regards
Anders

As I recall, 115200 is a limitation of the rs-232/485 standard. I don't think the UARTs on the mbed can go any faster, but I could be wrong. Also, the mbed serial-usb interface could also be limited to 115200. Maybe some of the other guys can clarify.

It is possible to get more throughput using ethernet or the real USB on the lpc1768. It would be nice if someone develops a communication driver and libraries for the USB interface.. Either way, the serial communication isn't intended for high-speed communication. I'd imagine you would get into all sorts of transmission problems if its much faster.

Hi,

Anders Rundgren wrote:
It seems that the MBED serial port can only be set to max at 115200 baud.

It should support 921600; try that for an x8 boost. Remember to set it on the terminal and in your program.

Simon

Hi Simon,

I did as you said but it fails on 230400, 460800 and 921600.
I tried with identical results on Ubuntu and XP.

Any ideas would be appreciated!

F.Y.I. I use the http://rxtx.org package latest version as driver.

Regards
Anders

Hi Anders,

Anders Rundgren wrote:
did as you said but it fails on 230400, 460800 and 921600. I tried with identical results on Ubuntu and XP. Any ideas would be appreciated!

Sorry to tell you it was working without confirming it was repeatable this end; I've just tested it and you are correct, it is failing at those speeds.

However, we specified it to work at these speeds and I have done some quick checks to confirm it does work in theory; the firmware/hardware is fine, so it is a library bug. I have raised a ticket to look at it and we'll get it fixed asap. You should then be able to use it at 921600 without problems.

Simon

Sounds fantastic!

Regards
Anders
MBED newbe and fan

How can you guys set those speeds on the computer? My mbed port can only be set as fast as 128 000...

I don't set speed through the device driver (that for Windows isn't even equipped with speeds over 115200), but through API calls in the http://rxtx.org package.  It seems to work fine.

Anders

Hi Anders,

I've just updated the libraries to v19 - this should now support standard baud rates up to 921600. Here is an example test program I used with Teraterm:

// display clock frequency at 921600 baud, sford

#include "mbed.h"

Serial pc(USBTX, USBRX);

int main() {
    pc.baud(921600);
    pc.printf("SystemCoreClock = %d Hz\n", SystemCoreClock);
    while(1) {
        pc.putc(pc.getc() + 1);
    }
}

SerialSpeedTest

Remember to set the speed on the Host PC too. For those using Teraterm, this is under Setup > Serial Port... (for the faster speeds, make sure you've got an up-to-date version of teraterm).

To get the new library, select it in the filetree and click "update to latest version". Can you confirm this works for you now?

Thanks!
Simon

Thank you Anders and Simon!

I couldn't set the higher speeds in terraterm. I thought it was Windows, but I guess it's just an old version.

Hi Igor,

Take a look at http://mbed.org/handbook/Terminal for where to find the latest version.

Simon

Hi Simon,

I have tested the new library (v19) but it did not perform exactly as I had hoped :-(

On 921600 I get erratic operation so I did more testing on half that speed.
It seems that the device is quite capable receiving data at high speeds.

But when I start to send huge chunks of data, communication is both slow and unreliable.
Since not even reset works and the on led stops, I guess the problem is rather in the firmware.

I would be great if this is curable, 5 Kbyte/s for fetching data is all I can get today.

Regards,
Anders

Hi Anders,

Anders Rundgren wrote:
But when I start to send huge chunks of data, communication is both slow and unreliable. Since not even reset works and the on led stops, I guess the problem is rather in the firmware.

Thanks for the full report - the completeness makes a real difference vs. "it doesn't work"! I think your hypothesis could be valid, and we'll put the firmware through it's regression runs. Please understand this may take a little longer than the previous update.

btw. What do you want to do with such a high data rate? (I know it is not that high, but for serial, it is pretty high :)

Simon

Hi Simon,

I fully understand that finding the culprit in the firmware (if my analysis is correct...) is a difficult task, particularly in the MBED case where there are multiple players LCP (library) <==> Magic chip (firmware) <==> PC (using various drivers) in the plot.

My guess is that there is something wrong with flow-control.

> btw. What do you want to do with such a high data rate?
>(I know it is not that high, but for serial, it is pretty high :)

Actually I'm open to any kind of protocol but for MBED using the built-in USB connector, I'm not aware of any other solution than USB-serial.  Since USB-serial is a virtual protocol, it should (at least theoretically) be capable running as fast as USB can.

My application is what I call "a smarter smart card" which will (hopefully) be the first card that will deal with Microsoft's Information cards which can be as large as 50Kb.  Waiting 20 seconds for each card to appear would make the PoC a bit lame so I hope that there is a possibility to get this working.

I have a fairly advanced test-program for the serial part which I can ship in case you are interested.

Hi Anders,

Its not entirely USB, The serial interface is coming from UART0 on the LPC1768, the other processor ('magic' chip) is using it's own UART to communicate to UART0, because there is no line driver the bus speed can be increased

, but the other processor still has to transfer the data between the UART and the USB connections.

I assume you're using either the SPI or I2C/S bus for this?

Wouldn't you be better using the LPC1768's USB port rather than the mbed port for this implementation?

This way you could implement a more direct connection.

Regards

Andy

You may also want to look at rolf's contribution here http://mbed.org/users/rolf/notebook/hexview/ may help reduce bandwidth requirements

Hi Andrew,

>Its not entirely USB, The serial interface is coming from UART0 on the LPC1768,
>the other processor ('magic' chip) is using it's own UART to communicate to UART0,
> because there is no line driver the bus speed can be increased
>, but the other processor still has to transfer the data between the UART and the USB connections.

Yes, I think I got that by looking at the sketch Simon did a few days ago.

>I assume you're using either the SPI or I2C/S bus for this?

I use the MBED library's Serial API which I assume is driving UART0.

>Wouldn't you be better using the LPC1768's USB port rather than the mbed port for this implementation?

Unfortuately that makes leaving MBED a more logical alternative, at least in my smart-card application which is self-contained.

>This way you could implement a more direct connection.

I started this way with LUFA and AT91USBKEY (AVR) but I liked what I saw at MBED so I hope that it is possible to increase speed a bit and most of all making the communication reliable.

Regards
Anders

Just to clarify.. Are the problems with sending data, receiving data or both? (with respect to the mbed).

On the highest setting both directions seems unreliable.
Uplink is though the one which seems to be most in trouble because it is slow and clogs up, and even manages to bring the magic chip/firmware down.

/anders

during the debugging I also temporarily introduced async channel operation and then the symptoms got worse.  My app won't need async channels but I'm sure there are plenty of logging apps that could use it.

hi everyone,

I am seshu, recently I bought a IC-LG 21-bit optical position encoder which sends serial data out (rs-485), Now I am just wondering whether I can read these rs-485 data into mbed or not..

can anyone suggest me how it fix it.

Another alternative is it can also send the parallel data out _{but I am more concentrating on the length of the wires.}

seshu