Max Baud Rate for Arduino Uno

Single register call: 248 usec.
== > is that the performance of the ReadRegister() code with the direct port manipulation? == code from Reply #36 ??
Is that only 10 micros faster than the digitalWrite() version? ????

Will SD Card logging or Ethernet transmission be faster as compared to this whole USB-Serial conversion?

SDCard : check - http://arduino.cc/forum/index.php/topic,64813.0.html -

This value was without Direct Port manipulation. With port manipulation, there is difference of 2 usec. So, with just 2 usec when the single call is taking around 248 usec there isn't much difference...plus code looks non-arduinoic.

From Reply #32 and your test codes:
It takes 248 usec when I just call Dx() and 1048 usec if I send print over serial, using Serial.print(Dx()).

void setup()
{
  Serial.begin(9600);
  Serial.begin("start");

  unsigned long before = micros();
  Dx();  // Takes 248 usec
  // Serial.print(Dx());  // Takes 1048 usec
  unsigned long duration = micros() - before;
  Serial.println(duration);
}

No idea know, what else could be done.

Thought of using Ethernet with Maple because it has 2 SPI but then it has no Ethernet library yet!
There is also CAN bus support and I could get the CAN-USB converter. How would it be with CAN bus, anybody got idea?

Will check the post you attached. Maybe it can change something. I only fear that I have 10 byte of data and if I have to write to SD card then maybe I had to open and close the file on each iteration. That seems a crazy idea to me.

There is also CAN bus support and I could get the CAN-USB converter. How would it be with CAN bus, anybody got idea?

1 megabit per second maximum over very short distance.

I had lots of problems with the National Instruments converters (software not hardware).

This one worked well...
http://www.esd.eu/german/products/CAN/can-usb-mini_e.htm

And one of the Kvaser converters worked well. I think it was this one...
http://www.kvaser.com/index.php?option=com_php&Itemid=258&eaninput=7330130002418

@dc42 : Reply #41
I don't think that it's USB-Serial conversion. I am taking the time before and after Serial.print(registerCall()). USB-Serial conversion effect could only be seen in amount of logged file/data after the data leave from Atmega168 to Atmega8 for conversion but not on the internal function of Arduino Uno like Serial.print(). There must be something...some delay of microseconds in the library itself that's hampering the transmission.

@Coding Badly:
I suppose CAN uses SPI library instead of Serial library. But if Serial then as I wrote above, if there is problem/delay with Serial.print() or Serial library then it doesn't make any sense to go with CAN bus.
SPI protocol is faster but how fast it converts the data from CAN SPI Bus to USB would be decisive.

I also heard about USB OTG/Slave with Maple Arm, but then I suppose they do run on SPI Protocol.

There must be something...some delay of microseconds in the library itself that's hampering the transmission.

I would suggest looking instead towards the USB serial convertor harware/firmware and the PC USB serial driver, as I don't think it's a single byte at a time transfer from the TTL serial to PC, but rather some buffering and dwell time for USB protocol, etc.

I think serial comm timing over USB is a lot more complex then one might expect.

A good experiment might be to bench mark comm port transfer of various amount of data at the same baud rate, but one run using a USB serial link and one run using a original RS-232 hardware comm port on a PC that has both USB and hardware comm ports. It might enlighten us?

Lefty

But don't you think that Serial.print() actually put the data on the TX pin of Atmega328?

If I got the time for sensor's register call - > Atmega328, say 248 usec and register's call + putting the data on Atmega328 Tx pin takes 1048 usec. I don't get it as to how USB-Serial conversion is coming into the picture. As far as I know, buffer could not be a problem either as it is usually set before the function calls, in the Serial.begin() and in my case, there is just a single byte call in Setup(). I don't know which function Arduino uses but I have worked with Atmega128 where UART is init with baud rate and then there are two function for string and char. The char function is called by the string function, which is then called by itoa() whenever there is printout. As Uart_Init() come in setup(), so there is always call to only three functions.

Call to a single function takes few usec and not 800 usec. If I believe, a large buffer size or itoa() like function being used by Arduino could be at fault.

I'm not talking about buffers inside the arduino code running on the AVR chip, I'm talking about the USB serial to PC process, it's hardware and firmware/software. Read the below FTDI application document and see if there in not other things that also come into play when determining maximum character throughput from arduino code and hardware to PC application software.

Lefty

I should correct myself: Reply #29

Per register call is : 0.3537 ms...instead of 2.8 Kbps it is 2.8 KBytes/sec as its for one 8 bit register call.
I guess the whole confusion started with this silly mistake.

With another discussed sensor, register call was 248 usec. Serial.print(register call) of register took 1048 usec with 9600 bps.
I checked today and with baud rate of 38400bps, Serial.print(register call) took 264 usec.This seems quite good.
I suppose, this conversion overhead is bare minimum (as I also checked after doing modifications with Arduino's library)

So, Sensor's half-duplex port is running at 32 Kbps (248 usec/byte).

I guess, the problem is somehow solved. It was just conversion mistake as pointed above. Anyhow, we could check how fast serial.print() works and under what.

Thank you all!

nitin29:
But don't you think that Serial.print() actually put the data on the TX pin of Atmega328?

You're right. There's no flow control signals between the atmega328 and the serial-USB converter, so the serial-over-usb protocol can't have anything to do with the speed of Serial.print, unless the library includes a deliberate delay at high baud rates in order to let the serial-over-usb protocol keep up. But USB is so fast that I doubt this is necessary.

But USB is so fast that I doubt this is necessary.

Again I suggest one reads the below document to get at least an idea of how the serial-over-usb function actually works. One can't just assume and treat a USB serial link as a limitless pipe where things go out as quick as them come in. When one is talking about arduino running at 1+ Mbaud or greater to a PC there must be a whole system approach looked at for what and were the limits and bottlenecks are.

@retrolefty:

Actually, you are missing the whole point that we are trying to tell. I must give a part of the codes, maybe then it will be clear.

Test Codes:

void setup()
{ 
  Serial.begin(38400);
  pinMode (SCLK, OUTPUT);
  pinMode (SDIO, INPUT);
  ChipReset();
  ReSync();
  ForceAwake(); // LED Always ON

  Serial.println(" Only Call time - ");
  unsigned long before1 = micros();
  Dx();
  unsigned long duration1 = micros() - before1;
  Serial.println(duration1);

  Serial.println(" Print Out time - ");
  unsigned long before2 = micros();
  Serial.print(Dx());
  unsigned long duration2 = micros() - before2;
  Serial.println(duration2);
}

You can seen, what is happening here. I am just taking the time of a call to Dx() (a 8-bit register value) in first and then how much time it take to call Serial.print() to put the data over serial (Tx pin). Upto here we are in Atmega328's circuit.

I am not talking about how much time it take for a register call and time it take to appear on OS terminal. So, how does Serial-USB conversion is coming into picture?

nitin29:
I am not talking about how much time it take for a register call and time it take to appear on OS terminal. So, how does Serial-USB conversion is coming into picture?

If retrolefty is correct in thinking that serial-to-usb conversion may be a bottleneck at the speeds you are using, then although this will not affect the speed of the Serial.print call because of the absence of flow control, there could be a risk of dropped characters.

I've taken a look at the Serial library, and for your particular application, I think the Serial.print(X) calls are probably what's taking too long, where X is the integer returned by Dx() or Dy(). You might wish to do some tests to confirm this. There are faster alternatives to using this overload of Serial.print.

There are faster alternatives to using this overload of Serial.print.

What are the faster alternatives to Serial.print() ?

At 38400 bps: Difference to call to Dx() (248 usec/byte) and Serial.print() (264 usec/byte) is 16 usec/byte.

nitin29:
What are the faster alternatives to Serial.print() ?

At 38400 bps: Difference to call to Dx() (248 usec/byte) and Serial.print() (264 usec/byte) is 16 usec/byte.

I don't understand what you are comparing. Do you mean that Serial.print(Dx()) takes only 16us longer to execute than Dx() ? If so, I am wrong and you may ignore what follows.

I am referring to the overload of Serial.print() that takes an integer. This is the one you use to print the values of Dx() and Dy(). If you time calls to different overloads of Serial.print(), I think you will find that printing a number e.g. "Serial.print(123)" or "Serial.print(123, DEC)" is, at the very high baud rates you are trying to use, slower than printing a character e.g. "Serial.print(';')" or printing a short string e.g. "Serial.print("123")". This is because printing a number involves quite a lot of code to convert the number into characters. It is made worse because the atmega processor doesn't have a hardware divide instruction, so to divide by 10 and get quotient and remainder is quite slow.

It would be faster to do the integer-to-characters conversion using a lookup table, or else to convert the number to hex instead of decimal so you can use shift and mask instead of quotient and remainder.

Yes, I meant what you understood in your first line.

However, I couldn't resist to read further. You pointed something interesting about conversion from int to char and int to hex. I will check how long the execution takes for both of these conversion. If it take less for int to hex conversion than I can improve the 16 usec time difference as I can do the hex to char conversion on PC.

Conversion to hex using Serial.print is unlikely to be any faster than conversion to decimal, because it uses the same code but with a different divisor. However, it is possible to write a more efficient function for converting to hex and then printing the result, by using shift instead of divide.

Hi,
How did you tested 1,2 mbps as window7 does not support these higher baud rates.

Thanks

jumshed63:
Hi,
How did you tested 1,2 mbps as window7 does not support these higher baud rates.

Thanks

Where did you get this information about the max baud rate of Windows?
AFAIK it depends on the terminal application used.
The Arduino IDE can go up to 115200 but e.g. putty.exe goes much higher (never tested 1.2 mbps)

from my experience it is not possible to go more than 2x115200bps on arduino