I was looking thru the \arduino-1.5.1r2\hardware\arduino\sam\cores\arduino\USB\CDC.cpp code and notice that the ring buffering is being set to a different size. It is initializing the buffer size to 512 but then only is using 64 bytes (defined elsewhere SERIAL_BUFFER_SIZE is 64). I don't know if this is intentional or not.
void Serial_::accept(void)
{
ring_buffer *buffer = &cdc_rx_buffer;
uint32_t c = USBD_Recv(CDC_RX);
uint32_t i = (uint32_t)(buffer->head+1) % SERIAL_BUFFER_SIZE;
// if we should be storing the received character into the location
// just before the tail (meaning that the head would advance to the
// current location of the tail), we're about to overflow the buffer
// and so we don't write the character or advance the head.
if (i != buffer->tail) {
buffer->buffer[buffer->head] = c;
buffer->head = i;
}
}
int Serial_::available(void)
{
ring_buffer *buffer = &cdc_rx_buffer;
return (unsigned int)(SERIAL_BUFFER_SIZE + buffer->head - buffer->tail) % SERIAL_BUFFER_SIZE;
}
int Serial_::read(void)
{
ring_buffer *buffer = &cdc_rx_buffer;
// if the head isn't ahead of the tail, we don't have any characters
if (buffer->head == buffer->tail)
{
return -1;
}
else
{
unsigned char c = buffer->buffer[buffer->tail];
buffer->tail = (unsigned int)(buffer->tail + 1) % SERIAL_BUFFER_SIZE;
return c;
}
}
Changing SERIAL_BUFFER_SIZE to CDC_SERIAL_BUFFER_SIZE in CDC.cpp has improved things a little - now when the file is sent with a 1ms end-of-line delay it appears to be received correctly. Without the delay though the file is still mostly lost.
Looking at the code, acccept() appears to silently drop characters when the buffer is full - maybe that is where the data is being lost.
On some other recent threads, it is clearly observed that the Serial USB link wether HW or SW (low level or high level) have serious speed issue. One way to perceive this, there are many other methods and practical tests, is by observing the same *.INO project loaded on mega takes almost no time to USB download but HUGE time to download on DUE.
selfonlypath:
On some other recent threads, it is clearly observed that the Serial USB link wether HW or SW (low level or high level) have serious speed issue. One way to perceive this, there are many other methods and practical tests, is by observing the same *.INO project loaded on mega takes almost no time to USB download but HUGE time to download on DUE.
Comparing upload times for the same sketch isn't particularly a good method to compare transfer rates.
It might be that the same sketch generates much larger code on the DUE than on the Mega.
To be fair when comparing upload times,
you need to look at the sizes of the .hex files and adjust the times
based on the ratios of their sizes.
i.e. if the DUE takes twice as long to upload but the .hex is twice is large,
then the upload speed is actually the same.
Could you be more specific about this 10X loading time? Maybe with links to these other topics?
Has anyone actually measured the times? Are the measurements on each operating system, or only one specific system? Does it happen on multiple computers, or is all this from only 1 machine? Is this with the programming port or native port?
So far, I'm only used the beta version of Due (which had only the native port), and only on Linux. I loaded many programs during the beta test period, where I discovered and reported several bugs, with Christian fixed before release. Much of that testing was before the auto-reset was working, so I do recall the cumbersome 3-button sequence, but the loading speed was quite reasonable. I did not measure the specific programming speed, but if it were significantly slower than Uno, I certainly would have noticed. (upload speed is something I really do care about.... I put a huge amount of work into Teensy 3.0 for best possible upload speed)
There. I've specified the hardware, port, software version (early betas), and which operating system I used. It's not hard. You can do this too, rather than simply saying it's 10X slower with no specific facts to back up your claim!
Here are some threads dealing with I think a more global issue related to Programmer USB port, in my case, I use MacBook Air where my code has been running for years on mega, it is Serial protocol using HDLC on to of USB.