Dogbone06
Well-known member
As far as I can remember, I never said they were ordered from JLC, what's that?
Call to arms | Teensy + SDRAM = true
- Thread starter Dogbone06
- Start date
I just want to know if the DevBoard5 has been tested. And it works.Okay everyone, I'm ordering the 10pcs batch now!
Dogbone06
Well-known member
I suggest that you read through this thread. Sure it may take a little time but there's a ton of information and knowledge in here that has gathered over the course of time when we developed this. There's code and pin mappings. Which you will need to find the board useful.
Atleast read throught the last 25 pages if you're in a hurry. Your question will be answered in doing that.
defragster
Senior Member+
Indeed, a batch of the DB 5.0 boards were made and distributed months back and they are working well. A batch of DB 4.5's were also made and distributed to a few people and they work and have seen use, but the DB 5.0 layout came with extended pins and features and is the main board being used the most.
One critical change for the SDRAM function is having the 10 pF capacitor in place for reliable use, especially when over clocked.
The boards were made with the 528 MHz Automotive type part and work well - even at 600 MHz but required a modification to the voltage curve. Using the standard temp 600 MHz part should not have this concern.
<edit> missed page change and final posts ... indeed above summary should be correct to many prior postings.
One critical change for the SDRAM function is having the 10 pF capacitor in place for reliable use, especially when over clocked.
The boards were made with the 528 MHz Automotive type part and work well - even at 600 MHz but required a modification to the voltage curve. Using the standard temp 600 MHz part should not have this concern.
<edit> missed page change and final posts ... indeed above summary should be correct to many prior postings.
Dogbone06
Well-known member
Hey all! I'm playing with a 5" 16 bit screen using eLCDIF together with LVGL which works nicely.
Me and @Rezo are a little curious on how to use the Pixel Pipeline to rotate the screen. Seems that Mike made a library.
Library: https://github.com/mjs513/T4_PXP
It would be nice to be able to do something like "lcd.rotate(90);"
Is it also possible to rotate odd numbers like say 33 degrees or is it just 4 rotations available?
What would be the proper way to do this having eLCD and PXP work together?
I use two buffers stored in SDRAM.
I then have the LVGL display flush function.
Display stuff is initialized here:
Me and @Rezo are a little curious on how to use the Pixel Pipeline to rotate the screen. Seems that Mike made a library.
Library: https://github.com/mjs513/T4_PXP
It would be nice to be able to do something like "lcd.rotate(90);"
Is it also possible to rotate odd numbers like say 33 degrees or is it just 4 rotations available?
What would be the proper way to do this having eLCD and PXP work together?
I use two buffers stored in SDRAM.
I then have the LVGL display flush function.
Display stuff is initialized here:
mjs513
Senior Member+
Been a while since I played with pixel pipeline but from what I remember you can only rotate in 90 degree increments.
Not sure how to incorporate into LVGL. This example would probably help.
T4_PXP/examples/another_pxp_test_sdram/another_pxp_test_sdram.ino at master · mjs513/T4_PXP
Teensy 4 Pixel Pipeline. Contribute to mjs513/T4_PXP development by creating an account on GitHub.
github.com
Thanks for all the people that worked on this to figure it out how to add sdram and creating libraries to work with it. I certainly would not have tried as it is beyond the scope of what i know how to do. So . . . I am starting to work on creating a custom board for a project of mine and wanted to use what was presented here as a basis for it. Unfortunately I am no master at routing and have no clue what I am doing. I didnt want to do a copy paste as I am using an mcu with a slightly larger footprint and doesnt align to this one (same mcu just different size as I already have a stock of them). shown below is a general trace layout of a 6 layer board between the 2 chips (left is sdram same as the one used in this thread and right is the imx). I have not added any additional circuitry or components yet as I wanna make sure the routes work for this before i go ahead and add em in. The idea is to use the sdram at the rated max of 166MHZ. bottom layer is the data lines and top layer is the address and control lines. i wasnt to sure about the length matching as i dont really understand how the timings work so generally followed this doc by issi (https://www.issi.com/WW/pdf/appnotes/dram/AN42S01.AN.pdf) which has general rules for layout of sdram. The only thing i am unsure about is the lengths. The difference between the longest and shortest lines is about 14mm for data lines and 10mm for address lines. In the guide they state a max difference of 20mm is needed. This would be on a more space constrained board so i needed the sdram to be as close to the mcu as possible (plus i just hear that it should be like that in general). also this does have a ground plane between the lines its just not active in the images. Idk what other information is needed but the connections are the same as in the dev boards, just routed to be closer. Maybe yall cant say with certaincy if it will or wont be fine but as a general is it ok to have that much difference between the longest and shortest path. Also forgot to mention the longest trace is 21mm if that has any bearing on this. Oh and what is the purpose of the zero ohm resistor on the clock line? Is it just to be able to swap resistors to get different impedences on the fly?
Attachments
Last edited:
Rezo
Well-known member
I recall reading in the RM that the PXP can work async with the eLCDIFA bit on each of their control registers needs to be enabled.Been a while since I played with pixel pipeline but from what I remember you can only rotate in 90 degree increments.
Not sure how to incorporate into LVGL. This example would probably help.
T4_PXP/examples/another_pxp_test_sdram/another_pxp_test_sdram.ino at master · mjs513/T4_PXP
Teensy 4 Pixel Pipeline. Contribute to mjs513/T4_PXP development by creating an account on GitHub.
Then you can feed the PXP with to partial/full screen sized buffers, it will swap between them automatically and push the rotated image out to the LCD controller.
Section 36.3.1.19 - LCDIF Handshake on page 1927
So the way I understand it, the PS buffer would actually be one of the LVGL allocated buffers (which are allocated to SDRAM) , and the out buffer are actually two smaller buffers in SRAM and work directly with the LCDIF.
@jmarsh have you ever played with PXP and the eLCDIF and handshake before?
Last edited:
I basically copied the traces from the MIMXRT1060_EVK design files on the NXP site. I certainly can't tell if what you have will work, but here are some details from the kicad trace inspector for the GPIO_EMC_* traces in my design:
thanks for the reply. I had just looked into how to actually do the math for the timings and yeah . . . i am way off . . .