Add support for AD7616

[pamolloy]

Add support for the serial interface to the AD7616 using the STM32 HAL directly (as opposed to Mbed).

Tasks

• [x] If not already setup, setup hardware for testing
• [ ] Create page on ADI wiki

Dependencies

• adi-ses/sea-misc/issues/6
• adi-ses/sea-misc/issues/8
• adi-ses/sea-misc/issues/9
• adi-ses/sea-misc/issues/11

[Skallwar]

Status update:

• We are waiting for a JTAG probe to flash SDP-K1 with the STM32 HAL
• I used this document shared by @mike-bradley to connect to the K1 using flywire. Looking at K1 datasheet however, it looks like some of the pins are not connected to the MCU. I came up with an alternative pin connection (test needs to be done before editing the wiki)
• No-os driver makes use of spi engine. Some heavy rework will need to be done to make it work without. Should we discus No-os driver portability?

[mike-bradley]

Just to clarify and apologies for any confusion - The Digital Control table in the document lists the AD7616 schematic pin name and the EVB SDP-120 way pin, they're not the SDP-k1 SDP-120 way pin numbers, so no expectation for 1:1 mapping.

[Skallwar]

Ah thanks I understand

[Skallwar]

At the moment I'm trying to drive the RESET signal via a GPIO on the K1 but after trying to setup a pull up from STM32CubeMx, the signal is still at 0V

[Skallwar]

The issue with GPIO is now fixed

[Skallwar]

Self test and CRC check are working.

One note regarding the ad7616_read_data_serial: the type of buf is uint32_t * which does not help to understand how the data is encoded. I propose to introduce a new type struct ad7616_conversion_result with 2 uint16_t to help the final user of the no-os driver to get result back without having to do bitwise operation, reducing the complexity. Let me know what you think

[mike-bradley]

I think I follow this query, but not got the code here to check. Do we really need a new type, or could we not change the data type returned by the function (what else is using it?) or instead type cast the buffer returned to a array of uint16_t before passing on elsewhere?
I think this part has serial and parallel read functions (though we're only doing serial with SDP-k1) so is the idea here to keep those functions' signatures the same?

[Skallwar]

or could we not change the data type returned by the function (what else is using it?)

The returned type is an int to be able to say if the call was successful or not (and if the data is usable).

instead type cast the buffer returned to a array of uint16_t before passing on elsewhere

Could be a solution along with better documentation about the order the data is returned. But casting from uint32_t to uint16_t might create issue for byte ordering depending on the architecture. Replacing the type from uint32_t * to uint16_t * in the function signature would be a better on this side and for the end user IMAO.

I think this part has serial and parallel read functions (though we're only doing serial with SDP-k1) so is the idea here to keep those functions' signatures the same?

I would convert theses to whatever we decide to do on the SPI side. But that would mean testing it again to make sure nothing broke.

[mike-bradley]

or could we not change the data type returned by the function (what else is using it?) The returned type is an int to be able to say if the call was successful or not (and if the data is usable). I was suggesting the type of the data buffer passed by ref change, not the function return value that is used for error checking.

Changing the declaration for other functions (e.g. parallel read) could require changes to the No-OS ad7616_sdz project, so they'd have to considered and potentially handled.

[mike-bradley]

In response to the comments in the AD7616 interfacing PDF...

1

Status, CRC could be stored in the device structure. This is what I do at the moment. I there a reason to know if we are in self test mode? I did not find change of behavior between a self-test conversion and a "standard" one I don't think the user would need to provide the CRC or status on/off to this function as input parameters, those would be taken from the device config struct if needs be. The self test function would 'know' it's self testing, and look after device configuration and readback/checking itself, the read data command shouldn't need to take that as an input parameter I think.

2

Even if CRC is enable, I'm not sure giving the CRC word to the end user is useful. At the moment I'm doing the CRC check in the function and returns with an error if the CRC is not correct. What would be a usecase for reading the previous channel index? Agree that returning the CRC to the calling function is not useful, instead the function should an appropriate error code: -EBADMSG ?) to indicate a bad CRC was detected. Not clear to me the purpose of the channel index of the previous conversion even means, the user should know what channels are in the output. The previous channel index is part of the status register read out with the CRC but it doesn't seem very useful. I'd suggest just leaving it out of the output parameter list.

3

I agree, CRC should be enable via an init parameter All good here.

4

This should be public IMAO. The user should set if he want to use the CRC at init If this function is public, then the user can change the CRC at any time after power-up if they want. I'd be inclined to not expose this function in the header for now as part of the ad7616 public api, and just use at init time.

5

Private is perfect All good here.

6

I suggest this one to be private too. We should call it at the end init to make sure everything is working. Running a self test periodically in an application, or 'as needed' by the higher level application could be a useful diagnostic that the converter is presenting and working (to a degree). I'd suggest making this public in the header.

[Skallwar]

Thanks for your feedback!

For number 4, I was missing a negation, so I do agree with you

Noted for 6

[pamolloy]

This part is being supported in no-OS