600MHz controller board, Teensy 4.0, $20

The MSP430 claims 4 ns resolution:

Combine 2 timer outputs with a high-speed gate for short pulses?

Arie

The MSP430 claims 4 ns resolution:

Maybe combining 2 timer outputs with a high-speed gate can give short pulses?

Arie

Paul Stoffregen's new board is great, but maybe for my pulse-generator idea, one of these other processors on an evaluation board would be better. I've plopped an STM32F chip down on some of my other PCB projects. That's a pretty nice series.

Dunno, sounds painful.

any and all pulses you can imagine:

Trying to get an MCU to provide high resolution pulses sounds painful to me. Why not use one of the many low cost FPGA boards available now. For not a whole lot more than the Teensy 4.0 board, you can get a FPGA board on a similar form factor.

FPGAs often have PLLs and can run quite high clock rates internally and with SERDES can get very high bit rates on I/Os.

Yes, I have thought about this this as well. One thing you can do is to combine 2+ timer outputs for creating a higher resolution DC voltage but creating the shorter pulse might take a little more work. I haven't thought about that very hard but should work about as well as the STM32F334 method that uses a delay line IIRC.

NXP LPC series uses a method where they have a combination of 16 different pulses that average out to a higher resolution PWM signal over time which works OK maybe but just not the same as a real HRPWM generator.

Must be more says to skin the cat instead of having to have a 5GHz clocked timer.

Someone should be able to port Doom to Arduino and have it run on that. Just add button inputs and LCD display (and optionally, audio output).

Tim

-- Seven Transistor Labs, LLC Electrical Engineering Consultation and Design Website:

On a sunny day (Wed, 7 Aug 2019 14:26:59 -0700 (PDT)) it happened Lasse Langwadt Christensen wrote in :

Nice! And cheap.

If I wanted to generate an arbitrary bitstream in software (as opposed to an FPGA), I'd use a *hard* realtime multicore processor with up to 32 cores. Key principles: simply dedicate one core to an i/o port, no interrupts, no caches, excellent inter-core comms hardware *and* software. The latter is missing from everything else.

I "kicked the tyres" to see if the hardware+software worked. It did, and *everything* was *remarkably* easy. There were no unpleasant surprises, nor 1000 page manuals, thank God.

Key points: - xCORE processor (buy them at DigiKey) - one of the 32:1 SERDES outputs giving 2ns pulse width - feed the SERDES output from one core - use other cores for USB/ethernet/front panel etc - core will stop and wait for the first of input X or output Y or message in or message out or timeout - and resume within 10ns - can specify when an output will occur to 2ns, and measure when input occurred to 2ns. - up to 32 cores/chip (4000MIPS), can daisy chain chips for more cores (software unchanged but there is some added latency) They are more than capable of sourcing/sinking

The cores are hard realtime; the IDE guarantees timing; none of this "measure and hope you hit the worst case" nonsense.

The xC software is excellent and designed for multicore operation; there's nothing else that comes close. The heritage is Hoare's Communicating Sequential Processes (CSP), Occam and Transputer. Comms between cores is exactly the same as comms to i/o, via "ports".

But no hardware counter/timer available? Make one in software, with decisions and loops? Assembly language, or equivalent?

Oh, I took that for granted, and it is *much* better and easier than you might expect :)

There is a global timer. Every port has its own timer.

The language is basically C/C++ - plus constructs for parallel programming, e.g. par, select - minus constructs that foul up parallel programming e.g. aliasing, memory accessed by more than one core - ports are to/from pins or other cores :) - ports to other cores are 32 bits - ports to pins are 1/2/4/8/32 bits wide, options - SERDES - strobed - different clock rate to the cores, max 250MHz/4ns - buffered - external clock - conditional, value == X or value != X - setting up the ports is simple and obvious (unlike many processors!), via function calls - you can escape to C/C++ if you want; I never have - the assembler is documented and visible in the xTime IDE (Eclipse based); only see it when single stepping in the usual fashion.

There are language constructs to use the timers:

- input: stall a core until input is available and capture the input and the i/o clock cycle at which it arrived e.g. aPort :> inValue @ whenInputArrived;

- output: state the clock cycle at which an output must be done, and stall a core until it has been output e.g. aPort aInVal: ... case bPort :> bInVal: ... case aTimer when timerafter( timeout ) : > void : ... }

where resumption latency is 10ns (not us/ms etc!), and the IDE examines the binary to tell you how long it *will* take to get from here to there.

Overall it is like having an RTOS in the language and hardware.

The restrictions, such as they are, are easily understood and /predictable/ iff you think in terms of what is safe/dangerous/possible in a multicore environment.