Go Down

Topic: Max Baud Rate for Arduino Uno (Read 16346 times) previous topic - next topic

Coding Badly

Quote
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

nitin29

#46
Sep 01, 2011, 01:01 am Last Edit: Sep 01, 2011, 01:04 am by nitin29 Reason: 1
@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.

   
-- Nitin

retrolefty

#47
Sep 01, 2011, 01:33 am Last Edit: Sep 01, 2011, 01:37 am by retrolefty Reason: 1
Quote
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

nitin29

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.
-- Nitin

retrolefty

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.


http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf

Lefty

nitin29

#50
Sep 02, 2011, 06:13 pm Last Edit: Sep 03, 2011, 01:57 am by nitin29 Reason: 1
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!
-- Nitin

dc42


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.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

retrolefty

#52
Sep 02, 2011, 11:40 pm Last Edit: Sep 02, 2011, 11:43 pm by retrolefty Reason: 1
Quote
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.

http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf

nitin29

#53
Sep 03, 2011, 02:08 am Last Edit: Sep 03, 2011, 02:22 am by nitin29 Reason: 1
@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:

Code: [Select]


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?
-- Nitin

dc42


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.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

nitin29

Quote

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.

-- Nitin

dc42


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.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

nitin29

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.
-- Nitin

dc42

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.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

jumshed63

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

Thanks

Go Up