Teensy 3.6 Fastest Generated Waveform

Status
Not open for further replies.

DavidTroendle

New member
Colleagues,

Many years ago I used the 8-bit Teensies and really enjoyed working with them. I have an application (virtual floppy drive for old computers) that will require a fast micro controller. The Teensy 3.6 looks it will work, but I am new to the 32-bit Teensies. I have been doing a good bit or reading and watching videos, but still have a few questions.

1. Using a loop sketch that simply toggles an output pin, what is the frequency of the output pin. Here is sample code:

Code:
int SomePin = 2;

void setup()
{
  pinMode(SomePin, OUTPUT);
}

void loop()
{
  digitalWrite(SomePin, !digitalRead(SomePin));
}

2. How stable is the waveform (i.e., is there anything else going on that would interfere with the waveform stability)? For instance, if this done on a device with a pre-emptive OS (e.g., Raspberry Pi), the scheduler injects jitter.

3. I will need a timer interrupt. Does TimerOne.h or some equivalent work on the Teensy 3.6? Could you point me to the documentation if not TimerOne.h?

Thanks in advance, and hope I am within the rules of the forum.

David
 
Using digitalWriteFast() and digitalReadFast() will increase the speed and make it faster. But there are still things like serial communication interrupts, the systick and other things which will be handled between the different loop calls, so there is no warranty for a jitter free waveform until you decide to cut all these interferences by enclosing the line in the loop by while(true){} so that you have your own uninterrupted loop inside the loop. You’ll most probably have to do an additional pin configure register write to take off the slew rate limit for the pin which you want to output that high speed signal.

The TimerOne library is old but will work somehow. A better approach would be using the more modern intervalTimer object to generate periodic interrupts. It’s just a nice wrapper around the Teensy3 Hardware interrupt timers, so that no additional memory and CPU cycles are waisted: https://www.pjrc.com/teensy/td_timing_IntervalTimer.html
 
Using digitalWriteFast() and digitalReadFast() will increase the speed and make it faster. But there are still things like serial communication interrupts, the systick and other things which will be handled between the different loop calls, so there is no warranty for a jitter free waveform until you decide to cut all these interferences by enclosing the line in the loop by while(true){} so that you have your own uninterrupted loop inside the loop. You’ll most probably have to do an additional pin configure register write to take off the slew rate limit for the pin which you want to output that high speed signal.

The TimerOne library is old but will work somehow. A better approach would be using the more modern intervalTimer object to generate periodic interrupts. It’s just a nice wrapper around the Teensy3 Hardware interrupt timers, so that no additional memory and CPU cycles are waisted: https://www.pjrc.com/teensy/td_timing_IntervalTimer.html

Thanks for the very helpful tips. I will look at the intervalTimer object and use the fast version of digital Read/Write..

Just to see if I understand you correctly -- interference can occur, but arises only from sources I can manage. There is no OS nor other threads competing for time.

My question was intended to get some idea of the Teensy 3.6's speed potential. I would like to emulate the floppy disk bit stream directly on an output port (1MHz or so). If needed, I can pump out the bit stream using a SPI port, but my guess is the Teensy 3.6 is capable of flipping a bit a lot faster than 1MHz.

Thanks again,

David
 
Yes, you have control over everything, there is no OS with unpredictable behavior.

But bit banging is never an elegant and smart solution, though. Using an SPI port and DMA to send out a serial data stream with up to 30MHz is much smarter since it will be always more precise and since it will use dedicated subsystems on the Teensy, it will only eat a minimum of CPU cycles, freeing up precious system resources for more intelligent tasks.
 
The code along this thread may be worth a look, though I think you are planing the reverse, having a teensy pretend to be a real drive, not plug a real drive into a Teensy

https://forum.pjrc.com/threads/47434...-on-the-Teensy

If getting serious about this looking at the DMA code in the OCTWS library may be worth a look for getting a DMA driven data stream. A lot more complex than bit bashing though.
 
Status
Not open for further replies.
Back
Top