I am working on reading an External 3 bit ADC (44MSPS) digital output through Arduino's digitalread() function, my only concern is the speed of digitalread() can it handle this amount of samples then print them in the IDE serial monitor?
If I am sending parallel bits is there any way to synchronize them with ext/Inter clk during the digitalread process?
thanks in advance
Look at the PORT commands - If you select your pins carefully you can read all three in the same instruction.
Edit: Serial speed is likely to be the limiting factor though.
If you want to use Arduino Uno there is no chance to read 44 MSPS with the 16 MHz professor.
I am planning to use Arduino due with 84Mhz clock speed
Under two processor clock cycles per sample?
I am not sure I understand what u mean
Think about what you are asking: the Due executes 84 million instructions a second, and you expect to capture 44 million samples per second
I guess it is possible, my only concern is the digitalread() speed and synch issue
You can be certain that if (and it's a big "if") it is possible, it isn't possible using digitalRead.
No, it isn't. The Due is way too slow.
do u have suggestion on what can I use ?
A Teensy 4?
Also consider your output. How many characters will you emit per reading? I can't see that the serial port will keep up.
I think you need to stop, take a deep breath, and understand what it is that you want to do.
Do you really want to take 44Msamples/second and output that through a serial port with a maximum rate of 921,600 bps? Does that sound possible?
To be fair, there was no mention that it would be done at the same time - it could be buffered in the Due's capacious RAM.
I am not sure if a poet would say --
roomy RAM
As a simple experiment you can read in a for-loop and time the loop with millis(). For example, time how long it takes for 10,000 or 1 million reads, etc. You'll have to add a counter and that will slow-down the loop, but eventually you're going to have to store, or do something, with that data anyway so that's just to give you an idea of how fast you can go.
I assume you don't mean literally printing/displaying millions of numbers!!!! 
You also don't have enough video resolution to graph millions of samples.
Also, the ASCII representation of a number requires a lot more bytes than the "raw" binary data.
I've got a 100MHz oscilloscope on my bench at work with a sample rate of 1.25GSPS but the display is only a few-hundred by a few-hundred dots... Something close to "VHS resolution".
I assume that's a 3-wire ADC (maybe SPI)??? I've never heard of a 3-bit ADC, which would only read 0-7 (decimal).
the MAXI2771 EVKIT (https://datasheets.maximintegrated.com/en/ds/MAX2771EVKIT.pdf) is what I intent to extract the sampled data from, unfortunately they do not provide a way to process the sampled data therefore I am looking for the appropriate microprocessor that can handle the data.
ps: the MAXI2771 IC (https://datasheets.maximintegrated.com/en/ds/MAX2771.pdf) : contains the ADC used + it's maximum sampled rate.
No, it's a 3-bit ADC with parallel output. But knowing that isn't very helpful. There are still the problems of
- Sampling at 44MHz rate
- Transmitting the data to a PC from an arduino at a 44Mhz rate
- Storing and/or displaying the data at a 44MHz rate.
Hence my suggestion to OP that they take a deep breath and think through how the system is supposed to work.
To sample IO bits at 44MHz, you would normally want DMA on a chip that runs its memory significantly faster than 44MHz (to avoid contention with other memory accesses.) I don't think that a Due is fast enough; a Teensy4 might be.
That is "hard", even before you consider how you're going to process, transmit, and/or display the data (which is even harder.) Typically I'd expect some sort of hardware FIFO and setup that would buffer data into somewhat larger words, to reduce the memory bandwidth required. (5 samples aggregated in 16bits would cut the transfer rate to "only" 8MHz, which would be much easier.)
As an example, Ethernet MACs typically have a "Media Independent Interface" that pipes 2 to 8 bits in parallel to cut down on bus access rates. (OTOH, various other protocols go to fully serial protocols to cut down on pins, but they tend to be "well defined" rather than "user gets to specify how many bits.")