I have a GPIO signal coming from PL to PS and want to change the LO based on this value. How can i change the LO using the drivers already implemented? I would like to add this to my c code which is monitoring my GPIO.
Unfortunately this pic code is not available to be shared.
Maybe what you can do is use XP1 by reconnecting it to the SPI bus you want to control.
It's not going to be easy but doable.
To change the LO frequency, you can call XCOMM_SetRxFrequency() and XCOMM_SetTxFrequency() functions.
What includes will I need to add to my c file?
The build we are using is pulled from:
<git://git.xilinx.com/u-boot-xlnx.git> Checking out: xcomm_zynq, Using: zynq_xcomm_adv7511_defconfig
Linux File Structure:
Sorry for somewhat simple questions, I'm a firmware guy learning linux and software.
I thought that you are using the no-OS driver...sorry. If you want to change the LO frequency from Linux, you can write the desired frequency value to /sys/bus/iio/devices/adf4351-rx-lpc/out_altvoltage0_frequency for RX or to /sys/bus/iio/devices/adf4351-tx-lpc/out_altvoltage0_frequency for TX. For more information take a look over the ADF4350 driver description: http://wiki.analog.com/resources/tools-software/linux-drivers/iio-pll/adf4350#hardware_configuration
I suggest you, before compiling your own kernel and creating a new SD card image, to also play with our image: https://wiki.analog.com/resources/tools-software/linux-software/zynq_images
Thanks Dragos, We ended up writing directly to these files in our software to implement the frequency change - works great.
Turns out using fopen and and write to the IIO files is taking too long to switch frequency. Currently we have a gpio bit from the pl that is monitored in a while loop in software, if the gpio goes from 0 to 1 the software writes the new frequency to the lo iio file. However it is taking upwards of 3ms from the pl trigger to the actual frequency change. Is there a way to get the lo to change frequency quicker?
I would try to further trace where time is lost.
Trigger another GPIO from the kernel driver when ADF4351 register 0 is written - also probe the SPI pins to the ADF4351. My guess is that the I2C to SPI bridge on the FMCOMMS1 causes the major delay.
There might also be a few us PLL lock time involved.
We probed further and it appears that the time from our write to the iio file to the spi transfer (spi clock) is were the delay is ( we believe to be the iio driver and the IIC to spi bridge). We are at the point of lifting pins on the adf4351 part to drive spi externally from the fpga but would like to do this as a last resort. Do you have any recommendations? I believe I saw the PIC source code is closed source.
Retrieving data ...