madmyers

Almost all projects require interrupts, for pretty basic stuff like USB communication and the timing functions like millis(), elapsedMillis, etc. But if you truly don't need any of that stuff and your code is doing to really tight timing, sure...

I read elsewhere than an interrupt takes around 240ns give or take based on cpu speed. Is that right? That’s functional breaking random delay for me. I completely understand many situations wouldn’t care at all about this. I could try and...

A better question might be what works without interrupts. Serial output will eventually stop working. millis() will never update, affecting anything that relies on it or delay(). Anything related to audio or USB definitely won't work.

Thanks! That would seem to mean that disabling then systick_isr (not sure how) would allow me to keep interrupts enabled but avoid any periodic ones, while keeping the automatic firmware download operational. I believe USB serial / automatic...

Until a device is activated the Millis_Tick is the only thing running on interrupt. Losing Button update is known - but USB is disabled with a 'NO USB' build. No active interrupts can be seen with : asm(" wfi"); Even the Millis_Tick "ISR"...

Thanks for the reply. The good news, for me, is that I don't use mills() or delay() and don't need serial. So I'm wondering what other surprises are out there...

Theoritical and kind of real world question. What harm is there in disabling interrupts in setup() and leaving them off? Obviously this prevents functions from running that use interrupts. But is there anything about the Teensy 4.1 that...

Appreciate the insights! I've got a bit of a pin problem so I'm looking into other approaches for the short term (may adjust my PCB longer term if it's needed). @Paul shared some great info about Ethernet in a different thread I started. It...

Another option: DMA_UART. See https://forum.pjrc.com/index.php?threads/using-dma-to-store-uart-byte-directly-in-teensy-3-5.71466/#post-315706 In your 250 ns you’ll have enough time to fill the DMA Tx buffer with up to, say, 64 bytes, and then...

Thanks. I wondered about the mapping of Teensy serial names to UARTs. And based on that info, Pin 4 isn't an option.

Any UART Tx pin could be used. You would need to change the UART the code references but other than that it should be identical. Just take care, the Teensy names and the UART numbers don't match (e.g. in the example Tx1 is not UART1, it's UART6)...

Interesting! To clarify, using the ARM_DWT_CYCCNT will always give the real info. The "probably not to trust" was about expectations based on C code and the compiler?

This is amazing. Thank you! I don't suppose there's a way to do this with Pin 4? My setup currently is using Pin 1 -- but I can change that if needed! -- Altan

Maybe Serial (real hardware serial on TX1) can work if you just write directly to the data transmit register. Just use Serial1.begin(baud) to get the hardware configured, and then rather then Serial1.write() which does complicated buffering...

Yes, I meant the transmit routine must be no more than 250 ns. Thanks for thinking about my problem and asking related interesting questions.

Agreed, the meaning of the question could be read a few different ways. Maybe not really relevant to the original question (or maybe it is?) but I got curious why writing 4 bytes measure so much longer than 1, 2, or 3. So I took a quick dive...

Out of interest what is the latency between putting the data into the tx buffer and the data output starting? If you set a pin high, write the serial data and then set it low how do the signals line up? If you repeat this triggering off the GPIO...

So you need to send a small amount of data but at a very precise time? 250ns is a very tight timing requirement to hit, that's in the same ballpark as the processors interrupt response time. Simply getting the transmit to be within a window that...

It may require interrupts, it depends how much data is currently being queued. delay() doesn't disable interrupts so it's not a concern. I haven't used it myself but several people on the forum regularly recommend TyCommander for serial monitoring.

It's the 2.3.2 IDE. I'm going to give TyCommnader a shot.

Yes. It's the dev/cu.usbmodemXXXXXXX (Teensy 4.1). At least I think that's what you were asking?

I'm looking into running Ethernet directly but I cannot find the right interfaces. I've looked at FNET. I've looked at NativeEthernet. But I don't see anything like a Linux net_device. I did find fnet_return_t...

I'm working on a project with Teensy 4.1. It's very (very!) timing centric and I've got it working. I need to communicate to an external device using whatever method/protocol is best, but "easy" things like Serial take way too time. I'm...

Your post came in while I was writing the other. Thanks -- I was wondering if it's the IDE. I'm running on a Mac (older Intel). Any recommendations for a solid serial read/write program?

Thanks. I'd experimented with that delay -- didn't know why it was there. Good to know! Alas, that hasn't fixed my problem. Does the Teensy USB code require anything to work? For example, interrupts must be enabled? Would doing a...

Don't use F_CPU, use F_CPU_ACTUAL, which despite being all caps is a variable, not a macro, and it gets updated even when you change clock speeds at run-time. You can search the forum for more info.

Thank you. With your info, I can see the function static inline void delayNanoseconds(uint32_t nsec) { uint32_t begin = ARM_DWT_CYCCNT; uint32_t cycles = ((F_CPU_ACTUAL>>16) * nsec) / (1000000000UL>>16); while (ARM_DWT_CYCCNT -...

I've found that I often need to physically power cycle my Teensy to get USB serial logs. I'm using the Arduino IDE. Has anyone run into this? 100% of the time I'll get output if I power cycle, much of the time I'll get no output if I just...

Following up with a clarification about delayNanoseconds --- Does delayNanoseconds adapt for a different CPU speed? For example, perhaps it's coded to work at 600 MHz but not at 912 MHz. I asked because when running at 912 MHz, I noticed...

No, you don't need that for T4.1 because unlike the T3.x, the T4.x core enables the cycle counter by default.

Oh, do I need this in setup still? ARM_DEMCR |= ARM_DEMCR_TRCENA; ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA Saw that in another post

On Teensy using Arduino IDE, you can just use ARM_DWT_CYCCNT. For example: static uint32_t previous = 0; void setup() { } void loop() { uint32_t n = ARM_DWT_CYCCNT; Serial.println(n - previous); previous = n; delayMicroseconds(15); }

Perfect, simple, thanks!

Thanks. I'm away from my Teensy at the moment but did some googling. Does this seem to be an accurate way to use the DWT? https://mcuoneclipse.com/2017/01/30/cycle-counting-on-arm-cortex-m-with-dwt/ Summary: uint32_t cycles; /* number of...

Best way to measure short times is by reading the ARM DWT cycle counter.

For a Teensy 4.1 with Arduino --- I've got some situations where I need to do 10s of nanosecond delays. I've found the delayNanoseconds function, but the documentation is not detailed. Is there a location with hard specifics on this functions...

look in cores/teensy4/imxrt.h

As you can see in cores/teensy/imxrt.h, GPIO9_DR is accessed via a structure where the target member is volatile. The link is to Paul's Github repo for the Teensyduino cores, with each release version having their own tag. It is possible to use...

Just to add a bit more info, long ago we had much simpler defines. But in practice that leads to inefficient code. When each define is just an address, the compiler doesn't "know" they're all the same peripheral. In typical usage where you...

Thanks for the useful replies. So much to learn.

Hey. I'm new to Teensy and using some code that accesses GPIO9_DR. Using the Arduino IDE, I'd like to ensure the definition includes volatile so things like while ( (GPIO9_DR&0x80000000) != 0) {} Don't get optimized out. I've been unable...