ad400x: Support for pulsar HDL and STM32

[ahaslam2]

Pull Request Description

This PR adds:

• support for stm32 with IIO
• changes for new HDL that contains:
  • fixes for simple spi,
  • pwm
  • clkgen

HDL is not merged yet on main repo, but code was tested with:
https://github.com/adi-ses/sea-misc/tree/main/AD4000-PRJ/debug_single_conversion

PR Type

• Bug fix (change that fixes an issue)
• New feature (change that adds new functionality)
• Breaking change (has dependencies in other repos or will cause CI to fail)

PR Checklist

• I have followed the Coding style guidelines
• I have performed a self-review of the changes
• I have commented my code, at least hard-to-understand parts
• I have build all projects affected by the changes in this PR
• I have tested in hardware affected projects, at the relevant boards
• I have signed off all commits from this PR
• I have updated the documentation (wiki pages, ReadMe etc), if applies

[rbolboac]

I still have to think a little bit about the spi chip select changes you have submitted, until then here are my remarks.

[ahaslam2]

I still have to think a little bit about the spi chip select changes you have submitted, until then here are my remarks.

There is onother option with these chips is leave the CS go low, but this would require SDI to be high.
this could be done by setting buf=0xFFFFFFFF before the spi operation.

[ahaslam2]

changes in v2:

voltage ref patch squashed into iio/project patches.
changed licence agreement text in iio driver
expanded iio scan type table, and removed global scan_type variable
fixed scale factor
removed alloc from capture loop, used single 32 bit variable
add driver remove on iio remove
other minor fixes.

[rbolboac]

I still have to think a little bit about the spi chip select changes you have submitted, until then here are my remarks.

There is onother option with these chips is leave the CS go low, but this would require SDI to be high. this could be done by setting buf=0xFFFFFFFF before the spi operation.

So please correct me if I am wrong: all you actually need for this driver is to have chip-select active high instead of active low, is that right?
If this is the case, I think it would be better to have an cs_active_high flag in the spi driver. the chip select is actual part of the SPI protocol and I find strange to make it optional in a spi driver. however, I think there are cases in which the polarity is inverted... this would ma a more acceptable approach.

[ahaslam2]

I still have to think a little bit about the spi chip select changes you have submitted, until then here are my remarks.

There is onother option with these chips is leave the CS go low, but this would require SDI to be high. this could be done by setting buf=0xFFFFFFFF before the spi operation.

So please correct me if I am wrong: all you actually need for this driver is to have chip-select active high instead of active low, is that right? If this is the case, I think it would be better to have an cs_active_high flag in the spi driver. the chip select is actual part of the SPI protocol and I find strange to make it optional in a spi driver. however, I think there are cases in which the polarity is inverted... this would ma a more acceptable approach.

this is not exactly right,he chip does not have a CS pin. its a conversion pin.

the issue with just inverting the polarity of the CS pin on the spi driver, is that
in fact to read/write the control register the CNV pin has to be low :(
(just realized need to add a toggle in register read/write too)

if you want to avoid handling the gpio on the driver:
the other option: setting buf to 0xFFFFFFFFF so SDI is high would allow
for CS pin to be low and read samples. the issue with this is that
the conversion starts on a rising edge of CNV, so if i read 1 sample for example: the sample
would be from past: from when the last SPI read finished and CS toggled from low to high.
would this be acceptable?

the above is what i see on the datasheet and from experiments:
https://www.analog.com/media/en/technical-documentation/data-sheets/ad4000-4004-4008.pdf

[ahaslam2]

changes v4:

• toggle cnv gpio on register read/write
• remove ref_voltage from driver init param
• extend sign in case of signed channel

[rbolboac]

I still have to think a little bit about the spi chip select changes you have submitted, until then here are my remarks.

There is onother option with these chips is leave the CS go low, but this would require SDI to be high. this could be done by setting buf=0xFFFFFFFF before the spi operation.

So please correct me if I am wrong: all you actually need for this driver is to have chip-select active high instead of active low, is that right? If this is the case, I think it would be better to have an cs_active_high flag in the spi driver. the chip select is actual part of the SPI protocol and I find strange to make it optional in a spi driver. however, I think there are cases in which the polarity is inverted... this would ma a more acceptable approach.

this is not exactly right,he chip does not have a CS pin. its a conversion pin.

the issue with just inverting the polarity of the CS pin on the spi driver, is that in fact to read/write the control register the CNV pin has to be low :( (just realized need to add a toggle in register read/write too)

if you want to avoid handling the gpio on the driver: the other option: setting buf to 0xFFFFFFFFF so SDI is high would allow for CS pin to be low and read samples. the issue with this is that the conversion starts on a rising edge of CNV, so if i read 1 sample for example: the sample would be from past: from when the last SPI read finished and CS toggled from low to high. would this be acceptable?

the above is what i see on the datasheet and from experiments: https://www.analog.com/media/en/technical-documentation/data-sheets/ad4000-4004-4008.pdf

So we would like to avoid changing the SPI driver like that (seeing how for other platforms we will have to adapt this kind of behavior and it might not be possible to not have a chip select configured)... A workaround would be to simply have a dummy chip select in the project (which will not be connected to the chip) and then gpio_cnv pin can be used however is needed directly in the driver.

[ahaslam2]

I still have to think a little bit about the spi chip select changes you have submitted, until then here are my remarks.

There is onother option with these chips is leave the CS go low, but this would require SDI to be high. this could be done by setting buf=0xFFFFFFFF before the spi operation.

So please correct me if I am wrong: all you actually need for this driver is to have chip-select active high instead of active low, is that right? If this is the case, I think it would be better to have an cs_active_high flag in the spi driver. the chip select is actual part of the SPI protocol and I find strange to make it optional in a spi driver. however, I think there are cases in which the polarity is inverted... this would ma a more acceptable approach.

this is not exactly right,he chip does not have a CS pin. its a conversion pin.
the issue with just inverting the polarity of the CS pin on the spi driver, is that in fact to read/write the control register the CNV pin has to be low :( (just realized need to add a toggle in register read/write too)
if you want to avoid handling the gpio on the driver: the other option: setting buf to 0xFFFFFFFFF so SDI is high would allow for CS pin to be low and read samples. the issue with this is that the conversion starts on a rising edge of CNV, so if i read 1 sample for example: the sample would be from past: from when the last SPI read finished and CS toggled from low to high. would this be acceptable?
the above is what i see on the datasheet and from experiments: https://www.analog.com/media/en/technical-documentation/data-sheets/ad4000-4004-4008.pdf

So we would like to avoid changing the SPI driver like that (seeing how for other platforms we will have to adapt this kind of behavior and it might not be possible to not have a chip select configured)... A workaround would be to simply have a dummy chip select in the project (which will not be connected to the chip) and then gpio_cnv pin can be used however is needed directly in the driver.

ok, ill do that.

[rbolboac]

overall looks good

commit: e5210d3 has a typo add add a device
commit: 3b83e8f has a typo usies
also, I see all commits have really short lines for the commit message, you can have up to 72-characters per line for the commit description

[rbolboac]

remove extra lines

[ahaslam2]

this extra line is not part of the latest push.

[rbolboac]

it is part of this commit: 5e09916
in general, in the same PR, we avoid fixing a problem we introduced with a later commit, rather we remove it in the commit it was introduced by rebasing.
this makes the review process easier, commit by commit

[ahaslam2]

ok, ill fix it there.

[ahaslam2]

Change log:

• fix 2 commit message typos.
• use 72 line indent for commit message.

[ahaslam2]

changelog:

• fixed white line in iio driver patch.

[rbolboac]

seeing how there is no ad400x driver documentation, do you plan on adding that here?

[ahaslam2]

seeing how there is no ad400x driver documentation, do you plan on adding that here?

I added the driver README.