enrico.dallavia Posted January 5, 2016 Report Share Posted January 5, 2016 Hello,I have a custom board, with stm32 F429. Using the FMC we have equipped the board with a 256MBit flash NOR, I've already used the embedded filesystem to load images on the uP's internal flash (generating the .h files as described in the guide of ugfx with ROMFS). But now I'm wondering how to use image (the images are plain bmp) loaded at runtime and saved on the external flash, is it possible to fill a gdispImage object with the data read from external flash? I don't have a filesystem over external flash, only a small portion of code that tell me at which address the image begins and how long it is.Can I use gfileOpenMemory to read data of image inside gdispImageOpenFile, or to be more accurate, is there a way to open an image and display it, using gfileOpenMemory and using as the void * memptr the address on flash where the image file begins?Maybe what I'm searcing for is gdispImageOpenMemory? Thanksps: is this approach valid? --> viewtopic.php?f=23&t=250but I've already tried to use a pixmap, creating the heap on external pSram, and the system performance slows down a lot, if I use cached image, could I suffer the same problem? Link to comment Share on other sites More sharing options...
inmarket Posted January 5, 2016 Report Share Posted January 5, 2016 If you have placed the bmp into a ROMFS then you can use the normal image file open calls.ROMFS creates a virtual file system specifically designed for FLASH without any of the FAT file system overheads.Look at the demos/gdisp/image directory for an example.Alternatively you can use the memory image open call with a suitable pointer address however that is not the preferred method.Image caching uses allocated memory to hold an in memory copy of the image. This is very expensive in RAM usage and is generally not needed when retrieving from FLASH as these device as often just as fast (or nearly as fast) as RAM for reading operations. Image caching is really only useful when holding images on really slow devices like SD-CARD. Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted January 6, 2016 Report Share Posted January 6, 2016 Multiple things need to be kept in mind when considering image caching. Whether it make sense to cache an image depends a lot on the user hardware/architecture as well as the application itself (how big the image is, what format/encoding the image is using, how often it needs to be drawn etc).As inmarket already said, caching an image means that a chunk of RAM will be allocated to store the entire decoded image. A decoded image is essentially a table of pixel values in the display controllers native color format. Working with an RGB565 format would mean that two bytes per pixel need to be allocated.A plain BMP file is already pretty much that. After a small header it's essentially a table of pixel values. This means that in terms of performance (as in saving CPU cycles for decoding) you won't gain anything when caching a plain BMP file.The next thing to consider is memory speed. This depends on the architecture of your device and the actual components used. In your case you're having both the ROM that stores the image as well as the RAM where you'd store the cached image on the same bus/peripheral (the FMC). Assuming that reading from your SDRAM is as fast as reading from the NOR would mean that the main gain would be that you don't need to spent time changing the peripheral configuration to switch between the two memories.Another important thing to keep in mind is hardware acceleration: In your case the DMA2D peripheral would allow to directly blit the entire image 1:1 without any CPU time involved at all. This is obviously a huge benefit and would save a lot of CPU time.In my opinion in your case it boils down to how often you need to draw the image, how big your RAM is and how fast you can access the NOR.I hope that helps... somehow.~ Tectu Link to comment Share on other sites More sharing options...
enrico.dallavia Posted January 7, 2016 Author Report Share Posted January 7, 2016 Hi all, thanks for the reply!I have a small gif loaded from romfs, but I don't think the images are needed to be redrawn a lot of time (so I will rather avoid caching). The external pSRAM is pretty big but the issue there is the speed at which I can use it. The flash also is quite big and I plan to save inside it only bmp image (so as Tectu has written, it should be fine loading them directly from the nor).I will try today using gdispImageOpenMemory.One question, since I can pass to the function only the address, how the ugfx will know how big is the image? because with bmp the image size is inside some part in the beginning of the "file" I've loaded?https://en.wikipedia.org/wiki/BMP_file_ ... ile_headerthanks Link to comment Share on other sites More sharing options...
enrico.dallavia Posted January 7, 2016 Author Report Share Posted January 7, 2016 It works!I've first loaded with ROMFS a bitmap, then copied the bytes on the external NOR flash.Using gdispImageOpenMemory(&myImage,data); gdispImageDraw(&myImage, 0, (fheight1+5), 60, 84, 0, 0);where data is the pointer to the address where the image is written, I can see the image at screen!uGFX is a wonderful piece of work!!! Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted January 7, 2016 Report Share Posted January 7, 2016 We are glad to hear that you got it working!Happy to hear that you like the uGFX library ~ Tectu Link to comment Share on other sites More sharing options...
spectre Posted December 10, 2016 Report Share Posted December 10, 2016 I also agree that uGFX is a great library. Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted December 10, 2016 Report Share Posted December 10, 2016 Thank you for your feedback, we appreciate it a lot Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now