CFA633 GPIO Questions

EddieShen

New member
Hi there,

I have been creating a C library for the CFA635 and CFA633 commands and have somewhat successful. I have been able to transmit commands and receives acknowledgements / status updates on the majority of the commands. However, when I attempt to adjust/read GPIO bits, I have been quite unsuccessful.

I have been trying to get GPIO[0] to be read and set as an input (read every 32 Hz) on the CFA 633. The symptom of the problem is that I receive no acknowledgement packets back.

I use the same data format that I used for other functions(printing to screen, boot image, etc). Even the example of ensuring that some GPIO bits are set correctly from the PDF don't work for me.
(i.e. command = 34; length = 3; data[0] = 2; data[1] = 0; data[2] = 2 <-- Ensures GPIO[2] operates correctly as ATX POWER)

In my code, when I switch command to 6 and length to 0 for example, the clear Screen command does indeed work (and sends back an ack).

I am running HW: 1.5a and FW:k1.9, which I assume to be the latest and greatest...

What confuses me is that your Wintest seems to be able to retrieve acknowledgements from these commands(34/35) whether they err or not, but my code doesn't seem to, although it works for other commands. I am runnign Fedora right now, but I don't think it would mess up only those two commands while leaving the rest perfectly fine.

Also, could you tell me the aperture size for the sampling of the GPIO bits as inputs?

Please respond as soon as you can. Thanks!
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
 
USB LCD Displays - Graphic and Character LCDs with a Keypad

EddieShen

New member
Got it working

It turns out that I fiddled with some of the sample code before which i assumed was working. Once I put it back to what it was before the GPIO stuff seems to work fine. I still would like to find out the GPIO sampling rate aperture time, however. Thanks =]
 

CF Tech

Administrator
It basically does an "instantaneous" sample, 32 times per second.

Do the smallest pulse it will guarantee to detect is one that is longer than 1/32 of a second.
 

EddieShen

New member
Thanks!

Thanks for the info. However the pulse high width size thatI am trying to capture is 5 ms over a period of 40 ms, which occurs at a higher frequency than 32 Hz. I am curiosu how long this "instantaneous" measurement is. Thanks!
 

EddieShen

New member
All fixed

When I tested to see how fast of a frequency I could use, it seemed to work fine in monitoring rising/falling edges and state up to 3 Mhz... which more than meets what I needed to get done =).

However, I noticed that if I poll the GPIO too often (i.e. twice a second) it doesn't give me the correct values all the time. However if I poll every 3 seconds or so, it seems to do the right thing. Any explanation for this?
I haven't tried polling 4 GPIO's just yet (it will eventually have to do this). In that case would I have to increase my poll time even more?
 

CF Tech

Administrator
I look at the port state 32 times per second. If it is high that instant, I record a high. If it is low that instant, I record a low.

If the signal is changing a lot, you will probably get both low and high transitions recorded.

It becomes a game of chance. If you poll slowly enough, chances are that the module will detect a transition (the short state coincides with one of the 32Hz polls at some point). If you poll quickly, sometimes a the only transitions will happen between polls and be missed.
 
Top