Recent content by Marcus LaGrone

and the code...(just modified from the example at this point!): #include <TimerOne.h> #include "SBUS.h" SBUS x8r(Serial1); volatile uint16_t ain[16]; void setup() { Serial.begin(1000000); x8r.begin(); Timer1.initialize(9000); // 7-14ms is what I found online... both ext work... left...

I'm using the SBUS library to talk to a DJI Ronin-S Gimbal. (example of someone else using a Futaba: https://www.youtube.com/watch?v=bQW3NOoDCOw ). The first 4 channels all play nice, Pan, Tilt, Roll, and what I think is focus control... the next three channels (based on other people stuff)...

I have a propshield that after a weeks worth of use the audio went south and the amplifer gets scorching hot. I assumed I had done something odd to it so I got a brand new one, soldered a (brand new) teensy 3.2 to it (after I had cut the USB 5V trace) and went to program it. and... my bench...

Haven't tried cooling yet... this is how things look with more samples: 3 of 9 Teensy 3.6 @ 240 MHz jitter 1 of 9 Teensy 3.1 @ 216 MHz jitter none are a problem @ 192 MHz and lower... I CAN run all the code (still double checking) fast enough at 192 Mhz to make this work (thank you FASTRUN!!!!)...

A few rounds of changes later and using FASTRUN the code is now faster with "Faster w LTO" as opposed to "smallest" quick question, is there any way to tell the compiler (Teensyduino) to stick EVERYTHING in RAM if possible? I can stick "FASTRUN" all over hither and yon, but having it also...

So what is the practical difference between RAMFUNC and FASTRUN? FASTRUN has been helpful today! Wish I had seen it earlier... --mjlg

If anyone is curious, that is what a Teensy 3.6 looks like under long wave infrared (8-12um). (temperature is not calibrated in the image). The Teensy is overclocked to 240MHz and is mostly busy, as it were. The nice shiny metal parts are showing a strong reflection, hence the colder color. One...

I continue to be amused when inline does and doesn't offer an improvement in speed... 1d6 please :P --mjlg

I have a very math intensive bit of code running a giant pile of things that also include a bunch of LUTs. So I sat down to see which of the various optimizations gave me the fastest code. Space? who cares! I want speed! So, at the start of the code I throw a pin high and at the end, throw it...

Pardon me as I can't post my code, but maybe someone can direct me where to poke the Teensy: I have code that runs fine on a Teensy 3.6. It is running Optimised Fastest with LTO and is overclocked to 240MHz. Everything is awesome (cue music). However... I have three of these on the same...

okay, either of those two approaches work fine, so I'm going to stop messing with it while I am ahead! I double checked this morning (after everything had been off a while) just to make sure it wasn't an odd computer (PC) glitch and I still get the same behavior of: working not #include, error...

not sure if this is a bug or if I am missing something. I'm porting something over from a Due to test on a Teensy 3.6 I have a giant LUT that I have as a separate file (for readability on my part). it is a table of 12801 entries. I have used both PROGMEM (which is what I did in the Due) and...