‎2020-02-03 08:57 AM
‎2020-02-03 09:40 AM
It says it for the SDRAM, not the QSPI
Why, because they used a 32-bit wide SDRAM due to price, availability or physical size/package, but they only have 16-bit of the data bits wired up, due to pin availability on the STM32 side. Consequently half the available capacity is lost.
The 32-bit wide SDRAM may be significantly cheaper because it's used in 100M quantities in some phone, tablet, or PC application.
‎2020-02-03 09:40 AM
It says it for the SDRAM, not the QSPI
Why, because they used a 32-bit wide SDRAM due to price, availability or physical size/package, but they only have 16-bit of the data bits wired up, due to pin availability on the STM32 side. Consequently half the available capacity is lost.
The 32-bit wide SDRAM may be significantly cheaper because it's used in 100M quantities in some phone, tablet, or PC application.
‎2020-02-03 09:45 AM
Oh lol I’m not good today, I thought for QSPI, sorry, then if it’s only the half is available! Supposed if I do, let say, a considerable application on this board, it won’t work? For example it might tell me SDRAM overflowed or something like that?
‎2020-02-03 09:54 AM
If you tell the linker you have 8MB (64Mbit) of SDRAM, it will tell you if/when you exceed the capacity.
If your application needs more SDRAM than that, you'd need to consider a different board to do the proof-of-concept on.
The SDRAM should be more than sufficient to sustain the screen buffer(s) for the 480x272 display.
I would generally avoid the SDRAM for code or stack as it is slower, and contended, the cache may hide most of this on the F7
‎2020-02-03 10:25 AM
>> I would generally avoid the SDRAM for code or stack as it is slower, and contended, the cache may hide most of this on the F7.
its very interesting this sentence, but I can’t understand it, can you explain me what do you mean please?
‎2020-02-03 11:06 AM
The external memory accesses slow, so fetching and writing have significantly more latency.
Typically to operate at full/optimal speeds you want to put critical data in more tightly coupled memory (TCM), the stuff that can be accessed within the current cycle, or one cycle.
All your code is likely dependent on the stack, for passing parameters, or holding auto/local variables. You should use the internal SRAM or DTCMRAM for such things. The DTCMRAM is fast, and not cached, allowing the cache to focus on slower memory a bus, or two, away from the core.
‎2020-02-03 11:15 AM
Thank you very interesting :smiling_face_with_smiling_eyes: