Recent content by dukeblue219

Thanks to Paul, Robin, and numerous posters here for their designs, coding, and support over the last 6 years. I have used Teensy 3.1, 3.2, 3.6, 4.0, and now 4.1 to successfully execute single-event effects testing of numerous digital devices in direct support of NASA flight programs and...

For anyone who stumbles across this thread, yes, it can be done. Not the right tool for the job necessarily, but it worked with the timing tweaked just right with nops.

This is going to sound crazy to anyone who knows enough to answer, but has anyone attempted to essentially bit-bang an NV-DDR3 interface or similar on a modern NAND device at the lowest speed modes? For background I have experience doing this with Teeny 3.x and 4.0 to older asynchronous flash...

I would be very curious in your results. I'll be at TAMU next week and might have a chance to run a Teensy in the K150 but TBD, it's low priority.

Small update since this thread got bumped. The T4.0 is my current controller for certain digital components that need radiation testing. I've been killing them off occasionally when used near, but not in, the beam line (at LBNL, not TAMU, but similar energies). I'm guessing the bootloader is...

It's been a couple years since I got everything working but you can definitely pull data into Python on Windows 10 at 10MB (yes bytes) per second from a T4. You'll need to scoop the data in large chunks and spend some time profiling your Python to find out where it slows down. Any real-time...

Great news about the USB. I'll check it out as soon as I can and see if the occasional stall has been fixed.

Just a followup note that the T4 ran great in a vacuum chamber at 600MHZ once it was installed on a PCB. The PCB had aluminum standoffs to mount on a large steel platform, and the holes for the standoffs were plated and tied to the PCB grouns. No thermal strap or active cooling, and it sat...

16 bits at once is going to suck, no doubt about it. For two 8-bit buses on T4 I made it work by reading a 32 bit register (GPIO6_PSR and GPIO7_PSR) and then scrambling it with a macro I can drop into my code that reorders the pins I'm using into a normal byte. This would never be fast if you...

I had to rewrite a lot of fast code that was using GPIOC_PDIR, GPIOD_PDOR etc from Teensy 3.6 when I moved to the 4.0. Using individual digitalreadfasts wasn't an option since I needed the fastest-possible reads in parallel. Unfortunately it's really a pain that there's not a full, in-orderbyte...

Understood. I have no complaints as it is right now. Certainly if I needed a fixed high-bandwidth solution an FPGA would be a more logical choice, with more headaches for me. I really appreciate the several-x increase in Teensy-to-PC throughput from 3.6 to 4.0. That pretty much matches my...

For many people it is, but even then, the program should still work without crashing. I, however, could easily generate 50MB/s of serial data to a PC, though I'm not able to get that on the USBHS implementation. I recall that I'm seeing around 7MB/s right now on T4. I use a Python GUI to log it...

How did I miss that? Apologies for the unnecessary question, but thanks to you and mjs513 for the very clear responses. I'll give it a test today.

Is there a straightforward way to adjust this at runtime rather than tinkering with startup.c?

To echo what Paul said, using either of those parts is not a trivial solder-at-home task. That .65mm pitch is going to be a pain in the butt to hand place, even if you have an oven. You'll never know for sure that you soldered it right even if it looks stuck in place, and without some electrical...