For my project, I'm currently using the FX3 (CYUSB3014) and looked into the SPI GPIO bit banging example as reference for the bit banging approach and given my timing requirements, it seems that we would need a delay less than a microsecond in between bits. From the looks of it, the smallest delay that can be used is with the CyU3PBusyWait (1uS). Is it possible to sample the logic levels of the GPIO pin/s with smaller delays and perform bit banging at a faster rate?
Through FX3 APIs minimum delay that can be provided is 1us (using CyU3PBusyWait as you mentioned). In spigpiomode example of fx3 sdk the clock stays high for around 1us, then sampling happens following clock going low for 1us. So using that example delay between two successive sampling will be around 2us.
We do not have an example firmware with <1us delay between bits sampled.
I saw a related forum here as well: https://community.cypress.com/t5/USB-Superspeed-Peripherals/FX3-GPIO-Clocks/td-p/191417#:~:text=Simp....
It mentioned there that "Simple GPIO use FX3 GPIO clock to sample the pins and hence can operate at maximum 100.08MHz". Based on this forum, I assume that the GPIO status can be sampled at a max rate of 100.08MHz or even 50.04MHz (min. divisor of 2). I was wondering how this would be implemented.
Also, would it be possible to use for loops / other loops to serve as delays aside from the API's?
I tried and the for loops idea for a delay don't seem to be the way to go. Even without delays from API, it doesn't seem to soove the problem either way.
I'm still looking at the forum link I saw regarding GPIOs and also asked here but can't seem to see how it would translate to the code itself since you said that the smallest delay is 1uS (1MHz).
The process I intend to to do is something like this:
1) read gpio pins status
2) nanosecond delay (~tens to hundreds of nS)
3) read gpio pins status
4) nanosecond delay
5) repeat as needed.
Maybe a delay as a function of the FX3 clocks can be used for this? I'm not really sure but I'm trying to exhaust all possibilities to come to a definite conclusion.
Thank you for any assistance you can provide.
Apologies for the delay in response. The SPI pins (53:56) are connected to different part. What I'm using are GPIO pins configured in simple mode.
I'm trying to read digital data from a connected device with timing diagram based below:
My goal is to have the DOUTx data bits be reconstructed on the FX3 end, in sync with the DCLK signal. Due to my assumption of previous limitations, I've been using DCLK levels 1MHz or below. The DOUT pins are connected to GPIOs 48,49,50,51, DRDY on GPIO21 and DCLK on GPIO22.
Here's the snippet of code I made to read from GPIO48 based on the timing diagram above and the bit banging example from FX3 SDK:
Right now, I'm trying to do this for only one channel (from GPIO48) but I'm also looking at the possibility of doing this for all 4 channels (GPIO48 to 51).
I also still want to clarify regarding the forum that I've mentioned in one of my previous comments regarding GPIO's being able to operate at max of 100MHz. Does this mean that GPIO status can be sampled at also around that rate or maybe even 50MHz (assuming divisor of 2)?
From your reply above, we can understand that 4 bits sampling is required. To sample bits parallelly, GPIF interface is recommended. Sampling of parallel bits in GPIO's cannot be synchronized. Maximum frequency supported by GPIF II block is 100MHz, so sampling at this frequency is possible.
So the 100MHz mentioned in the forum is only for GPIF and outside of GPIF I wouldn't be able to do it?
Right now I'm using the gpio register access (not API) to simultaneously get the GPIO status of multiple pins but even with single channel sampling there seems to be problem. Is there a problem with my code snippet (check drdy to go low -> wait until clk goes low -> get gpio48 level and parse -> repeat) ?
As we have understood, your application requires sampling of 4 bit data. Even if GPIO register access is used, 4 GPIO's cannot be synchronized.
So we would recommend you to use GPIF II block for sampling the 4 bits parallelly. We'll be happy to help if you have any queries on this.
Note: GPIF requires minimum of 8 bits for data, so the remaining unused 4 bits can be either pulled up or pulled down and those 4 bits can be discarded in the processing stage.
I'm also interested at finding a solution even for just one channel. I've been trying the code snippet I commented previously to read from just one channel but I'm also having some problem there it seems. I'm not sure if I'm properly detecting the negative edge from DCLK or if the varying logic from GPIO48 (dout) is reflected properly when I read the gpio registers.
Speaking of GPIF, I initially tried creating a new project and from what I see initially, I'm not able to set the corresponding GPIOs (48-51) as my data input line and I'm not sure exactly how to start using the GPIF designer to create a firmware that'll allow me to read data properly.
I appreciate the responses from my inquiry.
Could you let us know exactly what problems are you facing using single channel?
In the code snippet which you had shared,
In this line,
d0 = d0 | (*doutPtr >> 16) << (32-count),
(32-count) has to be replaced by (31-count).
Could you change the dout pins from 48:51 to some other pins that can be used with GPIF?
I'm expecting a constant value to beread from the GPIO48 (I checked from an oscilloscope and the bit stream is fairly constant). Instead of getting a constant code, I'm getting random values. I think it's likely that my code implementation is wrong. I'm reading 32 bits from GPIO48 in sync with a clock (timing diagram on previous comment) and transferring the result via usb using a modified bulkloopmanual firmware. I bit shift and mask every 8 bits in the 32 bit data and send it through USB (data[j] = d0 >> (8*j) & 0xFF where j = 0 to 4)
I'm using an FX3 eval board so yeah i think I can try using the allowed pins. What pins would i use for drdy, dclk, and dout pind for gpif? Are there any example firmware or manual regarding gpif interface I could look at?
Could you share the modified bulkloopmanual firmware being used?
For dclk, pclk(GPIO16) could be used, For 8 bit data(because minimum data bus width for GPIF is 8, 4 bit dout + 4 unused bits) , 8 pins can be selected from GPIO(0:7). Any control pin can be used to configure drdy signal.
Kindly refer to FX3_TRM, FX3_ProgrammersManual, and the gpif2_designer_userguide docs from the doc folder inside the downloaded SDK folder.
Attached here is the modified BulkLoopManual firmware. I modified the DMA callback function to have a provision for reading DOUT (GPIO48) when certain command is received from Control Center.
I also added a clock configuration in the main() to set SysClk = 400MHz, allowing maximum 100MHz operation for Simple GPIOs (https://community.cypress.com/t5/USB-Superspeed-Peripherals/FX3-GPIO-Clocks/m-p/191420#M18985). I assumed that doing this will allow me to sample the GPIO registers status at the said rate so I tried adding it anyways.
I will check the documentations you mentioned in the SDK folder thank you. Is there a way for me to verify if the created firmware with GPIF? i.e., upload via control center and send commands and read data etc.
Thank you for the assistance,
I think I've also tried that and it was indeed working. My problem probably is that i keep getting FF FF FF all the time. Even with a clock source in DRDY, DCLK, and DOUT0 (supply digital signal to input pin instead), the response is always FF FF FF.
Also can you help me understand clearly the forum link I posted on my previous comment? It sayst here that simple GPIo can operate at max of 100MHz. If it means that it can sample the GPIO pin at that rate, howw ould I be able to utilize that? Or is there I'm misunderstanding? Please help me clarify this assumption of mine as well.
We connected GPIO48 to GND, and we got 00 00 00 00 as output(as expected). Could you let us know specifically what input was given at your side, and what was received?
Simple GPIOs can operate at 100MHz and they can be sampled at that rate, but the frequency of sampling is constraint of the code written to read the GPIO's. This is why it was recommended to use GPIF as, GPIF samples data and stores it in the dma buffer.
Also the Simple GPIO clock is internal, but dclk (external clock) is being used in your application. Could you share with us the frequency of dclk being used.
Instead of using "while(*gpPtr & 0x400000)" to wait for the negative edge of the clock, an interrupt can be used for the negative edge of the clock, this is faster that the polling method.
I'm just using square waves from a signal generator as of this moment. I just try to look at the square wave profiles and try to estimate what I'd be expecting to be read.
I see. If the data is sampled through GPIF and is stored in a dma buffer, would the data be accessible and can be sent over USB similsr to the firmware I sent you? From what I remember in the firmware, the identification of usb command starts with looking at the buffer received and if I'm not mistaken, the firmware example for bulkloopmanual (basis of modified firmware) stores received and sent data in the dma buffer so I initially thought there might be problems.
I'm trying to use DCLK of at least 1.5MHz.
I think i previously tried interrupt based gpios but depending on the speed I think there were times when when I try to send command from control center and don't receive a response (error code 997) and i think it has to do with the speed at which the gpio pin is interrupt so it seemed to be limiting at the time. Also I'm not well versed in using interrupts so I'm not familiar with how to build firmware around or involving interrupts.