Capture Qei position and send to usb

When using any peripherial that has the hardware support for it, you may be able to poll the device for data. Or configure the device to issue an interrupt for each data getting available. Or configure the device to hand off data to a DMA channel. This may be an SPI device, an UART, or maybe an ADC - the concept is still the same.

So if this quadrature device supports DMA, then you need to configure one DMA channel to take the quadrature device as data source, and a buffer as data destination. The DMA channel can then generate interrupts to let you take care of received data and potentially supply new buffers to use. For DMA channels that supports it, it is often nice to have a buffer that is twice as large as the block size you want. So the DMA channel can interrupt when the buffer is half-full. Then you have ample time to take care of the already received data while the DMA channel continues to fill the other half of the buffer. And the ISR can tell the DMA what to do when the second half of the buffer gets full - i.e. that the DMA channel should restart from the beginning of the buffer again. So you basically double-buffer the transfer with a 2*n-sized buffer.

If you don't have too high data rates, it is possible to ignore any DMA transfers and instead have one interrupt/sample. And have the ISR pick up a single value and put in a buffer. This is ok as long as the ISR doesn't consume too much time, and the ISR is guaranteed to pick up a value before the device have produced the next value.

So Tsuneo Chinzei is talking about a concept, while leaving it to you to flesh out actual code to fulfill this concept. Note also that he wrote:

As of QEI unit of LPC17xx, an ENCLK_Int interrupt occurs at the every transition of the
encoder. In this ISR, your firmware reads out a timer value, which runs freely, to know the
interval of the every transition. Cortex-M3 NVIC has fixed interrupt latency of 12 cycle. You
may get exact interval with this method.

That indicates the he isn't talking about any DMA transfers, but about the ISR handling individual samples. So that would obviously mean that _you_ would be the one who decides the name of the buffer, and you who decides how to keep track of amount of data in the buffer.

So no way at all that anyone else can tell you the names that _you_ would decide to use when _you_ implement that ISR. So the reason no one gives you the answer to your questions is that it isn't possible for anyone to answer them. It's on your table to decide.

When using any peripherial that has the hardware support for it, you may be able to poll the device for data. Or configure the device to issue an interrupt for each data getting available. Or configure the device to hand off data to a DMA channel. This may be an SPI device, an UART, or maybe an ADC - the concept is still the same.

So if this quadrature device supports DMA, then you need to configure one DMA channel to take the quadrature device as data source, and a buffer as data destination. The DMA channel can then generate interrupts to let you take care of received data and potentially supply new buffers to use. For DMA channels that supports it, it is often nice to have a buffer that is twice as large as the block size you want. So the DMA channel can interrupt when the buffer is half-full. Then you have ample time to take care of the already received data while the DMA channel continues to fill the other half of the buffer. And the ISR can tell the DMA what to do when the second half of the buffer gets full - i.e. that the DMA channel should restart from the beginning of the buffer again. So you basically double-buffer the transfer with a 2*n-sized buffer.

If you don't have too high data rates, it is possible to ignore any DMA transfers and instead have one interrupt/sample. And have the ISR pick up a single value and put in a buffer. This is ok as long as the ISR doesn't consume too much time, and the ISR is guaranteed to pick up a value before the device have produced the next value.

So Tsuneo Chinzei is talking about a concept, while leaving it to you to flesh out actual code to fulfill this concept. Note also that he wrote:

As of QEI unit of LPC17xx, an ENCLK_Int interrupt occurs at the every transition of the
encoder. In this ISR, your firmware reads out a timer value, which runs freely, to know the
interval of the every transition. Cortex-M3 NVIC has fixed interrupt latency of 12 cycle. You
may get exact interval with this method.

That indicates the he isn't talking about any DMA transfers, but about the ISR handling individual samples. So that would obviously mean that _you_ would be the one who decides the name of the buffer, and you who decides how to keep track of amount of data in the buffer.

So no way at all that anyone else can tell you the names that _you_ would decide to use when _you_ implement that ISR. So the reason no one gives you the answer to your questions is that it isn't possible for anyone to answer them. It's on your table to decide.

OK
the datasheet says:

GPDMA supports the SSP, I2S, UART, A/D Converter, and D/A Converter peripherals.
DMA can also be triggered by a timer match condition. Memory-to-memory transfers
and transfers to or from GPIO are also supported.

and it appears that DMA doesn't support QEI.
so I must define a normal vector as a buffer, am I right?
and due to the low rate of data changes(least than 1 MHz) the ISR should "pick up a single value and put in a buffer."

I am a beginner in ARM and embedded systems, and need to learn too much about architecture. ;-)

thanks
Amir

Yes - you need to take care of the results one-by-one in an ISR. And invent a buffer to store the result in.