Call to arms | Teensy + SDRAM = true

Added a mandelbrot sample that cycles the palette colors (still using only 4bpp/16 colors because it turns out I only have RAMDACs on hand, not direct VGA DACs...)
A picture of 1920x1080 output for @Dogbone06 :
IMG_20240129_133556209.jpg
 
Opps - Updated CapReadSDRAM.ino again : https://github.com/mjs513/SDRAM_t4/tree/main/examples/CapReadSDRAM

The Error count counting was not right - blaming Github confusion since it was too dumb to be a human mistake :)

On multiple ReReads the per loop count of errors that adds into the returned error count was not zeroed between ReRead loops so the numbers were higher than expected - or possible - in both loops for Fixed and Random read testing.
 
Sorry all was MIA yesterday - power went out for about 8 hours and by the time it came back was too late. See I missed a bunch.

Planning on adding a new function to the lib to get the freq set in the begin method. But to do that I had to ditch using constexpr for the class and static on the begin methods. I will push the change and if no one likes it can always revert the change

example:
Code: 
    Serial.printf("Clock set %.2f MHz\n", sdram.getFrequency());

which would print:

Code: 
Clock set 166.15 MHz
basically what Paul's serial print is doing from within the library
 
Out of curiosity I modified @PaulStoffregen supported frequency sketch since I was seeing alot of dup actual frequencies:
Code: 
Set : Actual
100 : 99.31
102 : 102.86
105 : 106.67
109 : 110.77
113 : 115.20
118 : 120.00
123 : 125.22
124 : 123.43
126 : 127.06
129 : 130.91
133 : 132.92
134 : 135.00
138 : 139.35
142 : 144.00
147 : 148.97
152 : 154.29
158 : 160.00
164 : 166.15
166 : 166.15
167 : 166.15
170 : 172.80
177 : 180.00
184 : 187.83
193 : 196.36
198 : 198.00
199 : 196.36
201 : 205.71
211 : 216.00
221 : 221.54
222 : 227.37

So for example if I set a frequency of 206Mhz would give me a frequency of 205.71Mhz. The table above shows that the actual frequency is in the set frequency range of 201-210Mhz.

Here is the sketch if you are interested:

Code: 
#include <SDRAM_t4.h>

SDRAM_t4 sdram;

void setup() {
  while (!Serial) ;
  float supported_clock = 0;
  float supported_clock_old = 0;
  Serial.println("Set : Actual");
  for (int i=95; i < 370; i++) {
    bool ok = sdram.begin(32, i, true);
    if(ok) {
      supported_clock = sdram.getFrequency();
      if(supported_clock != supported_clock_old) Serial.printf("%d : %.2f\n", i, supported_clock);
      supported_clock_old = supported_clock;
    }
  }
}

void loop() {
}
 
Let's see if I understand that right.
If I for example write "222" as the frequency in the test sketch that you and defragster made, the one testing the memory. It would actually be 227,37MHz. Is that right?
 
Yeah, the hardware is only capable of specific discrete frequencies since it's clock comes from the PLL multiplied by 18 and divided by 2 integers. With the API allowing request of any integer MHz frequency, the best it can do is give the nearest that hardware is capble of generating.
 
Dogbone06 said:
Dumb question perhaps, I can just test later when I get home. But will the sketch you tested from Paul go higher then the 227MHz?
Click to expand...
the sketch goes from 95 to 370 Mhz. So from 222-370Mhz the actually frequency would only be 227.37Mhz. Looks like the minimum frequency is 100Mhz.
Corrected range....
 
I capped it at 360 MHz partly because supporting higher seems utterly unnecessary, but mostly because I was feeling lazy about assigning the PODF divider. Restricting to only 2 & 3 allows ~83 to 360 MHz.
 
Would be super cool with a sketch that will test each frequency. It'll probably take a day to run, but it's automatic.
You would give it the start frequency, for example 198MHz, then it would work it's way up as long as it doesn't get any faults. Once it reaches say over 1000 faults it will stop and present the results.

Obviously developing that may be more work then it's worth.
 
If you *really* want to go for overkill design, you could also support PLL2 PFD2 which gives 24 more possible base frequencies. You could also explore all possible clockdiv settings rather than choosing it in advance. Would probably involve substantial restructure of the code.

Seems like massive overkill to me, but if it's fun then why not?
 
mjs513 said:
Ditto - don't plan on it to be honest - in the middle of trying to get Flexio to work with the OV7670 camera - assisting @KurtE
Click to expand...
What protocol does the more "high end" cameras use? Perhaps the OV7670 uses the same protocol?
I know little about cameras. Just seems cool as hell to have a high def camera connected and then a screen. That's a great benchmark!
 
Dogbone06 said:
I'm hoping to reach 300MHz stable with one of the caps. But I think it's wishfull thinking from me.
Click to expand...
Sorry, I have not had enough :coffee: yet and my eyes are still sort of glazed over...

But I keep wondering if your goal is 300MHz, are you not asking for trouble if you try to more or less run something at twice the speed they are rated for? Are there faster versions?

Also wondering if the same CAP will work the same on different boards? Or will it all need to be fine-tuned depending on
each actual board design and which memory chip and ...

mjs513 said:
Ditto - don't plan on it to be honest - in the middle of trying to get Flexio to work with the OV7670 camera - assisting @KurtE
Click to expand...
Not sure which of us is leading :LOL:

PaulStoffregen said:
Oh yes, OV7670 is so much more important. :)
Click to expand...
Hard to know what is important these days :unsure:

Getting FlexIO to work well on a camera such as the OV7670 using multiple Shifters, could make it work well, both on these
boards as well as actual Teensy products like Micromod...

Then there are other diversions...
 
You must log in or register to reply here.
Back
Top