Data capture on GPIO



Hi I am Vybhav and i am new to Dragonboard 410C.
Part of my project is tho interface ADC to 410C and capture the data . Details about the algorithm used to capture data is mentioned below.

ADC generates chip select(frequency ranging between 10KHz to 375KHz and it is active low ),Clock (frequency ranging from 750khz to 24MHz) and data of 24bits.
The data is captured at every negative edge of the clock and when the Chip select is low . Can anyone tell is the possible on the GPIO’s of the dragonboard 410C

Help is appreciated

Thank you

Data capture on the GPIO-With timing diagram
Data capture on the GPIO

Hi ,i am Vybhav and i am new to DragonBoard 410C.
Part of my project is to capture data from the ADC(details mentioned below):
The ADC generates chip select(active low signal of frequency ranging from 250 KHz to 375KHz),clock(6 to 24MHz) and 24bit data.
My aim is to interface these signals to GPIO of 410C and capture data at the falling edge of the Clock when the chip select is low .

can anyone please throw some light on this . if this information is not sufficient please let me know .
Help is appreciated

Thank You


This sounds like SPI but could you share part number (and maybe also a link to the datasheet) rather than protocol?


Hi , this data sheetshows two SPI buses ,can you confirm whether both the SPI buses function on 410C?

If i have two SPI buses ,i can use one of it for ADC configuration to master or slave mode(Register read/write) and the second SPI bus for data capture .



He means the datasheet for your ADC.


I get that ,but the the ADC I am working with is in design stage and not out in the market yet ,so due to confidentiality clause I cannot share the data sheet.


Hi @Vybhav_Jayaraman.

The 410 does have multiple SPI ports, each BLSP can be configured as either GPIO, SPI, or an I2C port. All SPI ports on the 410 operate as Master only, none of the SPI ports can operate as Slave. Some of the SPI ports have multiple hardware chip selects and can access multiple multiple devices, or multiple virtual devices inside a single physical device, and all of the ports could have multiple software chip selects (using GPIOs as chip selects).

For a single SPI device (ADC on your case) you rarely need two SPI busses, however you do need multiple chip selects on the SPI bus. one chip select selects data transmission mode, and the other chip select selects register read/write mode.

SPI is a 4 wire interface with transmit and receive data, clock and chip select. The Master always drives the chip select, and usually drives the clock, the polarity of the clock (active rising edge, or active falling edge) is programmable on the 410, and is often programmable on SPI devices. The transition of the chip select initiates each transaction, and the active edge of the chip select (rising or falling) is programmable. Data flows in both directions during each transaction, although SPI devices may ignore one of the data flow directions depending on the transaction.

Be careful with your definition of Master and Slave on the SPI bus, just because the ADC is generating the data doesn’t necessarily make it the Master.

I of course have not seen the data sheet for your SPI device so I cannot comment on it’s design, but it unusual for a ADC to be a SPI master. The host (in this case the 410) is usually the master to an ADC, and the ADC sample rates are programmed by the host. Since the SPI bus is bi-directional the host can read data from the ADC, and write to the ADC registers to setup the various modes.

A good simple example of a SPI connected ADC is on the Linker board, and the software provided by Linker is capable of reading the analog voltages at the ADC inputs. This is demonstrated in the BreakerBall demo that I wrote a few years ago.

Last time I looked into the SPI drivers, the hardware chip select methods were not working well, and longer transactions (transferring hundreds or thousands of bytes per transaction) were not working well, but the hardware features of the 410 do work, and I believe that there have been some updates to the drivers to address these issues. If you hunt through the forums you will find examples of working SPI.

Getting any SPI interface up and running can be challenging since the active edges of the clock and chip select need to be configured, and often the data in and out pins get swapped due to the confusing naming. You really shouldn’t try to bring up a SPI interface without a 4 channel oscilloscope, since there is no way to debug the transactions in software. But once you “see” a transaction happening with the oscilloscope you can rapidly sort out what parameter you have set incorrectly.

Summer is almost over, almost time to start looking for a job…


Hi Lawrence
Thank you for your help,i will get back to you if i face any issue. Thank you again

Vybhav Jayaraman


The chip select or chip enable line’s frequency in SPI protocol is it constant or changing when SPI transaction is done ?

Thank you


The kernel can be configured to ignore chip select (e.g. require userspace to assert/deassert it), to use software to assert/deassert it during transactions (using cs-gpios in devicetree) or to use hardware to assert/deassert it.

If you configure spidev using the provided instructions the default will be to ignore chip select and you will have to manage it yourself (mostly because this plays nicely with userspace driver libraries MRAA/UPM):

If you want to use kernel-space drivers you should ensure the kernel also manages the chip select (given the feedback from @ljking that probably means using software techniques).

Data capture on the GPIO-With timing diagram

I’ve had feedback a couple of days ago that they are not going to fix the issues with the SPI driver:

As mentioned in the Bug ID there are workaround which involve rebuilding the kernel or using extra GPIOs.


I had posted this query a couple of weeks ago -Data capture on GPIO

I have uploaded the timing diagram of the data capture .
From the timing diagram in the file ,the frequency of CE=375KHz and DCLk=24MHz.

I need to know whether we can capture this data at every falling of CLK when these signal lines are interfaced to the GPIO?

Can anyone tell me whether Dragonboard 410C supports edge detection interrupts for the GPIO? If yes can I use edge detection interrupt to capture the data ?

Thank You
Vybhav (Email-


Edge detection is supported but from my point of view, it’s not easily possible to capture at 24Mhz (even with bare metal code). Cortex-A is not designed to give fast interrupt latency response. Even in best case, CPU idle, dedicated for IRQ handling, no cache miss… the interrupt latency will be too slow. For 24MHz capture, you have a ~40ns window to handle the interrupt, 48 CPU cycles at 1.2Ghz. I don’t know exactly how many cycles are requested to handle an interrupt with armv8 under Linux, but I would say hundred to several thousand cycles depending the conditions.

Maybe you can look at dedicated micro-controller (cortex-m, cortex-R) or FPGA for such capture.


I can reduce the clock frequency to 750 KHz and the chip select frequency to 10 KHz, in this case edge detection will work ?

I haven’t worked on bare metal code , i have implemented it using python and C (which didnt give me the desired results).


The diagram still looks like SPI (albeit with the ADC as the master). I’d recommend using a microcontroller of some sort to mediate between the ADC and the main SoC. Pretty much all microcontrollers can support SPI slave mode and reception is likely to be much reliable than trying to implement a bit-bang approach in the DB410C.