EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: super7800 on June 02, 2023, 10:43:27 pm
-
Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/AD7771.pdf (https://www.analog.com/media/en/technical-documentation/data-sheets/AD7771.pdf)
Timing found on page 57/58
So i'm trying to interface a SAMD21G18A running an Arduino bootloader with the parallel interface of the AD7771A. There are 6 pins coming from the ADC, four are parallel data, a clock output, and a ready signal. Basically all the makings of a QSPI interface with ADC-as-master.
My first thought was interrupts (basically bit-banging the interface), but that is proving very unreliable. I am wondering how the "correct" way of doing this is? would it be using a QSPI interface? (ideally not as this is a custom board already sitting before me, and the SAMD21 doesn't support QSPI).
I can get the data directly from the SPI interface aswell but that is not ideal. Ideally the data is received as fast as possible (not in samples/s but in processor cycles) so the processor can tend to its main task. Is using a QSPI interface a way to achieve this, the only way, the correct way? alternatives?
-
What is your MCLK/DCLK?
Without looking into the details of the SPI protocol, I would guess that hardware SPI would be faster than software bit-banging. Especially given that you can do SPI using DMA or interrupts, leaving time for other things to run.
-
Can it make dma transfers using a Timer?
If so, you could set up a PWM timer at 50% duty, inverted mode (Output low while active) acting as the master clock.
Then setup a second PWM channel in the same timer with no output, set at slighly larger duty cycle (ex. 55%) duty (So it triggers slightly after the first PWM rised, to let the new data signal stabilize), which trigger the DMA.
-
This is way too complicated, just use DMA with a regular SPI mode.
-
Ah, it's much easier, the clock comes from the ADC!
Then use the external interrupt controller, generating an event that triggers dma transfer from the GPIO to a circular buffer
It's 32bit per sample (24+8) and SPI Fmax is 30MHz, so with it you can still get ~937KSps, close to the ADC limit.
-
I'm using it successfully with STM32 SAI peripheral, you need some model with two instances but they can be cascaded and it works seamlessly
I do not know if you need Atmel's processor or if they have this peripheral available, but on STM it is easy
-
The ADC seems to support a normal SPI mode too. That is definitely easier on the µC side than trying some QSPI in software.
-
The ADC seems to support a normal SPI mode too. That is definitely easier on the µC side than trying some QSPI in software.
But it significantly limits the sample rate
It might be a problem for some projects
-
Define "significantly".
Max ADC sample rate is 8ch*128KSps = 1024KSps
Taking SPI limit from datasheet (30MHz), achievable rate is 937KSps.
If you slighly overclock SPI to 33MHz (10% faster) then it'll reach full bandwidth.
-
Keep in mind that SAM D21 SPI will not work that fast. So again, the approach depends on the sample rate and the amount of data that need to be captured at once. Without hardware way to capture that, capturing full speed 4-bit stream in the firmware may be challenging too. And doing DMA tricks to capture GPIO values may work, but there may not be a point in going too fast, SRAM will just fill and CPU may not be able to handle the data.
-
Keep in mind that SAM D21 SPI will not work that fast. So again, the approach depends on the sample rate and the amount of data that need to be captured at once. Without hardware way to capture that, capturing full speed 4-bit stream in the firmware may be challenging too. And doing DMA tricks to capture GPIO values may work, but there may not be a point in going too fast, SRAM will just fill and CPU may not be able to handle the data.
I've never used the samd21, but afaict from the datasheet it can run spi slave at 1xAPB bus speed, max 48Mhz
-
I've never used the samd21, but afaict from the datasheet it can run spi slave at 1xAPB bus speed, max 48Mhz
No, it can't do that. Max clock setting is 24 MHz, but if you look in the electrical specs, pad bandwidth would limit it to 12-16 MHz. Pad bandwidth can be ignored in some cases, especially for hobby stuff, but the maximum clock is fixed.
-
I've never used the samd21, but afaict from the datasheet it can run spi slave at 1xAPB bus speed, max 48Mhz
No, it can't do that. Max clock setting is 24 MHz, but if you look in the electrical specs, pad bandwidth would limit it to 12-16 MHz. Pad bandwidth can be ignored in some cases, especially for hobby stuff, but the maximum clock is fixed.
I'll take your word for it, but I don't see it in the datasheet, https://ww1.microchip.com/downloads/en/DeviceDoc/SAM_D21_DA1_Family_DataSheet_DS40001882F.pdf
table 37-7 and table 37-67
-
table 37-7 and table 37-67
Those are maximum clock frequencies that can be supplied to the peripheral input, this does not say anything about the performance of a specific peripheral.
Table 25-2. "Baud Rate Equations" - f_baud = f_ref / (2*(BAUD+1)), where BAUD is the register setting. If you set 0, then you get f_baud = f_ref / 2 = 48/2 = 24 MHz.
And Table 37-67. "SPI Timing Characteristics and Requirements" shows SCK period of 84 ns, so maximum frequency is 1/84e-9 = ~12 MHz.
-
table 37-7 and table 37-67
Those are maximum clock frequencies that can be supplied to the peripheral input, this does not say anything about the performance of a specific peripheral.
Table 25-2. "Baud Rate Equations" - f_baud = f_ref / (2*(BAUD+1)), where BAUD is the register setting. If you set 0, then you get f_baud = f_ref / 2 = 48/2 = 24 MHz.
And Table 37-67. "SPI Timing Characteristics and Requirements" shows SCK period of 84 ns, so maximum frequency is 1/84e-9 = ~12 MHz.
that's for master mode, wasn't there a way for the ADC to be master?
-
that's for master mode, wasn't there a way for the ADC to be master?
Not in SPI mode.
But also, the same pad limitations apply to the slave mode. The table says that it can go up to APB clock, but in practice making it work reliably at that clock is going to be next to impossible.
-
If you want to read data from AD7771 by config SPI, there is only debug read and it can read a value just from a single channel, you need to set the desired channel and do a conversion and then read data. It will be very slow.
Output can be configured as SPI master, but it is synchronous with the sampling clock, and over the single line you are limited to 1/4 of the max sample rate. You need to increase oversample or discard data from other channels.
-
Once again, it all boils down to OP's sample frequency and sample duration requirements. The optimal approach would vary quite a bit based on that. Cortex-M0+ is not the power house of signal processing, you you have to be ready for things to be slow, even if you capture at a fast rate.
-
The device doesn't do anything with the data. It will record it for 30seconds to at most 2 minutes, then stream to PC
STM32 is an option, but id hate to have to order another board, as these are "special" boards that require fairly expensive processes due to their very small size (via-in-pad etc.) I will be ordering a new board, as i messed up somewhere else on the PCB anyways thats non-fixable without a revision (DOH!)
The SPI bus is very much non-ideal solution, as there is another, more important DUT on a (separate) SPI interface, and I would get very poor ADC sample rate due to that. Perhaps a multi-mcu solution may be needed (add a dedicated MCU for ADC buffer) (hopefully, very hopefully, not though).
Ah, it's much easier, the clock comes from the ADC!
Then use the external interrupt controller, generating an event that triggers dma transfer from the GPIO to a circular buffer
It's 32bit per sample (24+8) and SPI Fmax is 30MHz, so with it you can still get ~937KSps, close to the ADC limit.
@DavidAlfa definitely something to look into. i was already trying to do something similar with interrupts, but not using DMA. Ill try that and see if it works. I am very much not well-versed in the more advanced MCU functions though. This seems to show some good examples https://github.com/manitou48/ZERO
-
A powerful device to implement high bandwidth/non-standard IO interfaces is a zynq MCU with FPGA fabric. I have seen a zynq in our Rigol scope. It's already the second question of this kind i have seen in this forum today.
Recently i spent an hour or so on whether one can make a realtime emulator for a 2 MHz 65SC02 on a STM32L433. Basically at 80 Mhz it should be possible. So i configured the MCU with a PWM counter to output the 2 MHz clock. Then i used an interrupt to generate the 6502 Synq signal. Probably the highest interrupt rate i was ever using on any MCU. It worked well but then i remembered that i wanted to run a USB stack on my MCU and put this aside. Such projects involve some kind of FPGA. The MCU is the wrong tool.
Regards, Dieter
-
The device doesn't do anything with the data. It will record it for 30seconds to at most 2 minutes, then stream to PC
This device has 32 Kb of SRAM. Where are you going to store 2 minutes, or even 30 seconds of data sampled at high rate?
and I would get very poor ADC sample rate due to that.
Why? Interrupt driven SPI takes almost no resources.
-
A powerful device to implement high bandwidth/non-standard IO interfaces is a zynq MCU with FPGA fabric.
So, you are suggesting to move from a $5 MCU to $70 FPGA requiring BGA process to sample some low speed ADC?
-
Using an FPGA does not imply high cost. Its flexibility may save a lot of trouble, like board revisions. Appearently the OP has a problem there, too. And as you wrote, it won't be a $5 MCU anyway, due to record size.
It seems to be difficult to do it on a MCU, i mean selecting a MCU with the proper peripheral. If i hear that somebody found a trick using two instances of an SAI peripheral, that's also nothing to recommend.
Implementing a peripheral by bit-banging isn't always possible. That's why we have this thread.
Regards, Dieter
-
SAI peripheral in STM32 looks to be designed in a way that allows paralleling to get a wider interface, so I won't call it a trick, just using the resources
And you can run on a single instance (two-bit wide) at half the sample rate
We did consider using a small FPGA to do protocol translation to something easier to manage.
But a single-chip solution is always easier to work with and there is no cheap mid-size Cortex M4 or M7 with a small FPGA of just a few hundred cells.
-
SAI peripheral in STM32 looks to be designed in a way that allows paralleling to get a wider interface, so I won't call it a trick, just using the resources
And you can run on a single instance (two-bit wide) at half the sample rate
We did consider using a small FPGA to do protocol translation to something easier to manage.
But a single-chip solution is always easier to work with and there is no cheap mid-size Cortex M4 or M7 with a small FPGA of just a few hundred cells.
will and M3 do? https://wiki.sipeed.com/hardware/en/tang/Tang-Nano-4K/Nano-4K.html
-
That ADC requires some bandwidth. At full data rate it produces 24 MBit/sec, something that doesn't even stream over many built-in USB peripherals. And if you want a two second record, there will probably be external RAM and a pretty complex project to achieve the bandwidth to memory, from memory and to the host. The evaluation kit does not support streaming.
A 5$ solution for streaming may be a FT2232H in parallel FIFO mode. The FT2232H will do high speed USB up to 40 MByte/sec, more than enough. It has internal 4 KByte FIFO size.
Regards, Dieter
-
so this was originally supposed to be a quick one-off (well, maybe a 10 off at most lol), but it looks like it may be a more advanced project. Cost of MCU is nonissue.
The idea is to store data onto an internal microSD card (over SPI), then when the test is done stream the data to the PC.
So I really don't want to involve the complexities of designing a proper high-performance single-chip solution (i.e. a FPGA with an ARM core). If performance is hurt by this so be it.
"bit-banging" the interface using interrupts doesn't seem to be a viable solution (at least I couldn't get it working reliably). I'm now starting to think that a two-chip solution may be the best bet, or just try moving to an STM32.
The SAMD51 has a QSPI interface which may be another option with ADC-as-master. SAMD51 is master only
@Miyuki would you be able to elaborate on how you connected/interfaced the STM32 to the AD777x? I have never used the STM32 or SAI peripherals before, but that does seem promising. There seems to be some example code for the STM32, but it doesn't use the SAI interface.
Attached is a diagram of the system as-is and as-proposed. Will give a better picture of what the design looks like.
-
You still have not mentioned your desired sampling frequencies, and this is the critical part that would define the design.
SAM D51 QSPI is a master-only.
-
@ataradov ideally I would get the full 128ks that the ADC is capable of. However, I can slow the DUT down and can live with a lower sample rate. This is very much non-ideal.
-
@ataradov ideally I would get the full 128ks that the ADC is capable of. However, I can slow the DUT down and can live with a lower sample rate. This is very much non-ideal.
how many SPIs can you spare and how many channels do you need?
I think you could do 4*64ksps with two slave SPI in parallel
-
@ataradov ideally I would get the full 128ks that the ADC is capable of. However, I can slow the DUT down and can live with a lower sample rate. This is very much non-ideal.
This would require is 3 MB/second, even if you could receive the data.
The best approach with MCUs I see here is to just use multiple SPI interfaces in parallel . They don't need to have any special internal connections, they will just each handle their own line and share the clock. They would place the data into their own linear buffers, so some bit shuffling would be required, but it should not be too hard.
The hardest part here is to actually get the DRDY bit and start reception in time. I'm not even sure it is possible at that rate.
This output format is really not designed to be read by the general purpose MCUs.
-
Recently we got a WEACT STM32H750 module from digikey and it included an OV2640 camera. Until now i did not look into this, but i guess there is a DVI input peripheral that can be used to pass the ADC data into MCU RAM using DMA. The ADC output signal DRDY would be a fifth data bit so the firmware can later partition the data.
I just looked into the reference manual. They call it DCMI and it includes a HSYNC input that one can use for syncronization.
Regards, Dieter
-
Yes, MCU with a parallel capture interface may work. But you also need to check the specs, since some of them will not capture arbitrary data without correct HSYNC/VSYNC signals and may include blanking periods.
The most universal parallel capture interface I know of is present in Atmel SAM E70/V7x MCUs. It is just 8-bits, external clock and enable signals that may be permanently enabled. I easily captured 50 MHz stream using it.
-
@ataradov interesting peripheral. it does have a QSPI peripheral, so I should be able to take data from the ADC and stream it there (to an onboard QSPI chip) until the PC wants it. Or i could use its HSMCI peripheral. It is a bigger IC than what I had before. It will physically fit, but the board will have to be redesigned for 6 layers, which is no big deal. bought a demo board to play with. ATSAMV71XULT.
i will have to think more on using an FPGA. Im most familiar with Xilinx, but all their new ones are BGA, which is a pain to solder, but doable.
Xilinx was bought by AMD? when did this happen lol?
https://www.digikey.com/en/products/detail/microchip-technology/ATSAME70N19A-AN/5235879 (https://www.digikey.com/en/products/detail/microchip-technology/ATSAME70N19A-AN/5235879)
-
it does have a QSPI peripheral, so I should be able to take data from the ADC
Writing to QSPI memory may be slow. If you replace it with QSPI SRAM, it may work, but still may be tight.
In my case I transferred the 50 MHz stream into the USB and let host PC deal with it.
But it also has quite a lot of internal SRAM too.
-
So i ended up moving to a 2 board solution. I'm (planning on) using a SAMD51 which has a SD host controller (SDHC) and a PCC interface (for the ADC). I'm considerably more well-versed in the samd21 and 51 then the SAM E70/V7x, however if this doesn't give me the performance i need ill end up making the switch. The chip was also physically smaller. I've never used DMA or PCC, so this will be "interesting".