External SPI Flash for storing data

You posted "the external flash (isn't mapped to the internal address space) instead its mapped to the internal address space".

Say again? Is it mapped to internal address space or not???

"Insted the SDRAM is mapped to the internal address space"

SDRAM, not external Flash...

The OP's post is too long for me to want to dig into it, but I hope someone else will.

--

  Rick C. 

  - Get 1,000 miles of free Supercharging 
  - Tesla referral code - https://ts.la/richard11209

I would do it a bit different. I would break the program into two programs. The first has the SPI Flash image loaded at 0xA000_0000 and loads a program to write that to the SPI Flash starting at 0xA020_0000 and this is loaded into the machine and run if you need to change the flash image.

The second program is your normal program which puts the program in the main internal flash, and begins by down loading the SPI Flash into the ram at 0xA000_0000.

If you change the SPI Flash Contents, rebuild and run the writer program, and the run the main program. If you don't change the SPI Flash contents, you don't need to run that first writer program.

This does say that the SPI Flash is only for constant data that is specifically generated as such (images and the like) and won't hold simple data that just happens to be const, but that shouldn't normally be that big and can stay in the internal program flash and is updated by the normal main build process.

Yes.

I'm sorry for the long post, but the question isn't simple to make without explaining what I really want to do.

Ok, but how to instruct the linker to put images at 0xA000 0000? I know I can use sections, however 0xA000 0000 is a RAM section, so the linker woud try to put them (images are initialized global variables) in .data and .text and copy from .text to .data at startup. It isn't possible in my case, because .text is the internal Flash that is too small.

In my original post I proposed a trick to solve this problem: define

0xA000 0000 as a ROM section, even if it is a real RAM section. In this way, the linker should put images directly to 0xA000 0000, without worrying to initialize/clear them at startup.

I don't know if NOLOAD attribute of the linker section could be used in my case. I think NOLOAD is for *unitialized* variables.

Should I declare images in normal program too? If yes, where to put them? Consider that I need to use instructions such as:

external const struct Image mystruct; draw_image(x0, y0, &mystruct);

So the linker of the normal program should know where is mystruct in SDRAM.

luni, 1 iulie 2019, 10:35:51 UTC+3, pozz a scris:

h,

is

to

l

CD

rs).

r

er

t

to

n

er

l.

n

M.

h y

I have a system very close to yours. LPC4088 with a 800x480 tft lcd. SDRAM

8 to 32M, 32bit, SPI Flash 4 to 8M. My flash is on SPIFI (4bit interface) b ut this is not the point (although it's much faster). My SDRAM is partition ed for the application in three areas. One is the frame buffer, one is the bitmap storage (images) and one is for a specific file needed by the applic ation (a big one up to 20MB) - a dictionary. I DO NOT USE the linker for either SDRAM or SPIFI Flash. The program loads "by hand" the bitmaps from SPI Flash to the SDRAM area. A lso loads the big dictionary file from a sd card to the SDRAM area. The SDRAM partitioning is very simple, without involving the linker: the fr ame buffer which is first (at address 0xA0000000) and fixed in size. Next i s the bitmap file from the serial flash. The size of the file is self-conta ined ina small header so it's known. The dictionary loads on top of the bit maps wherever this address is. Regarding the bitmap file: This is a single file in a custom format, which contains a small header for the size (at least). Every bitmap has also a sm all header in front of it, also for the size. I construct this big file wit h my own small C program which takes hundreds of bitmaps from a folder. A very simple C program in mingw (CodeBlocks). And last, the application is using the bitmap images based on their index. The index table (containing the start addresses in the SDRAM) is constructe d at the time the file is loaded from serial flash in SDRAM.

Most embedded systems allow you to use a langauge extension to assign a give variable to a specific 'section' of memory by attribute, with default sections for all things (.code for the program, .data for normal variable, .bss for memory to be zero initialized, etc). If you are using gcc, there is an __attribute__() you can attach to those declarations to assign them to the special section you create for them. There will also be a loader configuration script that tells the linker where all these locations are going to be located in memory, and what types of things are to be put into them.

You will need to have extern declarations for all the variables, and then, likely in a single file, the actual defintions of them as uninitialized structures. Note, you can't really declare them 'const' as the program is going to change them by reading from the SPI Flash at startup. You likely can get away with having them be marked const in the header file, but have a flag that removes that const (or casts it away) for the file that loads the data, but then you technically have invoked undefined behavior (but it may work)

Il 01/07/2019 10:42, snipped-for-privacy@gmail.com ha scritto:

Why? I understood that a SPI Flash connected to SPIFI is mapped directly to the internal address space. So the MCU should access images on SPI Flash as they are in internal Flash.

Yes, this is another approach. I will give it a try.

I wasn't trying to make a statement about your post. I was saying more about my laziness. In general it is better to provide too much information than too little.

--

  Rick C. 

  + Get 1,000 miles of free Supercharging 
  + Tesla referral code - https://ts.la/richard11209

a.

That's a long story. My system went through a lot of revisions, starting wi th LPC2478, then LPC1788 and lastly LPC4088. At first there was only the sd card and the bitmaps were loaded from it. When I switched to LPC4088 I hoped that letting the bitmaps in the SPIFI Fl ash will be faster than having them in SDRAM based on the fact that the SPI FI and SDRAM are on different busses. And it was! And the latest version of the system, indeed, have the bitmaps in SPIFI Flash directly. Unfortunately you cannot use this aproach since you don't use the SPIFI int erface.

e frame buffer which is first (at address 0xA0000000) and fixed in size. Ne xt is the bitmap file from the serial flash. The size of the file is self-c ontained ina small header so it's known. The dictionary loads on top of the bitmaps wherever this address is.

ich contains a small header for the size (at least). Every bitmap has also a small header in front of it, also for the size. I construct this big file with my own small C program which takes hundreds of bitmaps from a folder.

ex. The index table (containing the start addresses in the SDRAM) is constr ucted at the time the file is loaded from serial flash in SDRAM.

Since the bitmaps were completely external "objects" I tried to make the fi rmware as decoupled as possible from them. At least, I really didn't want t o involve the compiler and linker.

Il 02/07/2019 06:35, snipped-for-privacy@gmail.com ha scritto:

I rememeber I tried to choose a MCU with LCD controller, 32-bits SDRAM interface and SPIFI, however I didn't find anything in QFP package, maybe only BGA that we cannot manage.

So are you saying that images in SDRAM, together with framebuffer, will be slow? What do you mean with... slow?

I was thinking about your approach, it's nice because you don't use compiler/linker. However I'm using emWin as GUI libraries (you too?) so I have to call functions such as:

GUI_DrawBitmap(&bmp);

where bmp is a pointer to a struct GUI_BITMAP defined by emWin. You said you use a home-made "bitmaps compiler" running on the desktop PC to generate a "file of bitmaps". How are you sure "bitmaps compiler" generates data compatible with emWin running on the target? Even if you define the *same* struct in "bitmaps compiler", it runs on completely different machine and you will have the risk that struct are represented in memory with a different layout (I think of integer size, padding, alignment, and so on).

One solution is:

extern const GUI_BITMAP *bmp_convert(unsigned int bitmap_index); GUI_DrawBitmap(bmp_convert(BITMAP_BACKGROUND));

bmp_convert() is an helper function that convert the image from "bitmaps compiler" format to a "well-defined in target" GUI_BITMAP, returning its pointer.

LPC2478 - QFP208 LPC1788 - QFP208 LPC4088 - QFP208 - has SPIFI

Good question :-) Slower for sure. I have some runtime profiling of the time spent to show a full screen image. As I said, I really wanted to see if SPIFI bitmaps would be faster than SDRAM bitmaps. But don't ask me the figures, don't remember such details. LPC2478 - slow (sdram bitmaps) LPC1788 - faster (sdram bitmaps but 120MHz cpu and other improvements) LPC4088 - same as 1788 with sdram bitmaps LPC4088 - faster with SPIFI bitmaps LPC4088 with everything in SDRAM (including the code!) - slow! - I wanted t o see how fast SDRAM execution is but the result is predictable, very impor tant in this kind of MCU is the parallelism of the internal busses.

The idea is that the LCD bus master uses the SDRAM for the frame buffer qui te intesively, and the CPU should be updating the same framebuffer. With bi tmaps in SDRAM, the CPU will access the SDRAM for both read and write. With bitmaps in SPIFIFlash the CPU will access the SDRAM only for write.

the frame buffer which is first (at address 0xA0000000) and fixed in size. Next is the bitmap file from the serial flash. The size of the file is self

-contained ina small header so it's known. The dictionary loads on top of t he bitmaps wherever this address is.

which contains a small header for the size (at least). Every bitmap has als o a small header in front of it, also for the size. I construct this big fi le with my own small C program which takes hundreds of bitmaps from a folde r.

ndex. The index table (containing the start addresses in the SDRAM) is cons tructed at the time the file is loaded from serial flash in SDRAM.

e firmware as decoupled as possible from them. At least, I really didn't wa nt to involve the compiler and linker.

I don't use emWin. I use a personal library that I developed over time. It' s history started with a mono-chrome one.

Il 02/07/2019 10:31, snipped-for-privacy@gmail.com ha scritto:

Do you know if LPC4088 is pin-to-pin compatible with LPC1788? I'm using QFP208 too, but LPC1785. Maybe LPC4088 is pin-to-pin compatible with LPC1785 too.

^^^^^^^ I'm here, with LPC1785 running at 120MHz. I hope your "faster" will be good for my application.

I see.

I see.

mar?i, 2 iulie 2019, 11:58:11 UTC+3, pozz a scris:

I don't remember, but there are great chances. When I switched to 4088 I wa s changing some things here and there, especially adding the serial flash.

If you have a 1785 I don't know if 4088 brings something to you, as long as you don't use the SPIFI anyway. There are some other improvements of cours e, like the eeprom, but I don't remember something big. The SDRAM is still 80MHz max. I tested two configurations, CPU=120MHz, SDRAM=60MHz and CPU=SDRAM=

80MHz. In my system these two configurations worked about the same. I've chosen the CPU=120MHz, SDRAM=60MHz. I have also tested CPU=SDRAM=96Mhz, and it worked very well. In fact, t he LPC1788 variant is only working at 96MHz, with many units in the field. Well, the "field" is very friendly room temperature, lets say 15-35 degree Celsius...

Den 2019-07-01 kl. 00:15, skrev pozz:

With an IAR C compiler you can define write your own flashloader. When you download the code using the debugger, the flashloader will program the SPI flash.

The linker can generate copy tables which can be used for copying from the SPI flash to the SDRAM.

The actual copy routine, you have to write yourself.

AP