We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi I want to draw graphs of position of 2-phased QEI versus time. so I want to capture QEI position every time period. time gap between to position pulses is at least 7.2 microseconds. I think I have to choose one of these methods:
1-send position to USB during time overflow interrupt(TIM_INT)
2-send content of the timer when the situation changes. (I don't know if it is possible to sense the changes as an interrupt?)
I think there are some restrictions due to interrupt latancy. so what is the highest resolution for my system. and which method is better? How can I define interrupt for 2nd method? can i send data to buffer and send batch buffer to USB? Is it help me Reduce interrupt latancy effects? HOW? Please Help me Best Regards
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.
"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
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.
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