Diy teensy sdram solder yourself

theboot900 · May 19, 2025

Rezo said:
Could you share the codebase for this test?

I have 7” 800*480px display with the same driver and will be hooking it up to my Devboard V5 when the adapter PCBs arrive, and have been considering use of the PXP to write rectangle clips to the main eLCDIF buffer for LVGL partial mode implementation (to improve render/write times and as much non blocking transactions)

Sure. Give me a bit though to tidy it up. At the moment im running 3 seperate projects for simplicities sake. 32 bit, 24 bit and 16 bit, as all the primitive drawing routines take in different colour values.

Dogbone06 said:
I recently made a super nice PCB with lots of outputs and sensors. It runs stable on 221MHz, but I use the same SDRAM layout for all boards. I keep it simple by copying the "bare minimum" straight over to any new project that is similar. So I use that 10pF cap that me and Defragster decided on when we tested back in the day.

I guess different designs makes for different results, it just proves that layout is super hard!

Exactly! It took me the third itteration to get this board right. The first 2 efforts i kept getting 9 blinking lights (Unknown error) . I thought it was my power delivery or my soldering. Yet the Bootloader was marrying and locking itself to the IMXRT1060 chip.

Turns out after a good close look at the schematic i was missing the 2 DCDC ground connections. So my voltage's where all showing as good, however the internal DCDC converter was not grounded properly.

Have you got a photo of your latest pcb?

theboot900 · May 19, 2025

I did some tests running the backbuffers and display in rgb565 mode (Sdram clocked at 198mhz again)
Backbuffer size is 384000 * uint16_t. All this is done while the LCDIF is outputting to the display at 50hz

Pixel Pipeline time clearing the backbuffer with no CPU access. 8.66 milliseconds
No Pixel Pipeline CPU Clearing the backbuffer. 2.18 milliseconds
Pixel Pipeline time clearing the backbuffer, while the CPU also writes 1 full fill to the mid buffer. 9.9 milliseconds
Pixel Pipeline clearing the backbuffer while the CPU writes 5 full fills to the midbuffer
- Pixel Pipeline takes 19.6 milliseconds
- CPU takes 10.94 milliseconds
Without Pixel pipeline, CPU just doing 9 full fills to the backbuffer
- CPU takes 19.8 milliseconds

Looking at the raw performance. With the pixel pipeline doing a full clear of the back buffer. the CPU can do 5 full writes to the mid buffer, before the Pixel Pipeline takes longer than 20 milliseconds (A full frame length)

Alternatively, if we don't use the pixel pipeline we can do 9 full fills to the buffer just via using the CPUwithin that 20 milliseconds.

My take on this,

The Sdram struggles a bit when there is 3 things accessing it at the same time.
The Pixel pipeline is a bit slower than i expected. Even though its simply just doing a 1 colour fill, perhaps there is more going on there. Would standard DMA be faster?
I should test the running the PXP to clear the buffer without the LCDIF being output
I can understand why back in the early windows 95 days they used 16 bit colour, especially in software rendering. Its a lot less bandwidth, and a lot less memory.

theboot900 · May 23, 2025

I tried some full sized images, 800 x 480 in 24 bit packed format. Not using the pixel pipeline. The fastest i could get was:

Image in SDRam, reading from SDram then copying into the Backbuffer on SDRam. 13.9 milliseconds
Image saved to onboard Flashmem. Then read to back buffer. 16.2 milliseconds.

I then tried images in 16 bit. This seems like the sweet spot and the images dont really look any different. On these IPS panels adjacent pixels seem to blend in to each other anyway - so on a colorful image its hard to tell on the lower BPP. The real down side to 16 bit is banding when your doing colour gradient backgrounds etc. Copying is down by reading each image row into a buffer from sdram on the stack, then outputting that buffer 1 row at a time to sdram.

Image in SDRam reading from SDram then copying into the Backbuffer on SDRam. 8.6 milliseconds
Imaged saved to onboard Flashmem. Then read to back buffer. 11.3 milliseconds

I think 16 bit is the sweet spot. We can do full image shows in 8.6 milliseconds. We can clear a full back buffer in one colour in 2.18 milliseconds.

I havent tried an image copy on the PXP yet, but i assume that will be a lot slower than just a simple pixel fill. Also will try Image scaling.

theboot900 · May 24, 2025

Did some nearest neighbour image scaling using software. (I'm pretty sure the PXP uses nearest neighbour too)

I couldnt get Bilinear filtering work, however i think that would be way to slow in software

Nearest neighbour is quite quick.

Reading and writing non scaled 800 x 480 image from sdram to sdram backbuffer is 8.6milliseconds

Scaling the image ever so slightly (about 95% of its original size) , including reading the image from sdram and saving to sdram backbuffer is about 10 milliseconds.

And that time drops considerably - when the image is scaled to half the size it takes about 5 milliseconds. At 10% of its original size its half a millisecond (As we are only traversing the scaled down output image)

https://imgur.com/a/JDfmmCS

theboot900 · May 24, 2025

Whats interesting. Zooming in is actually a lot faster too. As when we are zoomed in there is a lot less of the source image to read from sd ram (We only read the rows required to go to the destination image) So zoomed in at its peak in the video is only 5 milliseconds to read SDRam, scale, then output to SDram backbuffer

https://imgur.com/a/yd24sxS

jmarsh · May 24, 2025

theboot900 said:
(I'm pretty sure the PXP uses nearest neighbour too)

PXP uses 12 bit bilinear, at least according to the documentation. There's even diagrams and equations on pages 1914/1915.

theboot900 · May 24, 2025

jmarsh said:
PXP uses 12 bit bilinear, at least according to the documentation. There's even diagrams and equations on pages 1914/1915.

Interesting!!

Rezo · May 24, 2025

Could you run a test to measure the time it takes the pxp to copy an 800x164px block (16bpp) from DMAMEM to SDRAM as well as SDRAM to SDRAM?

BTW, seems like I have the same panel as you - 7” IPS from BuyDisplay

theboot900 · May 24, 2025

Rezo said:
Could you run a test to measure the time it takes the pxp to copy an 800x164px block (16bpp) from DMAMEM to SDRAM as well as SDRAM to SDRAM?

BTW, seems like I have the same panel as you - 7” IPS from BuyDisplay

Yes its a pretty good panel. I had the non IPS version from them before which was not as good (When viewing from the side the colours seemed to change) The only downside is the 2 Ziff cables are far away from each other.

I had gone away fromm the pixel pipeline but found an old build with it. I tried adding image copy through the pxp and tried the test, but im not very confident with it. It seemed to be doing something but was outputting black on the display where i was copying the image. Not sure if its caching issues but i couldnt figure it out.

Increasing the image size was making it take longer so i think it might have been working. But i wasnt getting real difference in times from main ram and sdram. Either its my test (Highly likely), or the pixel pipeline is the limiting factor

Ram1 was 3058 microseconds
DMA Mem was 3066 microseconds
SDRam was 3062 microseconds

If you manage to get the test done let me know what you get.

Rezo · May 26, 2025

Did some initial testing with an older DBv4.5 (has the DQS cap, and can't get it to init over 133Mhz)
Will try the DB5 later at 166/198/221 and see how if affects numbers

Meanwhile, here is 133Mhz SDRAM, transferring 800*240*2 bytes from one buffer (RAM1/RAM2/SDRAM) to SDRAM
Also did 800*480*2 from SDRAM to SDRAM

Code:

SDRAM 133Mhz init SUCCESS :) ...
Time to copy 800*240*2 bytes from RAM1 to RAM2: 1607 uSec
Time to copy 800*240*2 bytes from RAM1 to SDRAM: 8405 uSec
Time to copy 800*240*2 bytes from RAM2 to SDRAM: 8405 uSec
Time to copy 800*240*2 bytes from SDRAM to SDRAM: 9754 uSec
Time to copy 800*480*2 bytes from SDRAM to SDRAM: 10822 uSec

theboot900 · May 26, 2025

Rezo said:
Did some initial testing with an older DBv4.5 (has the DQS cap, and can't get it to init over 133Mhz)
Will try the DB5 later at 166/198/221 and see how if affects numbers

Meanwhile, here is 133Mhz SDRAM, transferring 800*240*2 bytes from one buffer (RAM1/RAM2/SDRAM) to SDRAM
Also did 800*480*2 from SDRAM to SDRAM

Code:

SDRAM 133Mhz init SUCCESS :) ... Time to copy 800*240*2 bytes from RAM1 to RAM2: 1607 uSec Time to copy 800*240*2 bytes from RAM1 to SDRAM: 8405 uSec Time to copy 800*240*2 bytes from RAM2 to SDRAM: 8405 uSec Time to copy 800*240*2 bytes from SDRAM to SDRAM: 9754 uSec Time to copy 800*480*2 bytes from SDRAM to SDRAM: 10822 uSec

How are you doing the copy sdram to sdram?

Just a memcopy? I found it faster to burst read an image row (800 x uint16_t) into a local buffer on the stack, then output that in a burst back to sdram.

Rezo · May 26, 2025

Everything is done with the PXP for this test as I am looking to see what performance I can get with async copies

C++:

PXP_init();
  memset(s_fb, 0, sizeof(s_fb));
  memset(d_fb, 0x01, sizeof(d_fb));
  memset(ext_d_fb, 0x02, sizeof(ext_d_fb));
  memset(ext_s_fb, 0x03, sizeof(ext_s_fb));

  PXP_input_format(PXP_RGB565, 0, 0, 0);
  PXP_output_format(PXP_RGB565, 0, 0, 0);

  PXP_output_buffer((uint16_t*)d_fb, 2, 800, 240);
  PXP_input_buffer((uint16_t*)s_fb, 2, 800, 240);
  PXP_input_position(0, 0, 799, 239);
  startTime = micros();
  PXP_process();
  PXP_finish();
  Serial.printf("Time to copy 800*240*2 bytes from RAM1 to RAM2: %u uSec \n", micros()-startTime);

  PXP_output_buffer((uint16_t*)ext_d_fb, 2, 800, 480);
  PXP_input_buffer((uint16_t*)s_fb, 2, 800, 240);
  PXP_input_position(0, 0, 799, 239);
  startTime = micros();
  PXP_process();
  PXP_finish();
  Serial.printf("Time to copy 800*240*2 bytes from RAM1 to SDRAM: %u uSec \n", micros()-startTime);

  PXP_output_buffer((uint16_t*)ext_s_fb, 2, 800, 480);
  PXP_input_buffer((uint16_t*)s_fb, 2, 800, 240);
  PXP_input_position(0, 0, 799, 239);
  startTime = micros();
  PXP_process();
  PXP_finish();
  Serial.printf("Time to copy 800*240*2 bytes from RAM2 to SDRAM: %u uSec \n", micros()-startTime);

  PXP_output_buffer((uint16_t*)ext_d_fb, 2, 800, 480);
  PXP_input_buffer((uint16_t*)ext_s_fb, 2, 800, 480);
  PXP_input_position(0, 0, 799, 239);
  startTime = micros();
  PXP_process();
  PXP_finish();
  Serial.printf("Time to copy 800*240*2 bytes from SDRAM to SDRAM: %u uSec \n", micros()-startTime);

  PXP_output_buffer((uint16_t*)ext_d_fb, 2, 800, 480);
  PXP_input_buffer((uint16_t*)ext_s_fb, 2, 800, 480);
  PXP_input_position(0, 0, 799, 479);
  startTime = micros();
  PXP_process();
  PXP_finish();
  Serial.printf("Time to copy 800*480*2 bytes from SDRAM to SDRAM: %u uSec \n", micros()-startTime);

@jmarsh is there an option to overclock the PXP module? I don't see any mention of it in the RM

theboot900 · May 26, 2025

Rezo said:

Everything is done with the PXP for this test as I am looking to see what performance I can get with async copies

C++:

PXP_init();
  memset(s_fb, 0, sizeof(s_fb));
  memset(d_fb, 0x01, sizeof(d_fb));
  memset(ext_d_fb, 0x02, sizeof(ext_d_fb));
  memset(ext_s_fb, 0x03, sizeof(ext_s_fb));

  PXP_input_format(PXP_RGB565, 0, 0, 0);
  PXP_output_format(PXP_RGB565, 0, 0, 0);

  PXP_output_buffer((uint16_t*)d_fb, 2, 800, 240);
  PXP_input_buffer((uint16_t*)s_fb, 2, 800, 240);
  PXP_input_position(0, 0, 799, 239);
  startTime = micros();
  PXP_process();
  PXP_finish();
  Serial.printf("Time to copy 800*240*2 bytes from RAM1 to RAM2: %u uSec \n", micros()-startTime);

  PXP_output_buffer((uint16_t*)ext_d_fb, 2, 800, 480);
  PXP_input_buffer((uint16_t*)s_fb, 2, 800, 240);
  PXP_input_position(0, 0, 799, 239);
  startTime = micros();
  PXP_process();
  PXP_finish();
  Serial.printf("Time to copy 800*240*2 bytes from RAM1 to SDRAM: %u uSec \n", micros()-startTime);

  PXP_output_buffer((uint16_t*)ext_s_fb, 2, 800, 480);
  PXP_input_buffer((uint16_t*)s_fb, 2, 800, 240);
  PXP_input_position(0, 0, 799, 239);
  startTime = micros();
  PXP_process();
  PXP_finish();
  Serial.printf("Time to copy 800*240*2 bytes from RAM2 to SDRAM: %u uSec \n", micros()-startTime);

  PXP_output_buffer((uint16_t*)ext_d_fb, 2, 800, 480);
  PXP_input_buffer((uint16_t*)ext_s_fb, 2, 800, 480);
  PXP_input_position(0, 0, 799, 239);
  startTime = micros();
  PXP_process();
  PXP_finish();
  Serial.printf("Time to copy 800*240*2 bytes from SDRAM to SDRAM: %u uSec \n", micros()-startTime);

  PXP_output_buffer((uint16_t*)ext_d_fb, 2, 800, 480);
  PXP_input_buffer((uint16_t*)ext_s_fb, 2, 800, 480);
  PXP_input_position(0, 0, 799, 479);
  startTime = micros();
  PXP_process();
  PXP_finish();
  Serial.printf("Time to copy 800*480*2 bytes from SDRAM to SDRAM: %u uSec \n", micros()-startTime);

@jmarsh is there an option to overclock the PXP module? I don't see any mention of it in the RM

Very nice!!! The 800 x 480 x 2 seems pretty quick.

As an aside. You could try and allocate the buffers into different banks of memory (think it's 4 x 4mb each spaced sequentialy) im curious if that makes a difference. I believe there's a little less switching required on the sdram.

jmarsh · May 26, 2025

Rezo said:
@jmarsh is there an option to overclock the PXP module? I don't see any mention of it in the RM

There's no selectable clock for PXP, it just runs off IPG (which is usually the cpu clock divided by 4).

Rezo · May 26, 2025

More testing on DB5:

SDRAM@133Mhz

Code:

Time to copy 800*240*2 bytes from RAM1 to RAM2: 1607 uSec
Time to copy 800*240*2 bytes from RAM1 to SDRAM: 8406 uSec
Time to copy 800*240*2 bytes from RAM2 to SDRAM: 8405 uSec
Time to copy 800*240*2 bytes from SDRAM to SDRAM: 9753 uSec
Time to copy 800*480*2 bytes from SDRAM to SDRAM: 10822 uSec

SDRAM@166Mhz

Code:

Time to copy 800*240*2 bytes from RAM1 to RAM2: 1607 uSec
Time to copy 800*240*2 bytes from RAM1 to SDRAM: 7086 uSec
Time to copy 800*240*2 bytes from RAM2 to SDRAM: 7085 uSec
Time to copy 800*240*2 bytes from SDRAM to SDRAM: 8147 uSec
Time to copy 800*480*2 bytes from SDRAM to SDRAM: 8932 uSec

SDRAM@198Mhz

Code:

Time to copy 800*240*2 bytes from RAM1 to RAM2: 1606 uSec
Time to copy 800*240*2 bytes from RAM1 to SDRAM: 6544 uSec
Time to copy 800*240*2 bytes from RAM2 to SDRAM: 6541 uSec
Time to copy 800*240*2 bytes from SDRAM to SDRAM: 7521 uSec
Time to copy 800*480*2 bytes from SDRAM to SDRAM: 8218 uSec

SDRAM@221Mhz

Code:

Time to copy 800*240*2 bytes from RAM1 to RAM2: 1606 uSec
Time to copy 800*240*2 bytes from RAM1 to SDRAM: 5960 uSec
Time to copy 800*240*2 bytes from RAM2 to SDRAM: 5960 uSec
Time to copy 800*240*2 bytes from SDRAM to SDRAM: 6801 uSec
Time to copy 800*480*2 bytes from SDRAM to SDRAM: 7365 uSec

theboot900 · May 27, 2025

Rezo said:

More testing on DB5:

SDRAM@133Mhz

Code:

Time to copy 800*240*2 bytes from RAM1 to RAM2: 1607 uSec
Time to copy 800*240*2 bytes from RAM1 to SDRAM: 8406 uSec
Time to copy 800*240*2 bytes from RAM2 to SDRAM: 8405 uSec
Time to copy 800*240*2 bytes from SDRAM to SDRAM: 9753 uSec
Time to copy 800*480*2 bytes from SDRAM to SDRAM: 10822 uSec

SDRAM@166Mhz

Code:

Time to copy 800*240*2 bytes from RAM1 to RAM2: 1607 uSec
Time to copy 800*240*2 bytes from RAM1 to SDRAM: 7086 uSec
Time to copy 800*240*2 bytes from RAM2 to SDRAM: 7085 uSec
Time to copy 800*240*2 bytes from SDRAM to SDRAM: 8147 uSec
Time to copy 800*480*2 bytes from SDRAM to SDRAM: 8932 uSec

SDRAM@198Mhz

Code:

Time to copy 800*240*2 bytes from RAM1 to RAM2: 1606 uSec
Time to copy 800*240*2 bytes from RAM1 to SDRAM: 6544 uSec
Time to copy 800*240*2 bytes from RAM2 to SDRAM: 6541 uSec
Time to copy 800*240*2 bytes from SDRAM to SDRAM: 7521 uSec
Time to copy 800*480*2 bytes from SDRAM to SDRAM: 8218 uSec

SDRAM@221Mhz

Code:

Time to copy 800*240*2 bytes from RAM1 to RAM2: 1606 uSec
Time to copy 800*240*2 bytes from RAM1 to SDRAM: 5960 uSec
Time to copy 800*240*2 bytes from RAM2 to SDRAM: 5960 uSec
Time to copy 800*240*2 bytes from SDRAM to SDRAM: 6801 uSec
Time to copy 800*480*2 bytes from SDRAM to SDRAM: 7365 uSec

So will this fall within your use case of copying buffers from lvgl?

Doing some test image Scaling, Rotation and transparent pixels. All running at 50hz done in software

Source image is 128 x 128.

https://imgur.com/a/sOtpgGb

Rezo · May 27, 2025

theboot900 said:
So will this fall within your use case of copying buffers from lvgl?

Yep!
Plan (for now) is to use PXP to copy LVGL partial buffer data from DMAMEM to SDRAM main buffer
And also copy canvas data from DMAMEM to SDRAM

Will look very similar to this video - it used direct mode in LVGL to an SDRAM buffer and memcpy to copy canvas data (moving waveform) to SDRAM main buffer
Props to @beermat for the demo

https://imgur.com/a/wPwCge9

Dogbone06 · May 27, 2025

theboot900 said:
So will this fall within your use case of copying buffers from lvgl?

Doing some test image Scaling, Rotation and transparent pixels. All running at 50hz done in software

Source image is 128 x 128.

https://imgur.com/a/sOtpgGb

Good work! Rezo planned to add rotation with PXP at one point but never got around to it. Maybe you'll share your PXP code when you're done?

Rezo · May 27, 2025

I wanted to add PXP (or some hardware rendering support) to LVGL in a form that is supported on the Teensy platform.
LVGL does support the use of the PXP but their build code is built for MCUExpresso - and so it requires a lot of rewriting to compile on the Teensy

theboot900 · May 27, 2025

Rezo said:
Yep!
Plan (for now) is to use PXP to copy LVGL partial buffer data from DMAMEM to SDRAM main buffer
And also copy canvas data from DMAMEM to SDRAM

Will look very similar to this video - it used direct mode in LVGL to an SDRAM buffer and memcpy to copy canvas data (moving waveform) to SDRAM main buffer
Props to @beermat for the demo

https://imgur.com/a/wPwCge9

I've never used LVGL but it always seems to pop up with microcontrollers etc. Do you design your ui on a pc or something rather than hard coding things?

Dogbone06 said:
Good work! Rezo planned to add rotation with PXP at one point but never got around to it. Maybe you'll share your PXP code when you're done?

Sorry I wasn't very clear. I'm not using the PXP for scaling or rotation. This is done in software on the cpu. It's reading a stored image on SDRam, rotating, scaling and ignoring transparent pixels, then outputting back to the backbuffer on SDRam.

The pxps rotations are fixed 90 degree rotations. I will at some point try scaling on the PXP. Working with the pxp I find it is so time consuming to get right, it's a lot of trial and error. But I'm more than happy to share code on anything I can get working and anything that's useful for others.

I'm currently optimising all my drawing primitives for rgb565 and effecient SDram usage and as fast as possible. Happy to share all these at some time.

While there can be some benefits to the PXP, I think its probably best to use as all or nothing. (Send all drawing commands down the PXP via a queue)
Having having 3 things access the sdram bus does slow things down a bit.

Although I'm assuming you would need to use bitmapped fonts if you were doing them on the pxp.

Rezo · Jun 3, 2025

I've done some more testing, this time with eLCDIF enabled before the PXP is started and and before a trasnfer starts
PXP and eLCDIF share the destination buffer, so the eLCDIF is constantly running

This affects the number a fair amount, but not too bad still..

SDRAM @ 198Mhz

Code:

SDRAM init SUCCESS :) ...
Memset..
VID_PLL: 100.00Mhz, div_select: 33
Waiting for PLL Lock...done.
Configuring LCD pix_clk source...done.
Resetting LCDIF...poking reset...re-enabling clock...done.
Initializing LCDIF registers...
LCDIF_CTRL: 0xa0020
LCDIF_CTRL1: 0x1070000
LCDIF_TRANSFER_COUNT: 0x1e00320
LCDIF_VDCTRL0: 0x10300004
LCDIF_VDCTRL1: 0x1f8
LCDIF_VDCTRL2: 0x200340
LCDIF_VDCTRL3: 0x180014
LCDIF_VDCTRL4: 0x40320
done.
Unmasking frame interrupt
Running LCD
Time to copy 800*240*2 bytes from RAM1 to RAM2: 1608 uSec
Time to copy 800*240*2 bytes from RAM1 to SDRAM: 8195 uSec
Time to copy 800*240*2 bytes from RAM2 to SDRAM: 7979 uSec
Time to copy 800*240*2 bytes from SDRAM to SDRAM: 9474 uSec
Time to copy 800*480*2 bytes from SDRAM to SDRAM: 10231 uSec

To compare with SDRAM withouht eLCDIF running from the previous tests:

Code:

Time to copy 800*240*2 bytes from RAM1 to RAM2: 1606 uSec
Time to copy 800*240*2 bytes from RAM1 to SDRAM: 6544 uSec
Time to copy 800*240*2 bytes from RAM2 to SDRAM: 6541 uSec
Time to copy 800*240*2 bytes from SDRAM to SDRAM: 7521 uSec
Time to copy 800*480*2 bytes from SDRAM to SDRAM: 8218 uSec

Rezo · Jun 3, 2025

@theboot900 how are you dividing the SDRAM into the four banks? Through the linker script?

I’d like to set my destination buffer at the beginning of the second bank, but not show how with my codebase

theboot900 · Jun 3, 2025

Those times look good. Thanks. If you can start the PXP as early as possible you can do some of it in the vertical blanking period.

Rezo said:
@theboot900 how are you dividing the SDRAM into the four banks? Through the linker script?

I’d like to set my destination buffer at the beginning of the second bank, but not show how with my codebase

I haven't had any time recently to look at all this.
I hate to say it, but after stumbling around trying to roll something at the time I threw it at chatgtp. When doing timing tests it did make a difference.

However i haven't even really read through it or tested thoroughly by reading pointer values etc

Bank is 0, 1, 2 or 3

Code:

void* SdramMallocInBank(int bank, size_t size, size_t alignment = 32)
{
  const uintptr_t SDRAM_BASE      = 0x80000000UL;
  const size_t    SDRAM_BANK_SIZE = 0x00200000UL;      // 2 MiB
  const size_t    ROW_LIMIT       = 0x100000UL;        // 1 MiB
  const size_t    BYTES_PER_ROW   = 3200;
  const uintptr_t BANK_BASE       = SDRAM_BASE + bank * SDRAM_BANK_SIZE;
  const uintptr_t BANK_END        = BANK_BASE + SDRAM_BANK_SIZE;

  const size_t extra = alignment + ROW_LIMIT;

  for (int tries = 0; tries < 32; ++tries)
  {
    uint8_t* raw = (uint8_t*)sdram_malloc(size + extra);
    if (!raw) { return nullptr;}

    // 32-byte align the pointer */
    uintptr_t addr = ((uintptr_t)raw + alignment - 1) & ~(alignment - 1);

    if (addr < BANK_BASE) {addr = BANK_BASE;}

    // 2. if we overflow the bank after rounding, pull back to fit   
     if (addr + size > BANK_END)
     {
        addr = BANK_END - size;
        addr &= ~(alignment - 1);          // keep alignment
      }

      // 3. final safety: still inside the bank?                       
      if (addr < BANK_BASE || addr + size > BANK_END)
      {
        sdram_free(raw);
        continue;
      }

      // Fix the 1 MiB row-cross rule
      uintptr_t offset = addr & 0xFFFFF;      // offset inside 1 MiB window
      if (offset + BYTES_PER_ROW > ROW_LIMIT)
      {
        // slide forward to the next 1 MiB window                     */
        addr += ROW_LIMIT - offset;
        addr = (addr + alignment - 1) & ~(alignment - 1);  // re-align

        // still safe inside the bank?                               */
        if (addr + size > BANK_END)
        {
          sdram_free(raw);
          continue;
        }
      }

      return (void*)addr;   // success
  }
 
  return nullptr; // giving up after 32 attempts
}

Just remember I'm assuming if you start allocating new memory in the next bank, you would be wasting a lot of memory.

Rezo · Jun 4, 2025

I’ll be using SDRAM only for the screen sized destination buffer and a 4MB audio PCM buffer, so I’m not too worried about the wasted/untapped space

Rezo · Jun 4, 2025

Just for the sake of it (and to show the benefit of SDRAM over PSRAM in this case) I ran the test on a T4.1 with 16MB PSRAM running at 88Mhz (I can't recall if I changed the bus frequency to 132Mhz or not)

Code:

Time to copy 800*240*2 bytes from RAM1 to RAM2: 1606 uSec
Time to copy 800*240*2 bytes from RAM1 to PSRAM: 24952 uSec
Time to copy 800*240*2 bytes from RAM2 to PSRAM: 24952 uSec
Time to copy 800*240*2 bytes from PSRAM to PSRAM: 53161 uSec
Time to copy 800*480*2 bytes from PSRAM to PSRAM: 81093 uSec

Ouch....

Diy teensy sdram solder yourself

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member