At a clock speed of 1.4Ghz, that's 100 instructions (more or less). From C, using something like WiringPi, you should easily be able to toggle a pin that quickly.

BUT: if you are doing this in Linux, there is a non-zero chance that your pulse will be stretched to some very long duration (10mS or more) by the OS time-slicing. If this is not acceptable, you will need to use some type of external timing logic to create your precision pulses.

BUT: if you are doing this in Linux, there is a non-zero chance that your pulse will be stretched to some very long duration (10mS or more) by the OS time-slicing. If this is not acceptable, you will need to use some type of external timing logic to create your precision pulses.

I haven't tried, but I believe the pigpio library allows you to define a pulse that will retain its width. But the time at which it is sent may jitter.
I think a repeated pulse can be made more stable, but one-shot in response to an event is harder. There are ways to improve your chances -- you need to do some research and experiment.

It is quite easy to get pulse times of that range, and a bit shorter. You will definitely need to use C or another compiled language to reach that kind of speed. Keeping Linux out of the way will be the hard part, though it is possible.

Alternately you could do so in Ultibo for your OS instead of Linux, as it is designed for that kind of things, that is if you do not mind using Pascal.

Or you could run on bare metal, and get even better precision than you ever could in an Operating system.

A lot of the limit depends on what else you also need to do in your program.

RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

It is quite easy to get pulse times of that range, and a bit shorter. You will definitely need to use C or another compiled language to reach that kind of speed. Keeping Linux out of the way will be the hard part, though it is possible.

Alternately you could do so in Ultibo for your OS instead of Linux, as it is designed for that kind of things, that is if you do not mind using Pascal.

Or you could run on bare metal, and get even better precision than you ever could in an Operating system.

A lot of the limit depends on what else you also need to do in your program.

I have Raspbian installed on my Pi. I'm currently communicating with an arduino which is used to display some GUI information through serial communication in Python. If I uninstall Raspbian, and install Ultibo, would I still be able to communicate through serial communication to the Arduino? Does Ultibo use C, Python?

It is quite easy to get pulse times of that range, and a bit shorter. You will definitely need to use C or another compiled language to reach that kind of speed. Keeping Linux out of the way will be the hard part, though it is possible.

Alternately you could do so in Ultibo for your OS instead of Linux, as it is designed for that kind of things, that is if you do not mind using Pascal.

Or you could run on bare metal, and get even better precision than you ever could in an Operating system.

A lot of the limit depends on what else you also need to do in your program.

I have Raspbian installed on my Pi. I'm currently communicating with an arduino which is used to display some GUI information through serial communication in Python. If I uninstall Raspbian, and install Ultibo, would I still be able to communicate through serial communication to the Arduino? Does Ultibo use C, Python?

Ultibo is a truely low level OS, that requires that the program be compiled into the OS, and it is in Pascal. So yes you could communicate with the Arduino, though it is not a normal OS that you directly use for everything, and its only programming language is Pascal.

If you are running the other stuff at the same time as attempting to create your pulse, you could run into some trouble regardless of the language implemented in. As you would be on Linux, with all the over head that a modern OS has, and you would have to be allowing the other stuff to have time to run.

RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Perhaps look at the hardware stuff the PI has. PWM, GPCLK etc
PWM has two hardware pins available for it.
Ultibo is better than Linux for this in software but there is still jitter coming from somewhere.

Joan's pigpio code might be a good place to start.

Lawrence Livermore Naval Labs? came up with a way of generating short pulses.
It led to the Ultrawide band radio modulation method.
If I remember right it used a dual input XOR gate and a delay on the second input.
A resistor and the gate capacitance makes for a RC delay on the second input.
A slow clock or pulse on the two inputs generates a short pulse on the output, picosecond accuracy.

A lot of the limit depends on what else you also need to do in your program.

My Pi will simply be sending a 50ns pulse, up to 800 times per second. My analog to digital converter is 16-bit precision and can sample up to 850 samples/s.

All the Pi will be doing is:
Toggling the pin to 3.3V HIGH, wait 50ns, to 0V LOW, and counting the clock cycles until the ADC detects a signal back above a certain threshold. It will then do a small calculation to determine the distance based on some known parameters and send that serially to the Arduino for display on GUI.

Having said that, will it be likely I can avoid the headache of uninstalling Raspbian, installing Linux, and potentially learning another hardware type language? I've written the serial code in Python, and was planning on toggling the GPIO in Python as well. I'm not afraid of rewriting the code if I need to though

Toggling the pin to 3.3V HIGH, wait 50ns, to 0V LOW, and counting the clock cycles until the ADC detects a signal back above a certain threshold. It will then do a small calculation to determine the distance based on some known parameters

You have two problems there:

1) Generate a 50ns pulse.

2) Measure time until something else happens.

I think at this point you should tell us exactly what your ADC is and what your sensor is so that we can think about your real problems with it rather than the problem you think you have.

However, I have managed to toggle a GPIO pin from software on Raspbian on a Pi at 50MHz, "bit banging" as they call it. That is a period of 20ns or a pulse width of 10ns. So you should be in luck. Before we get to the howto on this let's see why this is difficult...

Linux is a multi-tasking operating system. But it is not really designed for deterministic real-time system. This means that your program runs in a process, that process could get suspended at any time by the Linux kernel as the kernel decides it's time to go and run something else for a while. Eventually the kernel will swap back to running your program. The amount of time all this takes is unpredictable and can introduce delays of many milliseconds at any time in the execution of you code. Your 50ns pulse could get stretched, worse still your subsequent timing will be randomized.

What to do?

Assuming you have a four core Pi it is possible to stop the Linux kernel from scheduling any processes on one or more cores by adding an "isolcpus" parameter to it's boot command. For example to keep linux off of cores 2 and 3 add the following to the linux boot command line

Admittedly there were some interrupt happening still on that core causing occasional glitches, I never did find out what that was or how to get rid of it. But I think if that becomes an issue in your measurements you will be able to detect it and discard false readings.

Do read that whole thread, it's not so long, to see how well it worked out.

I'm hoping to be able to get mV resolution accuracy which is why I picked a 16-bit.
I'll be using serial communication to send information to an Arduino for GUI display on TFTLCD when certain criteria are met in the ADC to GPIO input.

Examples of the GUI because why not.

Also, this is the overall circuit that the pulse will be being sent through if anyone is interested. The Vpulse source on the bottom left represents where the PI's pulses will be received.

The ADC will be hooked up to the receiving wire of the PT-12 transducer. This is not represented well in the schematic, but is located at the place of the 50 ohm resistor and differential probes. Essentially, it is a dual element transducer with a separate coax cable for each element, and an isolation barrier between the elements. The signal is sent out, and comes back in the other element within some mV range that I am not yet certain of. The probe's two wires are both coax and have separate grounds, so additional isolation between the MCU and high voltage circuitry won't be needed.

I am expecting the energy within the voltage pulse to be very low, not enough to cause any damage or parasitics to affect the ADC/Pi. The 50 ohm resistor between the probes is actually the impedance of the PT-12 transducer.

What you can not do is respond to that pulse from Linux in any guaranteed time.

The only thing that is necessary is determining the time of flight of the wave between emission and recievsion. By respond, do you mean counting clock cycles accurately, or communicating this information to the Arduino through serial?

Woah there buddy. Slow down nessy....I don't have an oscilloscope IN MY BEDROOM.

Why not? I did as a student. It was a big Tektronix about 50 Kilo. Also multimeters, soldering irons and sometimes a motorcycle.

Also, it was a pretty good netflix show.

It's better not to mention you are wasting your time watching telly. We demand full attention, else you don't get ours.

Now, down to business:

That ADS115 ADC you have selected has a max sampling rate of 860 samples per second. That gives you a timing resolution of 1.16ms. Or 1162790ns. About 11 thousand times slower than the 100ns you have been talking about. I don't think you will be measuring your time of flight with that.

Why do you want mV resolution, you only need to know when a pulse comes back? You could do that with a comparator circuit.

The only thing that is necessary is determining the time of flight of the wave between emission and recievsion. By respond, do you mean counting clock cycles accurately, or communicating this information to the Arduino through serial?

I was not talking about any communication to anything else. Only the measurement.

If you want to measure a duration in software, banging on and waiting for GPIO pins, normally the Linux kernel will get in your way and mess things up. As I described above. I also described a solution.

Why do you want mV resolution, you only need to know when a pulse comes back? You could do that with a comparator circuit.

Correct, my apologies. I can confuse myself since I've been working on this for a while, going through different iterations of how it will work. The voltage shouldn't matter, only the time at which the voltage is raised from 0V.

I mentioned I wasn't sure what the magnitude of the reflected wave would be, only in mV. This was told to me by someone who had worked in the industry testing with these devices. I thought an ADC that could detect small differences would be best in case the signal was very low.