Tennsy 4.0 and W25Q64

J

jean

Active member
Hello everyone,

I use a Tennsy4.0 card and a 320*480 TFT screen, everything works well thanks to your help.
what I would like to know if by adding W25Q64 to my montage I can put a photo of 2000*2000 pixels (the photo is 3MB), the script that I currently made works well with a photo in the memory of the card in PROGEM. (this one is 640*960 pixels).

Kind regards Jean
 
Hopefully some others might know parts of this better than I do.

If you were saying a Teensy 4.1 with one of the versions of the WW35Q64 that is supported that can be soldered to the bottom of the T4.1, I would say that you could have a littleFS file system on the chip and you could store the image as a file. I don't remember if we have a setup for LittleFS that works with normal SPI instead of Quad SPI.

Similarly you could store files lis this on an SD Card or USB or ...

Not sure if that helps or not.
 
Good morning KurtE,
I'm on Tennsy 4.0, I tried on an SD card (on the screen) but the image is too big and the test script doesn't work, the card is recognized but not the photo, the script I use to test it is that of ILI9341_t3 spitftbitmap
 
Sorry, I don't know how your image is created and/or stored. The sketch you mention only supports specific format bitmaps
Does your run give you additional information, like why it did not like the file?

Not sure what you are trying to do, as you mention your display is something like an ILI9488? or HX8357(I think that was the number) or ???
So what are you wanting to do with a 2000x2000 image?

We have some sketches that read in BMP or JPEG or PNG files, that try to scale them to fit on the screen. Not sure if that is what you are wanting? The example sketch simply allows you to pan in the file and clip what that does not fit.
 
jean said:
script that I currently made works well with a photo in the memory of the card in PROGEM. (this one is 640*960 pixels).
Click to expand...

Normally flash memory soldered to the QSPI pads on the bottom of Teensy 4.1 is accessed as a filesystem, not memory mapped.

The hardware does have the ability to memory map those chips. In the very early days of Teensy 4.1 we experimented with using that mode. Other than those early experiments, no code has been published to do this it's far from an easy thing. Even if you do get the memory mapping working, there's also the matter of somehow writing your data into the memory, which involve the "IPCMD" interface and needs to use the cache management functions to tell the ARM caches not to keep the prior data. It is possible hardware-wise, but not really supported by any of the current code.
 
PaulStoffregen said:
Normally flash memory soldered to the QSPI pads on the bottom of Teensy 4.1 is accessed as a filesystem, not memory mapped.

The hardware does have the ability to memory map those chips. In the very early days of Teensy 4.1 we experimented with using that mode. Other than those early experiments, no code has been published to do this it's far from an easy thing. Even if you do get the memory mapping working, there's also the matter of somehow writing your data into the memory, which involve the "IPCMD" interface and needs to use the cache management functions to tell the ARM caches not to keep the prior data. It is possible hardware-wise, but not really supported by any of the current code.
Click to expand...
I'm confused, isn't this exactly how the LittleFS library works? Reads are done with direct memory, writes use IPCMD...
 
For QSPI added to Teensy 4.1, both reads and writes use IPCMD.

For use of leftover program memory, indeed it is done as you said with memory mapped reads.
 
Hello

KurtE​

, the goal is to simulate a kind of GPS (random animation of movement) so a large image where I just take the part which is in the area of the size of the screen.
the image format is obviously not recognized as compliant. (it could be that a parameter is not correct. I tried on an SD card but same error. I am in BMP under Photoshop.
 
Good morning,
I have made a sketch for you of what I would like to do in order to make myself better understood.
Thank you for your help
 

Attachments

  • exemple.jpg
    exemple.jpg
    25.6 KB · Views: 9
The hardware does have the ability to memory map those chips. In the very early days of Teensy 4.1 we experimented with using that mode. Other than those early experiments, no code has been published to do this it's far from an easy thing.
Click to expand...
I did do this, pretty simply, addressing 8 or 16 megabytes as a single array. https://forum.pjrc.com/index.php?threads/extmem-and-playmem.74114/#post-335493
It has worked well for the simple use I had for it and avoided stuttering audio that I guessed (based on reading other reports in the forum) was related to buffering. the posted code used 8megabytes but I've also used 16 in the same fashion.
 
Good morning jrraines,
in my case, with a Tennsy4.0, for my image which is in PROGEM, is it your opinion to do the same?
 
Good morning,
I thought about my file size problem.
If instead of putting a file in hex in PROGMEM, can you put it in Byte? style:
Code: 
const uint16_t image[ ] PROGMEM = {
B11111111,
B11011000,
B11111111,
..........} ;

The same file would be much smaller in storage space.
But above all how to display the image afterwards?

Currently I go through each pixel of the image, I calculate the new position of the pixel after rotation, if the pixel is in the display area I display it or if it is not it is ignored.

Code: 
// Check if the new coordinates are inside the screen
       if (newX >= 0 && newX < SCREEN_WIDTH && newY >= 0 && newY < SCREEN_HEIGHT) {
         // Get the color of the image pixel
         uint16_t pixelColor = Map_B2[y * IMAGE_WIDTH + x];

         // Draw the pixel at the new position with the color of the original image in the screenBuffer
         screenBuffer[newY * SCREEN_WIDTH + newX] = pixelColor;
       }
 
Wouldn't you want uint8_t instead of uint16_t ?? Otherwise, you're taking up a 16-bit storage location for each 8-bit value.

Mark J Culross
KD5RXT
 
Good evening Mark J Culross,
unfortunately, this does not change my problem, the image is not displayed.
 
You must log in or register to reply here.
Back
Top