next topic »

[Reply #15 on:]

It is best if you use code tags not quotes, it is the # next to the quote.
Why

Code:

Serial.flush();

I can't see it doing anything for you.

Because on the Uno, Serial.write is non-blocking.

[Reply #16 on:]

It is best if you use code tags not quotes, it is the # next to the quote.
Why

Because the box is smaller, it scrolls, and the forum doesn't scramble your code up so people can copy and paste the code and reproduce your problems.
 
And mainly because that is what people want around here and it show common decency to comply. After all you are the one asking the questions.

Because on the Uno, Serial.write is non-blocking

Only to the extent of not having a full buffer.

[Reply #17 on:]

It is best if you use code tags not quotes, it is the # next to the quote.
Why

Because the box is smaller, it scrolls, and the forum doesn't scramble your code up so people can copy and paste the code and reproduce your problems.
 
And mainly because that is what people want around here and it show common decency to comply. After all you are the one asking the questions.

Quote within quote confusion... I didn't ask why.  I'm not trying to cause a problem.

Because on the Uno, Serial.write is non-blocking

Only to the extent of not having a full buffer.

True but not calling Serial.flush wouldn't show how fast bytes were being transferred out of the chip which was my goal.

[Reply #18 on:]

Ok that last code as poster reports:-

39258 bytes/second

On a Leonardo.

[Reply #19 on:]

Ok that last code as poster reports:-

39258 bytes/second

On a Leonardo.

It seems like the rate is highly dependent on the computer where it wasn't on the Uno.

[Reply #20 on:]

That is no surprise is it?

It is still a USB device and that get polled at a maximum of 1KHz, so I guess it is down to how fast the host computer empties the buffer. Allowing more bytes to be transferred.

[Reply #21 on:]

That is no surprise is it?

No.

It is still a USB device and that get polled at a maximum of 1KHz, so I guess it is down to how fast the host computer empties the buffer. Allowing more bytes to be transferred.

Where does the 1kHz come from?

[Reply #22 on:]

Where does the 1kHz come from?

The polling rate of a USB HID device.

[Reply #23 on:]

That 1 ms polling rate is true only for HID (the keyboard and mouse) which use the USB interrupt transfer type.  CDC (which Leonardo refers to as Serial) uses the USB bulk transfer type which doesn't guarantee timing but does guarantee that it will transfer the data as fast as possible.  That "fast as possible" depends on what else is happening on the bus AND on the host computer.

In practice this does lead to different maximum transfer speeds for Serial on different computers (and even on the same computer under different workloads).  I don't have a board with me right now but, from memory, you can usually assume at least several tens of kb per second, up to a few hundreds of kbps.

It's not necessary to call Serial.begin() for the Leonardo since the CDC device is initialized elsewhere.  The stub was retained for backwards-compatibility. 

Serial (which talks CDC over USB to the host) and Serial1 (which talks to pins 0 and 1 via the UART) are both definitely available and usable on the Leonardo.

[Reply #24 on:]

zeveland, I noticed much of the USB code for Arduino came from you.  Can you say how you learned to write "USB code?"  I read part of one book on the topic, but the material wasn't well written and as a result difficult to understand.

[Reply #25 on:]

mkwired, sorry - had overlooked your message.  I can't take much credit - most of the implementation was done by a brilliant guy named Peter Barrett. 

Almost everything I know about USB has come from working with Dean Camera's LUFA project (http://fourwalledcubicle.com/LUFA.php), reading Jan Axelson's USB Complete book, and reading the specs until my eyes bled.

[Reply #26 on:]

I found this interesting:

It's not necessary to call Serial.begin() for the Leonardo since the CDC device is initialized elsewhere.  The stub was retained for backwards-compatibility. 

.. since it seems to say that the serial speed for the USB CDC is independent of whatever code you write. I'm inferring that since you don't need to open the port with a speed (e.g. Serial.begin(115200))

Does that sound right?

Which leads me to my second question:

Q: Is the serial monitor in the Arduino IDE monitoring the USB CDC serial port or the hardware serial port?

Thanks for any insights!

Daniel

[Reply #27 on:]

Q: Is the serial monitor in the Arduino IDE monitoring the USB CDC serial port or the hardware serial port?

It's the USB CDC (unless you connected a USB2Serial to the hardware serial port and to the PC too).

.. since it seems to say that the serial speed for the USB CDC is independent of whatever code you write. I'm inferring that since you don't need to open the port with a speed (e.g. Serial.begin(115200))

Does that sound right?

As you can see in the implementation:

Code:

void Serial_::begin(uint16_t baud_count)
{
}

... this is correct.

[Reply #28 on:]

Thanks for the clarification!

The documentation on serial ports fir the Leonardo is a bit lacking.

When you open the serial monitor, and are monitoring the USB(CDC) connection, does the baud rate pulldown have any effect?

D

[Reply #29 on:]

When you open the serial monitor, and are monitoring the USB(CDC) connection, does the baud rate pulldown have any effect?

Theoretically yes, but it doesn't change any relevant parameter, it just sets some values in the driver on the PC. The counterpart on the Leonardo doesn't react on it.