Is there an easy way to disable the AUXADC, AUXDACx and GPO in your No_OS driver? We have nothing connected to those output/inputs on the AD9361?
- To disable AUXADC:
ad9361_spi_write (ad9361_phy->spi, REG_AUXADC_CONFIG, AUXADC_POWER_DOWN);- The AUXDAC is disabled by default (it can be enabled from the initialization structure by setting the aux_dac1_default_value_mV);- GPOs pins can be or low, or high, not tri-state.
Also no external LNA
Supplied drivers will not have the functionality to control every aspect of the chip. I am going to move this post to NO-OS driver section for an answer for this specific case. Document UG-671 can be helpful in determining how to go about controlling chip functions not covered by the drivers.
Moved to Microcontrollers no-OS Drivers section.
In the ad9361 driver the gpio perform the reset. Not true in all designs like mine. Dragos, could you look at my other driver discussions. They too are attempting to be hardware agnostic.
Are your the author of the driver. I believe your email address is in the source?
The reset can be hardware (using the RESETB input pin - all SPI registers are reset to default settings and the device is placed in SLEEP mode) or software (setting a SPI register - register values are reset to their default states with the exception of REG_SPI_CONF, REG_CLOCK_ENABLE and REG_BBPLL).
If you set default_init_param.gpio_resetb = -1, just the software reset will be performed.
There is no such thing as Software Reset. The only way to ensure proper initialization of the part is by asserting the RESET pin.
Performing a hardware reset (asserting the reset pin with a GPIO after the power has been applied) is a requirement for proper operation.It's not optional.
I can assert RESET just do not have it connect to GPIO
Just for clarification for other people reading this in the future, the AD9361 pin K5 (RESETB) must be connected to a GPIO on your MCU/CPU/FPGA.
The AD9361 Reference Manual (UG-570), Rev 0, (March 2014) states:
The RESETB line should be held low for at least 1 μs, and the device should not be programmed for at least 1 μs after the RESETB line has been taken back high.
The assumption that this is after all the power supplies have been brought up and are stable. Then bring the RESETB line down for at least 1us, and then high, wait at least 1us, and then programming can start. The AD9361 driver ADI created and maintains assumes that this GPIO can be driven from it's interface (the CPU that the driver is running on, controls the GPIO attached to AD9361.K5)
Of course it can be done other ways, but the above timing requirements needs to be met in all situations. (And we do it in the driver).
Your driver does a software reset in the init rouine write to reg 0 I think I'll look
As Robin said: performing a hardware reset (asserting the reset pin with a GPIO after the power has been applied) is a requirement for proper operation. You can ignore that software reset.
I can assert RESET with a pin on my design. The RESET pin is just not connected to the ad9361 GPIO pin.
I don't understand which one is the AD9361 GPIO pin. As far as I know AD9361 doesn't have any GPIO pin - there are just 4 GPO pins that can serve as general-purpose logic outputs.
However, the AD9361 RESETB pin should be connected to your processor and not to these GPO pins.
Now I understand. The GPIO init - direction routine in main.c is not referring to the ad9361 (that we have noting attached) but to a general purpose processor. We have RESET connected via a processing element. So we are good.
This is correct.
The following routines go away
and the following substitution applies
ad9361_reset(struct ad9361_rf_phy) // Toggle AD9361 pin K5 (hardware dependent)
You don't have to change anything: ad9361_reset() is called by ad9361_init(). Just implement gpio_set_value() according to your platform.
Retrieving data ...