Capture Qei position and send to usb

>Aren't you a funny guy?

>Maybe you would care to expand why you feel "really disappointed".

I don't care you are an active user or a KEIL Employee. but is it your amusement to visit this forum to write such sentences?

Some people usually share their information & knowledge through forum and some other ask (or even beg) other people to help them.
I didn't forced Mr Tsuneo & Mr Erik to answer me! Both of them kindly answered some of my questions. And speaking about "disappointing" won't oblige them to answer and I think it does not contain any insults.

Amir
Hejazi.1365@gmail.com

>Aren't you a funny guy?

>Maybe you would care to expand why you feel "really disappointed".

I don't care you are an active user or a KEIL Employee. but is it your amusement to visit this forum to write such sentences?

Some people usually share their information & knowledge through forum and some other ask (or even beg) other people to help them.
I didn't forced Mr Tsuneo & Mr Erik to answer me! Both of them kindly answered some of my questions. And speaking about "disappointing" won't oblige them to answer and I think it does not contain any insults.

Amir
Hejazi.1365@gmail.com

What amusement do you find in the sentence "Maybe you would care to expand why you feel 'really disappointed'"?

Did you _really_ read what I wrote?

"Some people usually share their information & knowledge through forum and some other ask (or even beg) other people to help them."

Share information requires that the helper already know the answer. If no one who reads your question knows the answer, then no one will be able to share that answer too, unless they invest own time to figure out the answer. And here is where you _do_ have to care about people just being other users of the Keil tools like your self, or if this is a payed support service where people are payed to supply help.

By the way - all your posting of email addresses implies that you want answers sent directly to you instead of having the answers posted on this forum. Private answers do have the big disadvantage that they can't be picked up by Google. So they would not help anyone else.

>In the QEI ISR, the timer value is written to a buffer of 1024 bytes.[Tsuneo]

When the buffer holds 512 bytes (sector size) or more, one sector of data is written to the USB drive.

about one of my questions "the helper already know the answer." and i want to know whats the name of the buffer. is it direct or indirrect? but no body answered me.

I said if they don't want to "share their information" for free and want to "earn $$$", I respectfully write my Email, to send me the price, Because I really need this buffer.

Amir

"about one of my questions "the helper already know the answer.""

Sorry, but you need to read more carefully.

The text you mention said:

In the QEI ISR, the timer value is written to a buffer of 1024 bytes.
When the buffer holds 512 bytes (sector size) or more, one sector of data is written to the USB
drive.

If you write a QEI ISR, then it would be _you_ who knows the name of the buffer _you_ place the values in. And it would be _you_ who knows when you have 512 bytes of data in that buffer, so _you_ would know when you have enough to write one sector to the USB drive.

If _you_ haven't written the QEI ISR, then it would still be _you_ who should locate the source of that ISR and look what buffer the data is stored in.

Do you even know if there exists any QEI ISR?

Thanks
So, I must read the GPDMA session from datasheet. and define a buffer.
i'll working on it. and then ask the questions about it.

Best Regards
Amir

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

Are you sure you are working on this?

I did a very quick browse of the GPDMA information in the processor user manual - it doesn't list the quadrature encoder among supported sources.

Which means you basically got all required information already in Tsuneo's earlier posts, if you had decided to read what he wrote and compare with the capabilities of your processor.

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

"i'll working on it." is different with "i'm working on it"

Because I am working on some thing in Parallel. and as I said before, due to my weak Architecture knowledge, I had no imagination about DMA.
If you did not tell me that DMA must supports the QEI, I would keep on concentrating on it. Because I thought that I can consider the QEITIME register as a part of Memory, and use "Memory-to-memory transfer" feature to buffer Data. but as _you_ said, it is not suitable to use DMA. and I think I should use a vector as buffer.

thanks

"i'll working on it." is different with "i'm working on it"

Correct - "I'll working" isn't a correct sentence.
"I am working" - doing now.
"I have been working" - have already done it
"I will be working" - something happening in the future
"I will work" - something happening in the future
"I am going to be working" - basically just more complicated construct

But that still doesn't change the fact that you - after having received all required information - comes back after a number of days and tells us how disappointed you are that no one is giving you the required answers. And then, when asked about your email address, specifically say you put up the address to let people quote a price to supply you with the information no one can really give you since you first need to write that ISR before it will be known what name you selected for that buffer.

That implies that you haven't been working on the problem, but have instead been assuming someone else should supply you with a solution. Enough so, that you are getting a bit irritated that people haven't stepped in and posted the solution.

The traditional route is that people work first. Then post questions about specific issues when they are stuck. Such a route would have made it obvious to you that you didn't have any open question about any buffer name more than a week ago.

Not only that. You earlier did write "I have written below codes [...]" and posted code containing:

*UserBuffer=LPC_QEI->QEITIME;

So it would then be up to you to know exactly where that "UserBuffer" comes from.

>"i'll working on it." is different with "i'm working on it...."
OK thanks for the grammatical point.

But if you had read the first post:
>can i send data to buffer and send batch buffer to USB? Is it help me Reduce interrupt latancy effects?

and in the 4th post:
>and USBhostlite code is available here: ...and I removed Uart from codes so that it just copies data to usb.

You would have found that I know what the buffer is. but I don't know how to configure it.
UserBuffer is the name used in USBhostlite(Main_Copy). and I choosed it. but I asked several times that:

due to low rate of USB functions, i must buffer data and send them in batch. And in the end, i should reset the timer.
so how can i buffer the data? should i use an auxiliary register?
how can i detect that number of bytes written in QEITIME(or auxilary Buffer) is 512?

Amir

Since you have an interrupt that produces one value at a time, it would be _your_ code that inserts data into the buffer. So it should be easy for _your_ code to know when you have 512 bytes of data.

Interrupt latency? Are you sure you need to worry about any interrupt latency? Exactly what latency are you worrying about? As long as the interrupt reads out data before a new sample is available, you should not have to worry so much about latency.

Next thing: If the quadrature encoder is limited to serving one value/interrupt, then that is a limitation you have to live with. The user manual for the quadrature encoder tells exactly what it can do.

How to buffer data? Like you would buffer any other data. The processor don't care much about the reason why you put data in a buffer. And the USB layer don't care much about what data you have in a buffer when you tell it to send a block of data.

In the end - if you copy an example: Make sure you read through that example enough that you understand what you did copy. That source code would tell you what WriteBuffer points to. And how to access that buffer - or if it is even applicable to make use of that buffer or if you should instead create your own buffer. But the USB layer still don't care much about what specific code did insert data into a buffer. It cares about the transfer requests you specify.

If you modify code, then it will be up to you to figure out if a buffer suddenly becomes unused. Or if an existing buffer can suddenly get a new use because your data collection is just comming from some other source.

>Since you have an interrupt that produces one value at a time, it would be _your_ code that inserts data into the buffer. So it should be easy for _your_ code to know when you have 512 bytes of data.

I don't know reason of _your_ emphasis on _your_.
Any way, when the number of bytes send to the buffer equals to 512, _My_ codes should sets an interrupt. and then it sends the buffer to USB. and then the counter for buffer should reset. I don't care that some counts at this short time lost.

but I have some problem with it that ask you after further works.

Amir

My emphasis _your_ is because people on this forum can't explain code you still haven't written. You must first write it and then post it before anyone can come back with feedback.

Next thing. You don't collect 512 byte of data. Then ask the USB layer to send your data. Then reset your counter and start to collect more data. You need to continue to collect data while you wait for the USB transfer. That is why you need to have two buffers - or a twice as large buffer - so you can capture more data concurrently with the USB transmission.

You helped me a lot Dear Mr Westermark.
I'll have more & more questions after the test.

Thanks alot
Amir