User avatar
mbferguson
Posts: 31
Joined: Thu Nov 15, 2018 2:33 pm

Toggling GPIO pins for pulse width of <100ns

Mon Nov 26, 2018 11:05 pm

I'm trying to use the PI's 3.3v logic gpio pins to create a short pulse that lasts around 50-100ns.

Googling 'GPIO pin toggle speed' gives many different answers that don't agree with one another.

Is this possible? What would be the limitation of pulse width if I was running a small program in python? in C?
Last edited by mbferguson on Tue Nov 27, 2018 2:36 am, edited 1 time in total.

User avatar
davidcoton
Posts: 4045
Joined: Mon Sep 01, 2014 2:37 pm
Location: Cambridge, UK

Re: Toggling GPIO pins for pulse width of <100ns

Mon Nov 26, 2018 11:23 pm

Why don't you try it and find out? That answer would be far more valuable than trying to resolve conflicting reports of other people's results.

You could even write up the results here. :D
Signature retired

rzusman
Posts: 346
Joined: Fri Jan 01, 2016 10:27 pm

Re: Toggling GPIO pins for pulse width of <100ns

Mon Nov 26, 2018 11:23 pm

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.

User avatar
davidcoton
Posts: 4045
Joined: Mon Sep 01, 2014 2:37 pm
Location: Cambridge, UK

Re: Toggling GPIO pins for pulse width of <100ns

Mon Nov 26, 2018 11:30 pm

rzusman wrote:
Mon Nov 26, 2018 11:23 pm
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.
Signature retired

User avatar
mbferguson
Posts: 31
Joined: Thu Nov 15, 2018 2:33 pm

Re: Toggling GPIO pins for pulse width of <100ns

Mon Nov 26, 2018 11:38 pm

davidcoton wrote: Why don't you try it and find out? That answer would be far more valuable than trying to resolve conflicting reports of other people's results.

You could even write up the results here. :D
I'm watching netflix right now, and would rather have someone else do it for me :mrgreen:

Also, no oscilloscope.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 1:08 am

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

User avatar
mbferguson
Posts: 31
Joined: Thu Nov 15, 2018 2:33 pm

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 1:13 am

DavidS wrote:
Tue Nov 27, 2018 1:08 am
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?

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 1:29 am

mbferguson wrote:
Tue Nov 27, 2018 1:13 am
DavidS wrote:
Tue Nov 27, 2018 1:08 am
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

User avatar
Gavinmc42
Posts: 3645
Joined: Wed Aug 28, 2013 3:31 am

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 1:58 am

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.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
mbferguson
Posts: 31
Joined: Thu Nov 15, 2018 2:33 pm

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 2:08 am

DavidS wrote:
Tue Nov 27, 2018 1:08 am
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 8-)

rzusman
Posts: 346
Joined: Fri Jan 01, 2016 10:27 pm

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 2:31 am

Raspbian IS Linux...

User avatar
mbferguson
Posts: 31
Joined: Thu Nov 15, 2018 2:33 pm

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 2:32 am

rzusman wrote:
Tue Nov 27, 2018 2:31 am
Raspbian IS Linux...
Said like a true Linuxian 8-)

User avatar
Gavinmc42
Posts: 3645
Joined: Wed Aug 28, 2013 3:31 am

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 2:46 am

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.
50ns is only 20MHz at 800Hz that should be relatively easy.
Standard clk is 19.2MHz, close enough?

Setup a hardware PWM with clock of 19.2MHz , a width of 1 at a period of 24,000?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
mbferguson
Posts: 31
Joined: Thu Nov 15, 2018 2:33 pm

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 2:51 am

Gavinmc42 wrote:
Tue Nov 27, 2018 2:46 am
Setup a hardware PWM with clock of 19.2MHz , a width of 1 at a period of 24,000?
I'm not following the width of 1 and period of 24,000. :oops:

Heater
Posts: 13134
Joined: Tue Jul 17, 2012 3:02 pm

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 3:51 am

mbferguson,
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

Code: Select all

 isolcpus=2,3
And reboot you Pi.

Now, the magic part of all this is that despite Linux not using cores 2 and 3 you can still run your program on them by using the "taskset" command:

Code: Select all

$ /usr/bin/taskset -c 2 ./myProgram
Now myProgram is running on core 2 and has the whole core to itself! Linux will not suspend it to schedule any other task there. It will run at full speed without interruption.

Assuming your program is written in C it can now access the Pi registers directly to do GPIO bit toggling. For my experiments I started from the example code by Gert van Loo & Dom here:
https://elinux.org/RPi_GPIO_Code_Sample ... ter_access

Have a look at the results I got in this thread: viewtopic.php?f=63&t=200793&start=25#p1252388

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.

User avatar
davidcoton
Posts: 4045
Joined: Mon Sep 01, 2014 2:37 pm
Location: Cambridge, UK

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 9:43 am

mbferguson wrote:
Mon Nov 26, 2018 11:38 pm
I'm watching netflix right now, and would rather have someone else do it for me :mrgreen:
I do hope you are joking.
mbferguson wrote:
Mon Nov 26, 2018 11:38 pm
Also, no oscilloscope.
How on earth are you going to check what is happening withoput an oscilloscope?

I'm out.
Signature retired

User avatar
Burngate
Posts: 5977
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK Tralfamadore
Contact: Website

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 10:15 am

Gavinmc42 wrote:
Tue Nov 27, 2018 1:58 am
...Lawrence Livermore Naval Labs? ...
Lawrence Livermore National Laboratory
https://www.llnl.gov/

User avatar
joan
Posts: 14210
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 3:43 pm

Yes you can generate a short pulse under Linux. I think user tag jbeale (apologies all round if I have the wrong user tag) managed 4ns and showed an oscilloscope trace.

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

User avatar
mbferguson
Posts: 31
Joined: Thu Nov 15, 2018 2:33 pm

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 5:08 pm

davidcoton wrote:
Tue Nov 27, 2018 9:43 am
How on earth are you going to check what is happening withoput an oscilloscope?

I'm out.
Woah there buddy. Slow down nessy.

I don't have an oscilloscope IN MY BEDROOM.

There are many good oscilloscopes in my university electronics lab 8-)

Also, it was a pretty good netflix show. :cry:
Last edited by mbferguson on Tue Nov 27, 2018 5:21 pm, edited 1 time in total.

User avatar
mbferguson
Posts: 31
Joined: Thu Nov 15, 2018 2:33 pm

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 5:13 pm

Heater wrote:
Tue Nov 27, 2018 3:51 am
Do read that whole thread, it's not so long, to see how well it worked out.
Will do my good sir. An update will be posted with progress soon. :geek:

ADC I'm planning on using --> https://www.amazon.com/gp/product/B01DL ... UTF8&psc=1
Datasheet: http://www.ti.com/lit/ds/symlink/ads1115.pdf

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.

Image Image

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.

Image

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.

https://www.amazon.com/Ultrasonic-Thick ... B01MTX2H4D
(No Datasheet, Chinese company with fake lemo connectors)

Here is the Cadence simulation of the circuit. The first few low voltage pulses are simply the simulation working through it's imaginary initial conditions.

Image

Zooming in on one of the pulses.

Image

The PT-12 usually operates at 220V, so I think that this will be close enough despite the losses through the diodes and BJTs. Also, the PFET is a power mosfet, so no worries about me electro-dieing. 8-)
Last edited by mbferguson on Tue Nov 27, 2018 5:58 pm, edited 13 times in total.

User avatar
mbferguson
Posts: 31
Joined: Thu Nov 15, 2018 2:33 pm

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 5:24 pm

joan wrote:
Tue Nov 27, 2018 3:43 pm
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?

Heater
Posts: 13134
Joined: Tue Jul 17, 2012 3:02 pm

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 6:38 pm

joan,
What you can not do is respond to that pulse from Linux in any guaranteed time.
My claim is that you can. If you isolate a cpu core to your thread. See my post above and our previous discussion of such things, linked to above.

Heater
Posts: 13134
Joined: Tue Jul 17, 2012 3:02 pm

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 6:55 pm

mbferguson,
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.

User avatar
mbferguson
Posts: 31
Joined: Thu Nov 15, 2018 2:33 pm

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 7:05 pm

Heater wrote:
Tue Nov 27, 2018 6:55 pm
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.

This seems to be a good ADC as replacement. MCP3008, sample rate of 200kHz max.
Datasheet: https://cdn-shop.adafruit.com/datasheets/MCP3008.pdf
Last edited by mbferguson on Tue Nov 27, 2018 7:14 pm, edited 1 time in total.

Heater
Posts: 13134
Joined: Tue Jul 17, 2012 3:02 pm

Re: Toggling GPIO pins for pulse width of <100ns

Tue Nov 27, 2018 7:12 pm

What about that 860 SPS rate?

What kind of time of flight are you expecting to see? Sorry have no idea about that sensor but I imagine it can be very short.

Return to “General discussion”