Mircro-controller designs to generate nano second pulses with variable delay. - Page 1
Forum section: electronics / general

author: fracton
author_rank: Contributor
timestamp: September 20, 2024, 04:17:19 am
content: For another project, I am trying to build a controller circuit that can generate four 50ns second pulses with variable delay upon receiving a TTL pulse as a trigger (with a repetition rate of 10Hz). While I have a low duty cycle application, I was hoping to build something that could operate atleast at a kHz repitition rates. I am considering to use Teensy4.1 for this application, I am guessing just counting for CPU clock cycles to give out pulses on the output pins should work. However, I am a beginner and have lilttle to no experience with microcontrollers. Would appreciate any help for any useful comments.

author: Andy Chee
author_rank: Super Contributor
timestamp: September 20, 2024, 04:49:41 am
content: Can you sketch out a few example timing waveforms?Or even better, please provide the datasheet of the thing you are trying to control!

author: JPortici
author_rank: Super Contributor
timestamp: September 20, 2024, 05:02:59 am
content: I'm a bit unsure about the 50ns, but you *should* be able to do it with a dsPIC33CK high speed PWM. You also have a retriggerable mode with a retriggerable counter, so you can generate up to 7 pulses after a trigger

author: pcprogrammer
author_rank: Super Contributor
timestamp: September 20, 2024, 05:30:34 am
content: There are of course many solutions to your problem, but using hardware timers that are available in many MCU's will make it more robust than counting CPU cycles. The nano seconds timing you like limits things to MCU's that can run on higher frequencies.The Teensy 4.1 certainly falls in this category and has timer peripherals that can create the pulses and the delays you need. The software only has to write the registers to set the durations. Get yourself thedatasheetand reference manual to find out more about the capabilities of this MCU. To get the reference manual you have to create an account at NXP though.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 20, 2024, 05:32:43 am
content: E.g. STM32H7 series HRTIM (which is a downgraded version of earlier HRTIM without the analog extra time resolution trickery) can run at 400MHz, giving nice 2.5ns steps, so accurate 50ns is doable, so it depends on the needs of those "variable delays", but I assume 2.5ns resolution for the delays would be fine, too?

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 20, 2024, 05:39:59 am
content: Quote from: fracton on September 20, 2024, 04:17:19 amBroadly, yes.You need to define the tolerance and granularity on the delays and pulses.Any small MCU can wiggle pins at opcode speeds, but pulses and delays will be quite granular, as will the response time and jitter from the trigger pulse.You could also look at the Pi PICO RP2040 or newer RP2350 PIO modules.Those can wait on a pin, then delay and pulse, with opcodes speeds IIRC of 150MHz on the RP2350, so that improves your granularity

author: pcprogrammer
author_rank: Super Contributor
timestamp: September 20, 2024, 05:48:15 am
content: The STM32F334 has 217 pico second resolution timers, but getting a board with one of those might not be as easy and cheap as a H7 variant.On the other hand, the STM32G474 has 184 pico second resolution timers, and can easily be found onAliexpress.As I wrote earlier, there will be many solutions for the problem. Choosing the right MCU is one of them.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 20, 2024, 07:10:48 am
content: Quote from: pcprogrammer on September 20, 2024, 05:48:15 amYeah, that's the analog trickery HRTIM I mentioned above. Be careful with it though, it is not an actual digital timer with that much resolution, so it has "terms and conditions". Like, you cannot sample an input with such accuracy, therefore cannot create delay from input trigger to output with that resolution. It's only mainly for high-resolution pulse width modulation and even then comes with maximum and minimum duty cycles.So the later H7 "crippled" HRTIM which runs at 400MHz or 480MHz is in many ways "better" and easier to understand. And something similar is probably available on nearly every high-end microcontroller.

author: fracton
author_rank: Contributor
timestamp: September 20, 2024, 09:18:22 am
content: Quote from: Andy Chee on September 20, 2024, 04:49:41 amPlease see the attached image. I need 2 sets of pulses with variable delay between them i.e delay between (1,2) and (3,4) is can be fixed (50-100 ns) while I need to have control over the delay between the two sets.Quote from: Andy Chee on September 20, 2024, 04:49:41 amThe "thing" I am trying to control are MOSFET gate drivers of switching circuit I am trying to build.

author: Andy Chee
author_rank: Super Contributor
timestamp: September 20, 2024, 11:52:03 am
content: Quote from: fracton on September 20, 2024, 09:18:22 amWhat are your MOSFETs controlling?If it's a stepper motor, rail gun coils, or something mechanical, then such mechanics cannot respond to your tiny nanosecond pulses.

author: pcprogrammer
author_rank: Super Contributor
timestamp: September 20, 2024, 11:53:03 am
content: Looks like the interval is a multiple of the 50ns pulse. If that is indeed the case timers clocking at 20MHz should be capable of pulling this of. Have the TTL signal trigger an interrupt and in the interrupt routine start a timer and use compare settings to generate the pulses. I think this can even be done with a STM32F103C8T6 found on the bluepill.

author: fchk
author_rank: Frequent Contributor
timestamp: September 20, 2024, 01:44:16 pm
content: A FPGA (even a small one) would be perfect for this task. Since everything is logic dates driven by a stable clock timings can be 100% accurate and repeatable.The logic inside this FPGA would be a simple counter and some comparators that compare the counter value to some preset and set or reset a RS flipflop.

author: pcprogrammer
author_rank: Super Contributor
timestamp: September 20, 2024, 03:38:22 pm
content: Quote from: fchk on September 20, 2024, 01:44:16 pmAbsolute, but the OP stated to be a beginner, so a FPGA might be even more difficult than using a MCU.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 20, 2024, 04:09:09 pm
content: Quote from: fchk on September 20, 2024, 01:44:16 pmOh, FPGA would be "perfect" for any task. But this task is 99% likely one for which market is full of well-suited microcontrollers. Which are one tenth of price of FPGA and require one tenth of design complexity.But of course devil is in details, so to confirm this more information about what OP is actually doing is necessary.

author: pcprogrammer
author_rank: Super Contributor
timestamp: September 20, 2024, 04:21:36 pm
content: Quote from: Siwastaja on September 20, 2024, 07:10:48 amI took a look at the reference manual for the STM32G4 series and the HRTIM is indeed a complex beast. Would be fun to play with, but I have no test equipment that can check if it can actually create pulses with the 184ps resolution. You are on the dot with the "terms and conditions" it comes with.

author: fracton
author_rank: Contributor
timestamp: September 20, 2024, 07:10:48 pm
content: Quote from: Siwastaja on September 20, 2024, 04:09:09 pmI am currently trying to build a High Voltage pulse generator circuit for a time-of-flight experiment using high voltage SiC MOSFETs. The HV pulse generator basically is sits between a HV power supply and a capactive load, driving it during the duration of pulse.The HV and the control sides of circuit are galvanically isolated using pulse transformers. To drive the gate capacitance of the MOSFETs on the HV side, I use high-speed MOSFET gate drivers that give out pulses upon receiving an input trigger. I only want provide the pulse generator a single external trigger, from which I plan to generate four pulses to sequetially charge and discharge the gate capacitance of the MOSFETS to generate a HV pulse. Further, in my current application the external trigger pulse has a repitition of 10Hz, while this could easily go upto 10's of kHz for other applications. Unfortunately, I don't have a neat schematic of my circuit, but it is largely based on this design (see the attached pdf) from a related textbook.

author: fracton
author_rank: Contributor
timestamp: September 20, 2024, 07:27:08 pm
content: Quote from: pcprogrammer on September 20, 2024, 03:38:22 pmI have some decent amount experience in working with C/C++, Fortran and Python. I could give it a try to program an FPGA. But, my only concern is the cost. I'm looking for a low-cost alternative that it robust enough to give these 4 pulses with minimal jitter and without any false triggering.From the inputs, I got from this thread, I'd try dsPIC33CK high speed PWM suggested by @JPortici as well as the the HRTIM option with the STM microcontrollers suggested by @Siwastaja and @pcprogrammer. Can any of you, comment on the jitter and timing issue, if any with either of these options.

author: nctnico
author_rank: Super Contributor
timestamp: September 20, 2024, 07:31:12 pm
content: Quote from: pcprogrammer on September 20, 2024, 03:38:22 pmNot necessarily. There are tons of simple FPGA boards out there. Tang nano with a Gowin FPGA for example. A few lines of VHDL will do the trick. As a teenager I was using programmable logic as much as microcontrollers already. And nowadays the tools have become much easier to use and more powerful.

author: fracton
author_rank: Contributor
timestamp: September 20, 2024, 07:41:34 pm
content: Quote from: NorthGuy on September 20, 2024, 07:24:56 pm<100 ns, anything more than that would significantly increase the dead time of my device.Quote from: NorthGuy on September 20, 2024, 07:24:56 pmQuote from: NorthGuy on September 20, 2024, 07:24:56 pm+/- 5-10 ns would be an acceptable accuracy for the intended application.Quote from: NorthGuy on September 20, 2024, 07:24:56 pmThe intended application of this timer circuit is to control an ultrafast HV pulse generator. The desired rise and fall times should ideally be <10-15 ns.Quote from: NorthGuy on September 20, 2024, 07:24:56 pmAs I explained in one of my replies, the delay between first two pulse and the last two pulses has to be variable. Ideally, these delays could vary between the two sets of pulses 100ns to 100's microseconds.

author: nctnico
author_rank: Super Contributor
timestamp: September 20, 2024, 08:27:04 pm
content: Quote from: fracton on September 20, 2024, 07:41:34 pmYou might be able to pull this off with a microcontroller which has a programmable timer (=a timer which can do things automatically based on inputs changing). But this timer would need to run at at least 100MHz (10 ns cycle time). And even then I'm not sure a 100ns latency is feasible with the degree of flexibility you want to achieve. Keep in mind that the event inputs will be sampled using the clock which drives the timer. This adds latency especially if the inputs go through a debounce/filter circuit.Have you considered looking at a multi-output function generator or some kind of digital pattern generator? Using an off-the-shelve unit would save you quite a bit of effort compared to building something like that from scratch.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 21, 2024, 01:28:05 am
content: Quote from: fracton on September 20, 2024, 07:27:08 pmDid you look at the Raspberry pi pico ?The PIO engine on that can give lower trigger jitter and delay, than a MCU interrupt design.That’s much cheaper than a fpga, and has modest SW complexity.Quote from: fracton on September 20, 2024, 07:41:34 pmThe Pico PIO will have sampling granularity of appx 7ns, so that sets your response jitter.There is a latency delay of InPin -> sampler -> state engine -> sampler -> OutPin which will be 2-4 clks + a few ns. Should be well under your 100ns - I'd guess 21-49ns ballpark, with 7ns jitter.Subsequent Edge to edge timing will be low jitter, and you could adjust the PIO PLL to fine tune that, if 7ns steps are too coarse.eg pick 100Mhz for 10ns ruler, 90.9 MHz for 11ns ruler and 111MHz for 9ns ruler etcIf sampled clock delay quantize is too large for you, you could move into the somewhat analog domain with a Monostables, or triggered VCO+counters or Delay lines (ADI have a series )

author: nimish
author_rank: Regular Contributor
timestamp: September 21, 2024, 01:53:21 am
content: Quote from: Siwastaja on September 20, 2024, 07:10:48 amThe HRTIM is just a timer with a delay line attached (or DLL, iirc)You can make them in verilog, CERN has a bunch of open source ones since ToF/TDC measurement is critical for them

author: pcprogrammer
author_rank: Super Contributor
timestamp: September 21, 2024, 06:34:48 am
content: Quote from: fracton on September 20, 2024, 07:27:08 pmHaving programming experience can be a burden when working with a FPGA. It is very different even though for example verilog has a lot of similar syntax to C. For "programming" a FPGA a HDL is used which is a hardware description language. So you have to think hardware not software. The logic works in parallel and is not directly sequential like how things are done in software.And yes there are cheap enough FPGA boards out there, even cheaper than STM32H7 boards, and maybe with a lot of example code that can be found on the net, it will need a lot of time if you are not used to thinking in digital hardware terms. There certainly is a learning curve to it that has many elements. At first the HDL, then a simulation environment and last but not least the vendor tools needed for the chosen FPGA.It will definitely provide a very robust solution, but with the need for an adjustable delay between the two sets of pulses it also needs something like a state machine, a softcore or an external MCU to write the needed delay to a register in the FPGA.Quote from: fracton on September 20, 2024, 07:27:08 pmJitter depends mainly on the quality of the crystal and the clock hardware in the MCU. Latency depends on how fast the MCU runs and it's interrupt handling system, if this is used of course. A more hardware based solution like in the Raspberry Pico it will be different, like clearly explained by PCB.Wiz.Quote from: PCB.Wiz on September 21, 2024, 01:28:05 amUsing the Pico PIO part also has a bit of a learning curve, but so do the other solutions with timers found in MCU's. It might be the best in between solution though.

author: peter-h
author_rank: Super Contributor
timestamp: September 21, 2024, 10:36:56 am
content: I did FPGA/ASIC design consultancy (Xilinx) for many years and although FPGA software is now a lot better I would still do anything with a microcontroller if at all possible. With FPGAs you sink a lot of time and learning curve climbing into an area which is a dead end... not what I want to do with my life. With code, you are learning useful stuff almost all the time.We still don't have the spec for this project, have we?A 480MHz CPU ought to be able to waggle a GPIO pin with a ~2ns resolution - assuming the GPIO clock is actually 480MHz in the fastest-GPIO mode. Any better, one might do it with PCB tracks of different lengths (1ns is about 2cm?) and then use the CPU to switch a mux selecting different taps. IOW, a DIY delay line.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 22, 2024, 01:50:43 am
content: Quote from: fracton on September 20, 2024, 09:18:22 amSome more thoughts on this :If the clock-sampling jitter on the trigger pulse is a problem, a hybrid solution might work.Use chained monostables for the immediate 'close in' two output pulses, will give you sub-ns jitter and analog precision of delays and widths.Then, the further out pulses, of 1us+ are probably ok with clock based pulses. The % error is quite small of 7ns in 1us

author: dmsc
author_rank: Newbie
timestamp: September 29, 2024, 01:02:45 am
content: Hi!Quote from: fracton on September 20, 2024, 09:18:22 amThis is exactly the application for the "one-pulse mode" of the STM32 timers, it is available in all the STM32 micros. From the reference manual:QuoteBy having the timer run at 20MHz (50ns period) you can get all the waveforms you sketched. You use one input and the 4 timer channels to generate each of the 4 outputs.

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: September 29, 2024, 02:28:50 am
content: Similar timing waveforms are often encountered in radar applications, and are usually implemented in an FPGA or similar. One method I've found handy is to implement a programmable state machine with a block RAM to store the state transitions and the time delay to the next state transition. When the external trigger is received, the state machine starts from the beginning of the block RAM and 'plays back' the stored transitions. Resolutions of 10 ns are easy to achieve on older FPGA families, and 5 ns or shorter on newer ones. The waveform sequence may be easily changed by rewriting the block RAM contents.One could also do a similar implementation using a memory block (SRAM, EPROM) and a counter.

author: fracton
author_rank: Contributor
timestamp: September 30, 2024, 06:04:49 pm
content: I've been trying out a couple of microcontrollers and pulse-width modulator ICs suggested above in this thread. While I've explored using an FPGA to do they same job, for now it seems to be an overkill.I will try to post results from some of tests with MCUs in this thread, soon.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: October 01, 2024, 01:29:43 am
content: Quote from: fracton on September 30, 2024, 06:04:49 pmPWM controllers for motor drive are common these days, even in small MCUs, so you can almost manage a mostly hardware solution.However, those work slightly differently from your pulses, in that they can trigger and produce a defined delay to a rising edge.You can get 4 narrow pulses if you trigger 4 monostables, then you get fine analog control of the MOSFET pulse widths and the small MCU gives digital control of the times between pulses.

author: mino-fm
author_rank: Regular Contributor
timestamp: October 01, 2024, 09:25:07 am
content: Quote from: fracton on September 30, 2024, 06:04:49 pmYou can use one PIO of RP2040. Define 4 outputs and shift out 32 bit patterns. If period is 12,5 ns each pulse will last 50 ns.send to OSR-FIFO:0x11110000 pulse 1 + 50 ns delay0x00002222 50 ns delay + pulse 2delay by sending 0x0 pattern, by counting down a register or missing of new patternsend to OSR-FIFO0x44440000 pulse 3 + 50 ns delay0x00008888 50 ns delay + pulse 4

author: PCB.Wiz
author_rank: Super Contributor
timestamp: October 01, 2024, 08:02:28 pm
content: Quote from: fracton on September 20, 2024, 09:18:22 amGiven that pulse scheme, that's not quite native PWM, but you can combinea two input gate driverneatly with a 2 setting PWM, for a no-additional parts solution.eg looking at the RP2350 PICOIf PWM_A = IN- and PWM_B = IN +,the output is HI only in the difference region (B & !A)I think the PICO can clock PWM to above 150MHz giving set points for each edge, to drive 8 pins, for 4 gate drivers.You can define any edge to 6.7ns granularity inside a 437us window (2^16).Triggering is covered here12.5.2.5. Level-sensitive and Edge-sensitive TriggeringThe PWM provides the following counter modes:• Default free-running, counting continuously whenever the slice is enabled (free-running)• Count continuously when a high level is detected on the B pin (level sensitive)• Count once with each rising edge detected on the B pin (rising edge-sensitive)• Count once with each falling edge detected on the B pin (falling edge-sensitive)

author: NorthGuy
author_rank: Super Contributor
timestamp: October 02, 2024, 03:58:04 am
content: Quote from: fracton on September 20, 2024, 07:41:34 pmThis is difficult for a CPU, so you'll need some logic. Some of the MCUs can do things automatically, such as trigger PWM or start timer using an external pulse, but even then they often have different synchronizers, so it might be over 100 ns by the time the signal is visible to the CPU. Such things are rarely documented, so you'll need to try.Is there any way for you to anticipate the time when you need to start the pulse sequence? If you could send the trigger earlier, say 500 ns or 1 us before the sequence should start, this would remove the requirement for short latency, then practically any MCU will do.Aside of the latency, everything else is trivial and can be done by practically any MCU.

author: mino-fm
author_rank: Regular Contributor
timestamp: October 14, 2024, 10:57:59 am
content: Sitting here on a rainy day I liked to play around with RP2040 and Arduino. The result is shown as TO has given his demands. (Sorry for bad GND-connections.)Using 200 MHz clock you get 5 ns timing which should be fine enough. As everyone knows RP2040 is working well at this frequency ;-)Spacing between pulse_AB and pulse_CD can be modified by Serial Monitor of Arduino IDE or using a terminal programm.

author: gdr771
author_rank: Contributor
timestamp: October 16, 2024, 01:11:08 am
content: Whatever microcontroller you end up using, be sure to check if it has a switchable slew-rate limiting feature to reduce EMI from the output edge rate, and of course disable said feature if necessary.

author: jwet
author_rank: Frequent Contributor
timestamp: October 16, 2024, 04:42:36 pm
content: Don't know what level of precision is required and this is coming from another direction, but you might consider a multi-tap silicon delay line or related. Maxim and LTC, now ADI, still makes a few that have 5 taps with fixed "semi precise" delays between outputs. They were once popular in DRAM circuits and ATE equipment, etc. Accuracy is a few percent, operation is dead simple. Look at Max1100 or search DK for delay circuits. Digikey still sells some and they're popular surplus parts.At your speeds, you might even be able to get away with just old 74C cmos jelly beans, they have prop delays on the order of your delays.Good Luck.

author: marcov
author_rank: Newbie
timestamp: October 29, 2024, 03:31:13 pm
content: Quote from: JPortici on September 20, 2024, 05:02:59 amAnother solution for the dspic33 range: Output Compare in dual compare can be trigger from an INT . If you can get a no code solution to rearm the OC after one cyclus, it could be quite fast. You could use the OC interrupt to retrigger the OC, which would still be only in the 1-2us magnitude.

author: NorthGuy
author_rank: Super Contributor
timestamp: October 30, 2024, 07:55:12 pm
content: Or use PIC16F13xxx. They have a tiny FPGA inside with around 30 LUTs, programmable in Verilog, which you can interconnect with timers and other periphery.

author: fracton
author_rank: Contributor
timestamp: November 21, 2024, 06:44:25 pm
content: Thanks a lot! That was really helpful. I was wondering if I could trigger pulses C and D at the falling edge of my input pulse. In that case the pulse width of my input pulse would determine the delay between A_B and C_D.

author: mino-fm
author_rank: Regular Contributor
timestamp: November 22, 2024, 12:44:51 pm
content: If you like to use my RP2040 program, you can add PIO-code:// delay*prg++ = 0xa046; // mov y, isradr++;*prg++ = 0x0080+adr; // while(y--); jmp y--adr++;// additional wait until TRIGGER_PIN goes low*prg++ = 0x00c0 + adr + 2; // if(!TRIGGER_PIN) skip loopadr++;*prg++ = 0x0000 + adr - 1; // loopadr++;// 2. patternIt isn't tested but should work this way. Please notice: TRIGGER_PIN ist inverted by GPIO4_CTRL.