Latest activity

I actually tested it with a bunch of values, and it only works if the number of blocks is odd. I think it comes from the fact that the input is stereo while the output is mono, so it is not possible for the input queues to allocate everything...

Ideally all the wires from mcu to motor driver should go through the same ferrite so it removes common-mode interference but doesn't add differential mode interference. Definitely add 10nF to 100nF on those limit switch inputs next to the mcu...

For the sake of testing, I'd try allocating many more blocks, like 100. Then if you see your usage is in the 90s, you'll know one or more of the queues is hogging memory.

Have the SDRAM board wired up to the ER-TFT101-1 display. DMA is working on it as well as the MicroMod, sort of! This is the test sketch I am using modified to include SDRAM usage: #include "RA8876_t3.h" #include "SDRAM_t4.h" #include...

Ideally all the wires from mcu to motor driver should go through the same ferrite so it removes common-mode interference but doesn't add differential mode interference. Definitely add 10nF to 100nF on those limit switch inputs next to the mcu...

If the system is starved of blocks odd things can happen if something is freeing blocks at all, don't take the fact it "works" with 11 to mean its properly working, for if it were 12 would definitely work too.

Merged: https://github.com/Defragster/EVKB_1060/blob/main/docs/DogBoneSDRAMv1.xlsx

Merged: https://github.com/Defragster/EVKB_1060/blob/main/docs/DogBoneSDRAMv1.xlsx

Sorry, I did not go all the way up on the SS to those pins... I have now... Exactly. Pushed up current version to fork of defragsters github project and issued PR https://github.com/Defragster/EVKB_1060/pull/1

Merged: https://github.com/Defragster/EVKB_1060/blob/main/docs/DogBoneSDRAMv1.xlsx

Merged: https://github.com/Defragster/EVKB_1060/blob/main/docs/DogBoneSDRAMv1.xlsx

Sorry, I did not go all the way up on the SS to those pins... I have now... Exactly. Pushed up current version to fork of defragsters github project and issued PR https://github.com/Defragster/EVKB_1060/pull/1

Sorry, I did not go all the way up on the SS to those pins... I have now... Exactly. Pushed up current version to fork of defragsters github project and issued PR https://github.com/Defragster/EVKB_1060/pull/1

Sorry, I did not go all the way up on the SS to those pins... I have now... Exactly. Pushed up current version to fork of defragsters github project and issued PR https://github.com/Defragster/EVKB_1060/pull/1

@KurtE here is the full list. Need to update B0_00 through B0_03 accordingly

Thanks, @mjs513 (and others), I updated again the dogbone... excel document all of the LCD pins on the right hand side of the board were filled in. I think it should look like: Will send the document back to you and/or could try to do PR with...

B0_00 is LCD_CLK, B0_01 is LCD_ENABLE, B0_02 is LCD_HSYNC. I guess you could have either a 24-bit LCD, or a 10/16 bit camera without running into conflicts. But still, not with the current board due to the missing CSI data pins.

@KurtE here is the full list. Need to update B0_00 through B0_03 accordingly

Thanks, @mjs513 (and others), I updated again the dogbone... excel document all of the LCD pins on the right hand side of the board were filled in. I think it should look like: Will send the document back to you and/or could try to do PR with...

@KurtE the dev board has all the eCLDIF pins exposed. Starting from B0_00 to B1_13 I believe. I posted here a few weeks back that I got it working on a 24 bit display with SDRAM.

Right, and the EVK board has the display wired at 16 bits to free up the rest of GPIO_B1

Right, and the EVK board has the display wired at 16 bits to free up the rest of GPIO_B1

LCDIF, CSI, and PXP all have their own masters. Their priorities (against each other) are controlled by the SIM_MAIN NIC registers. The documentation hints that LCDIF has a bunch of cache memory tucked away inside of it, that isn't directly...

Right, and the EVK board has the display wired at 16 bits to free up the rest of GPIO_B1

I wonder if there are any hints on this on how they use SDRAM with CSI in the 1050 document https://www.nxp.com/docs/en/application-note/AN12110.pdf

@KurtE the dev board has all the eCLDIF pins exposed. Starting from B0_00 to B1_13 I believe. I posted here a few weeks back that I got it working on a 24 bit display with SDRAM.

I think the way they organised the pins was intended for an 8-bit camera connected to CSI and a 16-bit (parallel) display connected to LCDIF. Anything higher in either case and you run out of pins due to them being shared between the modules.

@KurtE the dev board has all the eCLDIF pins exposed. Starting from B0_00 to B1_13 I believe. I posted here a few weeks back that I got it working on a 24 bit display with SDRAM.

True, I have not really studied the LCDIF as I don't think we have had any boards that have enough pins exported to use. I might take a look and see if we added the 3 or 5 pins mentioned in yesterdays post about CSI... If both would be covered...

Is this any chance that the ground wire between the Teensy and the motor driver (with the ferrite bead) is forming a ground loop?

True, I have not really studied the LCDIF as I don't think we have had any boards that have enough pins exported to use. I might take a look and see if we added the 3 or 5 pins mentioned in yesterdays post about CSI... If both would be covered...

At the time of printing you've only assigned a value to CycleTime[i-1], not CycleTime[ i ].

The set up is: Teensy4.1 Adafruit bmp388 over I2C openSUSE Leap 15.3 Arduino 1.8.19 teensyduino 1.59 I got a interestring result with the function micros() in combination with one/two do while loops. The code with OneLoop measures and...

Looks like the method: int vprintf(const char *format, va_list ap) { return vdprintf((int)this, format, ap); } Was added last year (May 2023) Wonder if they should have not put the implementation of it within print.h but instead into print.cpp...

You're right... the mono code uses 9 blocks while the stereo one uses 10 (maximum). So I increased the audio memory to 11, and it works! Then, I started to become crazy because increasing the audio memory is the first thing I tried. So, I did a...

They're using LCDIF (and PXP) to output to the display... which is pretty tricky considering the amount of pins shared between CSI and LCDIF... but the main note is they're explicitly not using the eDMA module which is where the slowdown seems to...

Try using AudioMemoryUsage() to monitor how many of the 10 audio memory blocks are used up. Or use AudioMemoryUsageMax() to check whether you have at any point used up all the memory. My guess, admittedly from only a quick glace at your code, is...

I wonder if there are any hints on this on how they use SDRAM with CSI in the 1050 document https://www.nxp.com/docs/en/application-note/AN12110.pdf

I find it odd that SDRAM is not working well with FlexIO & DMA.. On the original version of the devboard, @Dogbone06 has just standard T4.1 PSRAM, and I was able to use a frame buffer in there with my Micromod 8080 library without any issues...

That was an interesting forum post especially if you read all the way through it. The fix they recommended was basically to change both BCMRX registers to 0x81...

LCDIF, CSI, and PXP all have their own masters. Their priorities (against each other) are controlled by the SIM_MAIN NIC registers. The documentation hints that LCDIF has a bunch of cache memory tucked away inside of it, that isn't directly...

That was an interesting forum post especially if you read all the way through it. The fix they recommended was basically to change both BCMRX registers to 0x81...

@mjs513, looks interesting. Wonder what the differences are from the DMA and non-dma? Other than the obvious. Like when we are not using DMA operation, the new data is written to the cache, and only later, when necessary, it flushes it out to...

I find it odd that SDRAM is not working well with FlexIO & DMA.. On the original version of the devboard, @Dogbone06 has just standard T4.1 PSRAM, and I was able to use a frame buffer in there with my Micromod 8080 library without any issues...

We finally have DMA working properly on the MicroMod and presumably the SDRAM Dev Board (not tested yet). My MicroMod quit while testing the 8080 mode for the ER-TFTM101-1 display. Had to reposition the MCU board in the connector. It's working...

Thanks for the quick response. I can see the code is now using the right (?) library, but the error is still the same: C:\Users\*****\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.59.0\libraries\ShiftPWM\CShiftPWM.cpp: In destructor...

Hello Paul, thanks for taking the time to answer my question. I have reviewed all the libraries and their respective licenses. For those under the MIT license, everything seems straightforward. However, with libraries licensed under LGPL 2.1...

Here is the mnimal code (using the original i2s objects) reproducing the problem: #include <Audio.h> #include <arm_const_structs.h> #include <utility/imxrt_hw.h> #include <SD.h> #include <SPI.h> File dataFile; const int...

Switching back from platform teensy 5.0.0 to older platform with: platform = teensy@4.18.0 does the trick. But why does teensy 5.0.0 rise this problem?

Thanks for reminding me about that example. I had already looked at it could not work out what it actually did! I will go back to and rejig it for platformio.