Search results

Nop, nop... Who's there? Yup. While most programmers would balk at code-dependent timing, if you use consistent overclock and compiler settings, linear strings of "nops" or loops with them are surprisingly useful. Always use FASTRUN to keep your code in RAM, typically good to use void yield()...

Can anyone explain how to actually code up writing to the ports? On the Teensy 3.6 we easily get 10M reads/writes per second to the (scrambled) ports and with overclocking and tweaking 20 MSPS. I was so excited to get the Teensy 4.0's but no luck so far... Example that works on Teensy 3.6...

Thank you all. I appreciate all of the input and was also interested in all of the side discussions. The current state of this seems to be that there is no significant improvement possible (for now). I'm limiting my work to what would be available to a general user (i.e., student) right out...

Folks, Just to clean up a loose end, I did try "__asm volatile ("dsb");" and even "isb" as some folks have suggested, but it made absolutely no difference in terms of net execution rate and no observable difference in jitter in the test code originally posted at the beginning of this thread...

Thank you all very much. I'm very grateful for the thoughtful responses from folks who obviously know a ton of detail here. If this gets improved, great. If not, I'll remember the effort you all put in. If you ever need help with analog, mixed signal, or sensors, please let me know. Thanks, Greg

Thanks for sharing. I think anyone needing super long delays shouldn't mind a few nanoseconds of error by using multiple delay calls in series... Ok, maybe somebody at NIST is doing a precision version of "Blink," but probably not. :)

Thanks! I did look at IntervalTimer.h and - to my non-expert eyes - it is built for the Kinetis. Changing 36 -> 24 or 12 (in all instances) unfortunately does not help.

I have been working on a lot of low-jitter, fast interrupt applications (mostly precision digital synthesis) using the Teensy 3.6. It's been a great learning experience, and when I come across something that isn't easy to explain (usually needs the code gurus, as I'm mainly a hardware person), I...

Trying basic direct digital synthesis that works perfectly on the 3.6 and getting strange "wobble" in frequency, seems random and is about 10% around the desired frequency. The basic idea is the make a look-up-table of the waveform to be synthesized and "walk through" it based on the top bits of...

Here you go, scope photos in order of your examples. First two: exactly the same, 150 MHz, symmetrical. Last one: 23.077 MHz, symmetrical. 6.5X slowdown.

Incidentally, adding in "__asm__ __volatile__ ("nop\n\t"); for delays does not (yet) work, but this is my main "tried and true" delay mechanism for the Teensy 3.6. Is there something coming for precise code delays? Simply doubling up the HIGH and LOW writes produces exactly 1/2 of the...

Improved measurements... Paul, I don't use social media, but please feel free to post or use anything I put up here. My aim is to help the community. Thank you and your co-developers SO MUCH for the ARM-based Teensy versions. They have been complete game-changers for research, education and, as...

I couldn't help but test the new boards when they arrived. Super simple code, just to see how fast a pin could swing. Answer: 150 MHz. This is done without a load, no (as yet) understanding of slew-rate limiting or not (as implemented on Teensy 3.6), and not the best grounding (hence negative...

I am happy to run any tests you should require. That's why I offered to help on the Teensy 4 (but was told no). I could also loan you an older generation Tek 1GHz digital scope with FET probes if needed.

Ok, one last thing (I can't help it, I'm a nerd). Here is an easy way to "pad" the timing in the logic HIGH phase to get a better duty cycle. As shown below, the code has two "nop" instructions inserted to get the sample rate to 20.1MSPS (not bad) and a duty cycle of about 40% (not great, but...

To see how fast code like this to generate clocks and grap data can run, use a minimalist approach. //Minimalist pin output clock speed test for Teensy 3.6, overclocked at 240 MHz //G. Kovacs, 7/6/19 //Use bit-banging to make a clock for an external ADC and port reads to capture output (later...

Update Just to update this thread, here are the results showing slew-rate-limiting on and off, measured with a 1GHz Agilent MSO-X 4104A and 1GHz active probe (N2765A) and careful lead placement. No news here, but cleaner waveforms. Some have written "beware" of turning...

Oh yes, there is another posting I'd like to make on the weekend on the details. The data from the ADC with the code in my previous (few days ago) posting using the kludgy bit-read-and-shift approach was crap, because the ADC needed about 50% duty cycle on its clock. Digging in deeper revealed...

Thank you very much. In a few weeks, I should be able to send you a fast ADC with DIP adapter. The best bet is a 40Ms/s 10-bit unit I've tested. Awesome. Right now I'm bogged down here... Currently designing an external circuit. There are more issues popping up, such as when you write to an...

Continuing my prior work, I wanted to illustrate some ongoing difficulties with jitter as illustrated by some simple examples. For this test, we will use a 1 GHz bandwidth, 5 Gs/s, oscilloscope with 700 MHz bandwidth passive probes. Here, this is the simplest example of all. Write pulses to a...

Sure - that would be great. Right now, I'm pushing for more speed. I am about to post about what can be done in terms of sample rates with external flash ADC's (not that much without a fairly simple external circuit). My goal was minimal hardware, cheap, open everything, for teaching. I'm not...

So let me please ask a question on the ADC. Assuming you are using the internal 1.2V reference, 16-bit ENOB would require 18 microvolt LSB being above noise. I'm still scratching my chin that a Teensy 3.6 could ever achieve that, let alone at 400+ ksps. I'll try an experiment of simply...

Oh yes, and with no (zero) additional hardware. Adding proper filtering helps a ton, but I'm starting with the minimalist setup to demonstrate quantization noise, aliasing, etc.

Impressive noise level. My 100 ks/s-ish statement was without mention that I'm also using the internal DAC to generate a sine using DDS as a tracking generator for an FFT.

Upper bits of Port C are incorrect in the posted mapping. It is like this: Port C Teensy Pin Notes 12..31 NONE 11 38 10 37 9 36 8 35 7 12 6 11 5 13 LED pin 4 10 3 9 2 23 1 22 0 15

Thanks. That's very cool. I'm not sure looking at your code how to derive a periodic interrupt from that, and for now simply use the Teensy IntervalTimer routine. Internal ADC's cannot keep up except to maybe 100-ish ks/s, so with those I don't need to go faster. For the external ADC stuff...

Thank you and yes, it certainly does. The datasheet from Kinetis is typical of "non-analog" folks. It talks about bits, but not ENOB, which is way, way less than 16. There is no way a chip like could provide 16 bit ENOB at 461 ks/s or people would be using it as an ADC since it would be cheaper...

Thanks. I really appreciate it and understand the overload that happens. Yup, I know about "in hardware" (my area) but software "NOP" tuning can work in tight loops so I don't see it as a no-fly zone. Once had to build a 300 MIPS thingy using ECL. Ha, ha! At least then the manuals weren't 2700...

Man, that would be so awesome! Any guidance as to where to look for the details would be appreciated. Of course, the ISR would have to be fast enough, and as it stands, with my clunky bit-banging to get around port-scrambling, I can barely hit 1.5Ms/s at 16 bits just grabbing the bits, and maybe...

Thank you for your response! The pins could be contiguous - avoiding those that are "blocked" by legacy Arduino stuff the audience out there would need. I have used pins all in a row in my previous "how fast can it go" thread. I have not personally used DMA with the Teensy and was hoping to...

Folks, We need someone who perhaps has read the entire datasheet (joke) and can write some form of extension (I don't really care how it is implemented) that will acquire a burst of 16-bit data (e.g., 512 or 1024 words) from user-specified, likely contiguous (but potentially arbitrary) pins of a...

Well, we at the university worked with TI (Robert Wessels) and brought our own DSP shield to life with a fork of the Arduino iDE (Energia: https://energia.nu/). The problem is that forks require a ton of maintenance or they seem to drift off after a few updates of the parent. If PJRC saw fit to...

That sounds great. Do you know the rough price-point? Even with the PJRC bootloader, the question would be if and how the "clean" ports would be supported. Is there a plan for that? Any chance you could estimate the port update speed? In principle it could be pretty fast...

I apologize for the length of this posting. I'm kind of doing it for the record, so of nobody reads it, fair enough. I'm still a happy nerd. The point here is to make a case for fast I/O. Those of you who have written essentially that "pursuing the fastest X" is pointless, or that "parallel I/O...

May not be correct for Port B After much frustration, I manually mapped Port B and it does not correspond to the chart exactly. In my application, with several libraries at play, pin25 simply did not respond (always read as HIGH) but (interestingly) digitalReadFast(25) *did* work, so my...

I saw the earlier thread from someone that said "talk to Robin about possible bulk pricing." Happily, but... I'm asking independently why there is not a pre-existing pricing structure (e.g, in the PJRC Store) for quantities of 100 or 1000 of something like the Teensy 3.6 (my interest here) that...

Paul, Thank you. Your work is treasured by us, and the Teensy 3.X has been my go-to teaching board for years. I have not seen the beta test thread nor heard of the new Teensy. I'll check it out. I really appreciate your response. I understand the sample rate quantization due to the hardware...

Oh, il est clair que vos intentions sont bonnes! No worries. I did not have any insight into Paul's calendar. :) We have actually been involved in forking the entire Arduino IDE ("Energia" from Texas Instruments). Whew. Not a good plan here, but if you want to see it: https://energia.nu/...

Understood... Request Still Stands - Please Read Thank you for your thoughtful response. I'm not trying to argue, just make my case as an educator. Believe me (28 years as EE professor) I truly do understand substrate-coupled noise and other reasons why ADC's on uP's do not deliver full...

Hoping for Library Additions to Broaden User Base Opportunities Will do. Have not been at the computer. I hope Paul Stoffregen will see this. Two changes to the library would open it up wide for folks doing teaching and science. One is to use the full 3.3V swing. When using the native Teensy...

Thank you very much. I replied to Frank B that when a project is intended to be shared (e.g., with students who may be just starting), editing libraries can be intimidating. Also when the parent library is updated, the process must be repeated. I find that begging the library authors to add a...

Unfortunately, this approach did not work. I was hoping not to have to edit the library so that I could share the project widely. New users (I have taught for a long time) often are intimidated by editing libraries, and then when the parent library is updated by the author, have to do it again...

Thank you for your kind response. However, it is the solid FFT and filter routines of the audio library that makes me stick with it, and I'm well aware of the various ADC functions and libraries out there. I am exploring designing a broad-band, heterodyned FFT (PSA architecture) spectrum...

Folks, Does anyone know how to change the reference voltage for the audio library from 1.2 to 3.3V? I am using it for non-audio projects and need to take inputs with maximum dynamic range. Any help would be appreciated. Thanks, Greg

Normally, when I try a new "Arduino-ish" board, I start with a simple bit-banging test, just taking the delays out of "Blink" as below: /* Blink Turns on an LED on for one second, then off for one second, repeatedly. This example code is in the public domain. */ // Pin 13 has an LED...