Search results

There are four quad timers each consisting of four timer channels (hence the "quad" name). In the first code you're using timer 3 channel 3, in the second code you are using timer 1 channel 1 but set TMR1_ENBL to 8 which turns on channel 3.

That looks like you have loads of free memory available to begin with, which means the out-of-memory issues are most likely caused by trying to allocate too much dynamic memory (using malloc() or new). Moving objects into RAM2 isn't going to help with that, in fact it will make it worse since...

That's going to cost you a lot of performance. It shouldn't be necessary if you handle the caches correctly; copy the executable code to its destination then flush it from the data cache and invalidate the instruction cache on the same range. That's a huge question with no simple answer...

This isn't due to GPR17, that only controls how the first 512KB of ram are configured (RAM1). The problem that you are running into is that the RAM2 section is set as non-executable in the MPU. The MPU is not a Teensy-specific feature, it's part of a standard ARM Cortex-M CPU so the details can...

Did the battery have a load on it when you checked the voltage? Ideally you would check both the voltage and current being drawn by the Teensy at the same time.

Do yourself a favor and just switch to the external RTC. The battery simply doesn't last when trying to keep the Teensy's RTC running for months, it's really only suitable for protecting against short power blackouts.

The crash is when it's trying to write the SD card file, it looks like outPtr has been incremented beyond the end of the array and has collided with the stack canary (a small area of inaccessible memory).

There is no guaranteed order for how these statements will be executed so some may end up with invalid values. You should only initialize values from constants.

At power-up the default pin state is input / tri-state / high impedance so an external pull-up should be fine. There's definitely something fishy about those scope shots; there is no explanation for the voltage being around 1.2V no matter what state the pin is in, assuming there is nothing...

That delay would likely be the USB initialization. There is information about how to reduce this / using the startup hooks to initialize hardware earlier than in startup() on this page: https://www.pjrc.com/teensy/td_startup.html (But, I'm not sure why a physical pull-up on the Teensy's output...

You keep mentioning "2000 lines" in your post but the code doesn't reference anything like that. What is the code that you posted meant to demonstrate exactly?

The breadcrumb memory isn't cleared at startup (because that would potentially wipe any breadcrumbs from a previous run). As a result uninitialized data may be interpreted as valid breadcrumbs. Just ignore them if they're not ones that you explicitly set.

You can have atomic variables (see the c++ std::atomic class) but the issue here is that you have a collection of variables rather than one. You can either disable/enable interrupts (any triggered interrupts will execute when they are re-enabled) or you can change what the interrupt handler does...

All you have to do is cut the join between the pads and solder the diode on...

Your existing code is fine, it's a 32-bit CPU so any direct memory assignment of that size or below will happen as a single operation.

It was discovered that the default voltage setting used in the Teensyduino code is not high enough for the CVJ5B chips even at 528 MHz, it may become unstable under heavy load unless the voltage is set higher.

digitalWriteFast is an inline function that does direct register manipulation.

That's more or less how it is. With the 5-pin plug the second GND is usually connected to the shielding inside the cable and the ground shield around the plug.

^^ This AI generated spambot is wrong, the 4-pin cable DOES have a 5V line, it's only missing an extra ground line which doesn't matter.

The USB plug on the Teensy might be damaged/worn out, micro usbs have a reputation for wearing out.

The usual behaviour of any of the optimization levels besides "smallest code" is to replicate the same code multiple times to avoid branching, so it blows up the size quite significantly. It also uses a much bulkier version of newlib to provide all the basic C functions, rather than newlib-nano.

If you haven't already done so, set the optimize level to smallest code.

I probably should have mentioned, it's also possible to override operator new on a class basis if you wanted to pick and choose which classes utilize extmem. Of course you should also override delete in those cases so the memory for them gets released appropriately.

There's a couple of ways to do this, without resorting to overriding the global new and delete functions. There is placement new; this is a standard c++ feature that lets you explicitly specify the memory location to be used for the new object. So you'd allocate a suitably sized chunk of extmem...

Is that me?

These relay boards nearly always use an opto-isolator to control the relay, they can work safely with a Teensy 4.x only if they have a separate logic VCC instead of connecting the opto-isolators directly to the same voltage supply as the relays.

The IDE lets you specify which port to connect to, look under Tools -> Ports -> Teensy and select a different port if it's using the wrong one.

It just makes the Teensy act as two individual USB serial devices instead of one. The PC should show two serial ports; Arduino IDE serial monitor will connect to one as usual, and you can connect a comms program (or your C/python logger) to log the other one. On the Teensy software side the...

What is the orange wire supposed to be connecting?

Those pads on the bottom go to the second USB port, separate from the one used for programming.

There's also the alternative of simply fooling the uploader so it uploads the hex regardless of the attached model - deleting the .elf file should be enough, since it uses that to check what the target hardware is. Or else you can make a single edit to the linker script so binaries get "tagged"...

I think most of the time when people build their own boards, it's for the purpose of specifically exposing different pins that the default products do not. So editing core_pins.h is required regardless of the flash size.

The source code for the teensy_size program is available on Paul's github, you can modify it and replace the original if you really want to, but personally I just switched to using dynamically allocated RAM (rather than static) so that it has nothing to complain about. I don't think this is...

Size of the flash memory indeed. If you use a 16MB flash it will think it's a Teensy Micromod.

Pin 34 isn't listed as a valid input for FreqMeasureMulti on the T4.1, see the readme: https://github.com/PaulStoffregen/FreqMeasureMulti

"8 bidirectional endpoints" = 8 input endpoints, 8 output endpoints = 16 total.

The bootloader isn't connected to the USB port. What you're probably seeing is the IMXRT's ROM going into serial download mode, which I believe is locked out (via fuses) in the retail Teensys. (Possibly related: see the section titled "Pin 25 Issue")

This isn't true, and also note that input and output endpoints may be completely independent despite possibly sharing the same endpoint number.

I'm not sure what type of content you're displaying but if it's basic stuff that doesn't use too many colors, there's also an 8-bit palette mode (pixels specify a byte index into a 24-bit color palette). It's handy for UIs if you want to support custom colors or simple brightness changes.

I'm pretty sure eLCDIF can extend 16-bit data to 24-bit on its own, copying the highest bits into the lowest to maintain proper range. The ST7277 datasheet says it upconverts the same way, although I would have doubts on a screen that small having a full 8 bits of range anyway.

I have tried to help you, but it seems like you just want someone to write all the code for you and I'm not going to do that.

Well if you're a hardware designer, go read the IMXRT1060 reference manual. Then you can program the DMA TCDs directly to use a minor loop of 32 bytes, reading from memory using 4x 64bit accesses. There's no requirement to only process one word per minor loop.

The CPU has the advantage of either using its data cache or directly accessing the tightly coupled memory (one-cycle access), the DMA engine has to perform bus accesses for every transfer. You're comparing apples to oranges here. (".dtcm" is not a valid section name. I assume that's more AI...

You realize the DMA engine runs on a much lower clock (IPG speed = ~150MHz) than the cpu? And the same applies to the low-speed GPIO registers... I'm not sure why you're focusing on memory-to-memory copies, the thread started out asking how to write continuously to GPIOs.

Using a PIT isn't going to be faster than continuous triggering; it's meant for situations where you want to limit the transfer frequency below the maximum. You're using micros() for timing here, which means the minimum measured time difference will be 0.000001s - that means the highest...

We figured this issue out last year and a fix was committed to Teensyduino, but there hasn't been a proper release since then that includes the fix.

Well, there is one other longshot... The crash report that gets written when a program faults is located right at the end of RAM2. So in theory, if nothing else touches that memory in between (and the device stays powered), you could upload a new sketch that does nothing except print the...

If you use C++ it may be crashing somewhere in a constructor for a static object. Besides commenting them out, you can use the builtin LED to see which ones are completing successfully.

You're doing a lot of String manipulation there, possibly it's running out of heap memory.

Detecting whether a device is connected to the port will not be sufficient to know if an application is ready to communicate. The earlier code you've used, to detect a change in DTR, is the most straightforward way.