FX3 continuous data reading

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
user_1566431
Level 1
Level 1

Hello! This is my first post though I have had a CYUSB-FX3 kit for a while. I want to be able to read data synchronously and continuously (no flow control) whenever a WR pin is high. I have attached two snapshots of my idea for the GPIF II interface. I know I have to use two threads to avoid delays, but my question is, Can I use autodma to transfer the data to the USB port. Is it possible in this scenario to us "manytoone" or is processor intervention required.

I have read through a number of the appnotes but at present find it all a little unfamiliar. Your advice would be kindly appreciated.

0 Likes
1 Solution

We cannot read the the counter values for DATA, ADDR, and CTL counter in the firmware.

Regards,

Sridhar

View solution in original post

0 Likes
7 Replies
KandlaguntaR_36
Moderator
Moderator
Moderator
25 solutions authored 10 solutions authored 5 solutions authored

Yes, you can go with Auto DMA.

Regards,

Sridhar

0 Likes

Thank you for your response. Can I also use the "ManyToOne"?

Sorry if this seems obvious to you but it isn't to me.

Also does my state machine look reasonable?

0 Likes

Yes. You can use Many to One Auto DMA Channel.

Regarding State Machine:

Your state machine looks like a trimmed version of UVC State machine.

Is the amount of data you write to GPIF II is always a buffer size?

Do not you need to write any size less than buffer size to host at any time?

How do you know that the buffer is always ready?

What if your host is steaming lower than expected.

In this case, your buffer will be full and you will be keep on writing to GPIF II.

In case of UVC, if the host is slow to to stream the data from device, we will look for the Commit Buffer Failure in DMA callback then reset  GPIF II and DMA. This results loosing some video data. In video application, it is okay if there is a loss of data.

But what about your case, what kind of data you are streaming (what is your application)?

Regards,

Sridhar

0 Likes

1. Yes the amount of data written from the GPIF II is always a buffer size. When the write WR is high data is read at the clock speed. Dah, I get it now, the buffer could be under filled when the WR goes low, so I would have to deal with that!

2. I assume that the buffer will always be ready because of the automatic switching of threads and sockets when one gets full. No flow control.

3. Yeah, the Commit Buffer Failure looks like a good idea.

4. I am doing a simple continuous read test, which I will adapt for an ADC. I am building a 16 bit synchronous counter to feed into the GPIF II so that I can look for any missing codes.

I intend to use a bulk endpoint. Is that the best form of communication to use?

Thank you for your very helpful answers.

0 Likes

>> I intend to use a bulk endpoint. Is that the best form of communication to use?

Bulk endpoint is perfect for your application.

0 Likes

I have modified my state machine, I am wondering if you could tell me if it looks reasonable?ModifiedStateMachine.png

Can the CPU access the count in "addr_counter" because I use it to count the total number of samples. Can I send that data as a footer/final header?

I would also like to clear all the buffers on "intr_cpu". How would I do that? Thanks.

0 Likes

We cannot read the the counter values for DATA, ADDR, and CTL counter in the firmware.

Regards,

Sridhar

0 Likes