USB in a NutShellMaking sense of the USB standardStarting out new with USB can be quite daunting. With the USB 2.0 specification at 650 pages one could easily be put off
When you say instructions, your talking about the assembly line variant after the compiler converts the c code we use. I can't remember the exact assembly terms or the correct syntax, but it would almost be:- Something with a loop, BEGIN maybe?- READ x, dma_buffer- STORE ram_buffer, x- Something to return back to the top, RETURN maybe?
From what I understand, we decide where in RAM we want the DMA controller to send the data to maybe through the use of some set function given by Atmel in the datasheet for the microcontroller. If we have some char array, say 8bytes long to give 8 total characters, would the interrupt be thrown once the buffer is completely filled in or read out, or could we decide to tell the controller, "HEY, I'd like you to read/write only half way up this buffer"?
I love the idea of the interrupt being thrown once complete, but what would happen if the microcontroller is already taken care of another interrupt? I know for the UNO, this new interrupt would be lost. My guess is that for the DUE, interrupts are put into a queue, since we have to clear the fired interrupt within the function call.
Would you happen to know what the hardware buffer size limit is for the DMA controller? What if we are reading/writing a big chunk of data, say 1kB worth. Would we have a possible buffer overflow?Again, thanks for the great explanation. It does help to understand how everything is really working internally.
It should be obvious to pretty much everyone that an 84MHz processor is unlikely to be able to sustain 38MB/s unless you use DMA or spend every single processor cycle moving data to the USB buffers.