600MHz controller board, Teensy 4.0, $20

Hardworking uP genius, Paul Stoffregen, has introduced a new 600MHz 32-bit ARM Cortex-M7 controller board, in a compact 1.4 by 0.7- inch Teensy form factor (like Teensy 3.2).

formatting link

I imagine running one at 500MHz, and making perfect 2.0 ns-resolution pulse generators. Paul Stoffregen wrote and maintains the Arduino time library, so with his updated code it should be easy to write a program, make it work. First maybe gotta read NXP's 3637-page i.MX RT1062 reference manual. Or maybe the 111-page datasheet will do. Oops, there I learned the fastest hardware timer outputs are 20x slower. Oh well.

--
 Thanks, 
    - Win
Reply to
Winfield Hill
Loading thread data ...

The MSP430 claims 4 ns resolution:

formatting link
The STM32F3x4 seems to have 217ps resolution timers:
formatting link

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

Arie

Reply to
Arie de Muynck

The MSP430 claims 4 ns resolution:

formatting link
The STM32F3x4 seems to have 217ps resolution timers:
formatting link

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

Arie

Reply to
Arie de Muynck

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.

--
 Thanks, 
    - Win
Reply to
Winfield Hill

any and all pulses you can imagine:

formatting link

Reply to
Lasse Langwadt Christensen

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.

--
  Rick C. 

  - Get 1,000 miles of free Supercharging 
 Click to see the full signature
Reply to
Rick C

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.

Reply to
boB

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 
 Click to see the full signature
Reply to
Tim Williams

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

Nice! And cheap.

Reply to
Jan Panteltje

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

100Mb/s ethernet serial streams.

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".

formatting link

Reply to
Tom Gardner

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

--
 Thanks, 
    - Win
Reply to
Winfield Hill

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.

Reply to
Tom Gardner

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.