Adjust teensy clock speed with a knob?

Status
Not open for further replies.
M

mykle

Well-known member
Hi,

I've just spent some time noodling with a retro guitar delay pedal that use a simple PT2399 echo chip with an adjustable clock. The way the sound responds to live manipulation of the clock rate is really interesting to me, and I think is part of what they're talking about when they describe it as a 'analog delay' (although the PT2399 is as digital as anything.)

Anyway, this got me to thinking about the ways I could interface my teensy with various analog signal sources and sinks, and I got to wondering if it's possible to slew the clock frequency of the teensy and the audio board via a potentiometer or an external control voltage ... or even internally via software.

To be clear, I'm not talking about adjusting the input or output sample rate by messing with the timers, and I'm not talking about adjusting the prescalers. I'm talking about adjusting the main clock frequency that drives all the other clocks on the chip, from the maximum of 96mhz down to a minimum of 0. So basically, replacing the crystal oscillator with some kind of adjustable equivalent. That would allow me, right off the bat, to do the same kinds of knob-twiddling echo effects that these pedals do, but I can think of a host of other interesting possibilities.

I've read that some chips can deal with this and others can't. ADC performance might be affected, I don't know how much. DAC performance would have to be decent for this to be worth trying. Has anybody tried this? How would you go about it?

Thanks for any advice,
-mykle-
 
USB is the main obstacle to flexible clocking. It requires a very accurate 48 MHz clock, which is created from the PLL output using a direct or 2X multiplier and a 1 to 8 divider. So only exact multiples of 24 MHz work.

The other possible issue is the PLL's response speed to changing input, and it's limited lock range. It's designed for a very stable crystal. As I recall, it only works with input between 2 to 4 MHz, and there's a programmable divider to get the input into that range.

Many other technical issues probably exist.
 
As someone that does dynamic cpu scaling, this would be very difficult to do. Not only the usb but pretty much everything is tied to compile time constants of F_CPU, F_BUS and F_MEM meaning everything that relies on those clocks will have to be adjusted. The DAC might not even work like this and you will have your work cut out to figure out all the adjustment on the fly to get it to behave. Then when you go below 24MHz you have to change clock modes and lose all USB and those modes take much longer to switch to so that delay will be limiting any smooth transition.
 
For PT2399 emulation, I think what you're really looking for is a modulated delay line.

I've got a sketch using one here:
https://github.com/Jacquot-SFE/Synth-drum/tree/master/teensy-based/fx/cosmic-delay-sketch

It's got a bunch of other stuff in it as well - highpass and lowpass filters on the feedback, as well as distortion. You could add realtime controls for each of them for a lot more hands-on playability.


If you really want variable clocking for an audio stream, the bit-crusher can run at reduced sample rates.
 
duff said:
As someone that does dynamic cpu scaling, this would be very difficult to do. Not only the usb but pretty much everything is tied to compile time constants of F_CPU, F_BUS and F_MEM meaning everything that relies on those clocks will have to be adjusted.
Click to expand...

Well, the point would not be that the chip can detect its own speed change and adjust. I certainly wouldn't expect USB or other clock-based communications to keep working. But if the audio board takes its clock from the teensy's chip, I'd hope that the i2c bus would keep working, at whatever speed. As the clock slows I'd expect that any audio being written to the DAC would get slowed down by the same amount.

duff said:
Then when you go below 24MHz you have to change clock modes and lose all USB and those modes take much longer to switch to so that delay will be limiting any smooth transition.
Click to expand...

Why do you have to change clock modes below 24mhz?
 
B.Jacquot said:
For PT2399 emulation, I think what you're really looking for is a modulated delay line.

I've got a sketch using one here:
https://github.com/Jacquot-SFE/Synth-drum/tree/master/teensy-based/fx/cosmic-delay-sketch


Hey, that looks like a really cool project. Is it something I can compile & listen to, or is it still work-in-progress?

But I'm not looking to simulate this stuff digitally. To my ear, there's something very different-sounding about an analog-slewed clock delay, compared to the digital delays I've listened to that modulate via (one assumes) interpolation. It's like there's more detail to the results. Also, the immediate feedback when twisting a knob is hard to match in the digital domain. Probably it can be done eventually, but it just seems a fundamentally simpler approach to adjust the speed of the clock in order to adjust the pitch of a signal-generating algorithm on the DAC, instead of asking the CPU to do a bunch of interpolating.
Click to expand...
 
PaulStoffregen said:
The other possible issue is the PLL's response speed to changing input, and it's limited lock range. It's designed for a very stable crystal. As I recall, it only works with input between 2 to 4 MHz, and there's a programmable divider to get the input into that range.
Click to expand...

Interesting. I'm reading up on this ... are you talking about the PLL that's used for the I2C bus, or the PLL that's one of the three options for SYSCLK? Does the Teensy use the PLL as SYSCLK source by default? For this application I assume I'd be switching to the high-speed external clock -- if I'm allowed to do that in software -- and attaching some component or circuit to generate an adjustable clock source. The M4 manual gives me the impression that the PLL for the I2C bus is slaved to SYSCLK, and the audio board (i think?) shares the teensy's I2C, so ... I don't know, it might work, or it might just speed off without SYSCLK. I guess it depends on the design of the I2C PLL.

I suppose i'll have to try it to find out. But I'm wondering what's a good component for, or a good approach to, generating that adjustable clock. I guess I'd be looking for a square-wave or pulse generator that's pretty accurate from very slow rates to reasonably fast ones. It doesn't have to go all the way down to zero, but if the teensy audio board puts out 22khz frequencies at its highest speed, and I want to be able to slow those to the sub-audible range (say, 22hz), then I assume I'd need to adjust the clock down to .001 of its top clock speed -- which I assume would be more like the HSI clock rate (16mhz) than the fancy high-performance PLL rate (96mhz). Is there a clock-generating chip with frequency that can be voltage-controlled from 16khz to 16mhz?

Or is that just crazy? I don't know, I'm still kind of a microprocessor newbie.
 
A simpler thing I could try would be to switch SYSCLK to the high-speed internal clock, and then adjust the tuning on that. I wonder how low that goes ...
 
Oh man, maybe I've been reading the wrong manual. When I search for 'cortex M4', I get all of STI's documentation ... the freescale doc you linked to doesn't say anything about multiple system clock sources ... or, hang on, it does but things have different names ... the HSI is now the Fast Internal Reference Clock. But it's only got four bits of trim, alas.
 
Last edited:
Dumb question here from the manufacturing engineer:

Why not use a PWM output from the Teensy as a OSC input for the other chip while running the Teensy at a constant clock speed? I'd imagine it's a lot easier to vary a PWM output to coincide with specific ADC settings than to mess with the Teensy clock. You could use the PWM signal to trigger interrupts as needed to start ADC sampling, use a DMA buffer, etc. The ADCs in the 3.2 are pretty flexible.... and if they're not flexible enough, then I'd go look for specific external ADC chips that have been developed for your application.

The teensy is an amazing universal tool, but like most universal tools, the designers had to make compromises along the way. Dedicated ADCs that are designed for your application are likely to do a better job and end costing less to implement than the custom front-end that you'd likely have to develop for the Teensy to do an adequate job.
 
mykle said:
Hey, that looks like a really cool project. Is it something I can compile & listen to, or is it still work-in-progress?
Click to expand...

It's both. It's good enough that I'm using it for stuff, but it could also use some improvement, which may or may not ever actually happen.

If you're using the audio adapter board, you're most of the way there.

The important parameteric work is in param_update(), which you might have to adapt to your hardware. I've got 16 pots on all the otherwise unused analog inputs.

If you don't have pots to map the params to, try hardcoding
Code: 
inmix.gain(1, 0.95);
and
Code: 
dlyctrl.amplitude(0.99);
 
Status
Not open for further replies.
Back
Top