jmarsh's latest activity

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...

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...

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...

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...

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...

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...

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...

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...

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...

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...

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...

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.

You don't need TimeLib at all. The applicable code is here in the core: https://github.com/PaulStoffregen/cores/blob/master/teensy4/rtc.c The SNVS_LP* registers refer to the low-power block; that's the module that is kept running by the battery...

How much more space do you need in RAM2 to fit the framebuffer? With some tweaks to the linker script it's possible to reallocate space from RAM1 to RAM2...

It looks like you've used transferSize() when you've intended to use transferCount(). You've also got the second parameter wrong for destinationBuffer(); it should be in bytes, not elements.

I haven't done that, I purposefully avoid having SDRAM as both the source and destination for large copies (whether it's done using the CPU or DMA).

That is correct, because PWM by design has on and off cycles. The hardware doesn't allow either cycle to be 0 length. This is documented on PJRC's website: https://www.pjrc.com/teensy/td_pulse.html

I think it's been mentioned before but the "C" variants of the IMXRT1062 (different from the "D" variants used on the Teensys produced by PJRC) are only nominally rated for 500MHz rather than 600MHz. This means they not only require a higher...

FlexIO: https://github.com/A-Dunstan/SDRAM_EXTMEM/blob/master/examples/flexio_vga/flexio_vga.ino eLCDIF: https://github.com/A-Dunstan/SDRAM_EXTMEM/blob/master/examples/elcdif_vga/elcdif_vga.ino

This example runs a (very stupid) DMA channel to demonstrate: #include <DMAChannel.h> #include <Audio.h> DMAChannel dma(false); AudioSynthWaveform waveform1; AudioOutputI2S audio_out; AudioConnection pc1(waveform1, 0, audio_out, 0)...

Added support for pre-empt/non pre-emptible channels: https://github.com/A-Dunstan/cores/commit/331ad25279fd87351aee8e9ee6b69497339b5b41 The default is the old behaviour (non pre-emptible), so the Audio library and everything else that already...

Change HardwareSerial to HardwareSerialIMXRT.

Try it without using DMAMEM for the array. It looks like that code isn't designed to manage cached memory at all.

TOP stands for turn-off power. As soon as that bit gets set in the LPCR register the power to the CPU (and practically everything else powered by the 3.3V regulator) gets turned off. The rest of the code doesn't run.

A solution to the specific problem in the opening post isn't what I created the thread for. I have other DMA-based code that performs table lookups by poking values into DMA TCDs and chaining them together; it's not triggered by external hardware...

Trying to influence the dice roll of which DMA channel gets assigned to which object is not a solution. There isn't even a way to know which channel the AudioOutputI2S object has been assigned because it's a protected member. I'm thinking maybe...

At least some of those functions are implemented in Teensyduino so I'm not sure why they would be missing symbols. Especially _sbrk, without a proper implementation of that you won't be able to do anything that involves dynamic memory allocation.

USB audio output works fine, that's how I tracked the problem down to the audio DMA channel being starved of runtime. Dynamic object creation doesn't really fix the problem, it just shifts it; in this case my display driver is for a USB device...

I'm having a problem related to Teensyduino's DMAChannels/eDMA module and am curious to hear any suggestions. My project is for the T4. I have display driver code that constantly uses a pair of DMAChannels to render data. These channels are...

This here is your answer. The length argument of the crc32() function is a uint16_t so it can only process up to 65535 bytes of data. Passing in any value higher will get truncated to 16 bits.

This isn't going to work. The audio pins are connected to SAI1 and can't be arbitrarily reassigned. You will need to check the reference manual to see which other pins are possible substitutes, and then hope they're exposed as physical pins on...

I don't think you can. You can't trust the manual here - the "APBDMA only" mode that it talks about practically doesn't exist because the FIFOs have no external entry point. The only way to get data into them is using the dotclock mode, pointing...

If you don't enable DOTCLK_MODE it won't output any data.

This code will infinite loop: void safesetup(){ // inizializzo tutti gli array di celle e pacchetti a valori corretti qui solo le old cell e chiamo safereset for ( uint8_t b = 0; b < cells; b++ ) { myOldCell[b] = 0; } for ( uint8_t b = 0...

Most STM32s are 5V tolerant. The Teensy 4.1 is not. You will damage it with that voltage if you haven't already.

Why are you powering the 74LS241 with 8V? That seems like it would be out-of-spec and is definitely dangerous to connect to the Teensy's RX pin.