This is regarding interfacing character LCD (parallel) with STM32F767. I can find plenty of specific detailed info on DSI, DFSDM, graphic LCD, but except for highlighting it as a feature, I can find no actual information on this interface

[DRine.968]

I've poured through every doc I could find and only find 2 mentions of interfacing w/ parallel character LCD , 3 if you count the Cube MX drop down menu indicating it can be done. The data sheet clearly indicates it is a thing. The last paragraph of the FMC feature, section 2.8, pg 24 is entirely about this interface Happens to also be the only mention of it. The big book, RM0410, has exactly one bullet point on page 332, again FMC, listing it as a main feature. Not another word. No register mapping, no alternate function pin mapping, no driver/HAL that I can seem to spot...

I'm sure it's relatively straight forward, but without basic info, hacking the chip and bit banging my UI isn't really what I was hoping to do for the rest of my life. I just can't find any details, actual information. Any help would be appreciated.

Dale

[waclawek.jan]

Dale,

Thing is, that that section shouldn've made to the DS at all. I guess you are from the younger generation - the seasoned hardware developer with no prior experience with parallel-interfaced LCD would look at the its DS and immediately say, "oh, it's just another SRAM-like interface, except just with one address bit" (often marked as D/C for Data/Command). He would then look up the FMC chapter in the STM32 RM and he's done.

Because that's it.

Setting it up is then the same as with any SRAM, setting up the respective pins for the given AF in GPIO, and writing two or three registers in FMC.

Using it you don't need any driver or whatnot, it's simply writing the needed value to one of two addresses, depending on which address pin of STM32 you've connected to the C/D pin of LCD (and which bank you've used, that's given by which chipselect pin you've used on STM32).

That ST might've written a clear appnote once they've started to push this non-thing as a thing, is another thing. (@Vincent Onde​  this goes to the dozen which belongs to the SRAM subfeature of FMC).

JW

PS. Please change your username to a normal nick.

[waclawek.jan]

Okay, I found AN2790.

@Vincent Onde​ ,

1. It says 'F1 and hasn't been updated since 2008. I don't say it needs to be updated as such, but that this is indication that it was never considered to be applied to the newer families with the F(S)MC (btw. this naming confusion deserves an appnote too, btw, another going to the dozen). This is reflected in the fact, that this AN is nowhere to be found in those newer products' folders (and did I mention how idiotic the technical part of ST's web, i.e. the products/product families folders got, after the website revamp in Spring this year?) To be fair, I found it in some 'F4 product folders (did not go through all them of course, that's not my job to do) but not in the 'F767 as the the OP uses.
2. It concentrates too much on the demo. That's a plague of many ST's AN, they pay too little attention to the principles and too much on the implementation (like screenshots from Cube). If there's a particular demo in mind, that should go to a separate AN. The principles should be explained in clear terms, in many diagrams, and it should not contain - as is another plague of the ST ANs - lengthy quotes from the RM. After all, the AN should *explain* the RM, so it should substantially extend on the RM's material, rather than quoting it. In AN2790, logically, chapter 2 should come first, as that's the main matter, and only then the description of F(S)MC, as that's the means to get to the solution.
3. As for particular details go, just to mention a few: a) table A should include the major minus of the on-LCD controller, i.e. the cost of that controller (and usually also an extra board which comes with it) , i.e. that mcu-interfaced LCD modules are more expensive than the "bare" ones (which are also sometimes reffered to as "LCD panel" to distinguish them from "LCD module [with controller]", this might've mentioned in the "terminology" section too); last row in table A should also be updated in light of fact that since 2008 there are STM32s (and other mcus) with built-in LCD widely available; first line of table A should for controller-less should not say unconditionally "external RAM" as sometimes internal RAM is sufficient but still is a burden; on the controller-included side it should be mentioned as a + that any unused extra RAM in the LCD controller can be used for general-purpose; also it should be mentioned that *some* LCD controllers offer simple acceleration such as line/rectangle/circle drawin, bitblt, scrolls are available even in the simpler LCDCs... b) ch. 2.4. is clumsy, it should say right away that the 6800 interface does not match well the F(S)MC and should be avoided if possible, and that the suggested solutions are essentially workarounds (I'm not sure all 6800-interfaced ICs will work OK with E being driven by inverted CS, as that does not provide any data/address hold for write); c) some if not all LCD controllers support 8-bit data (which is often welcome to spare pins and PCB area) and there are some with 24-bit bus requiring 32-bit to be set on the STM32 side (this should be also mentioned for how 9-bit and 18-bit LCD controller is to be interfaced); this should be reflected in a substantially extended ch.2.2, focusing also on the impact of data bus width at the address calculation (this is a relatively confusing issue which comes up on this forum regularly); d) there are controllers out there with substantially different read and write timing; that gives a nice opportunity to highlight this option of F(S)MC; e) there should be short software examples (yeah, snippets are the way to go! =) ) given for both setting up the LCD controller and the usage (read/write to control/data addresses)
4. Please don't get me wrong - there are many good things in AN2790, e.g. the Note in ch.2.2 nicely explains the usage ie. how address depends on (except it fixes at 16-bit bus unnecessarily as I said above); even the fact the 100-pin packages are still usable as outlined in ch2.4 (F(S)MC used to be said to not exist in 100-pin 'F4 packages in the respective DS, this was corrected on ground of them being usable for the LCDs, this was discussed in this forum at that time). Unfortunately, it's generally harder to "positively criticize"... ;)
5. There's also AN3241 but that's a completely different thing, essentially a "hack" enabling to use controller-less "RGB-interfaced" LCDs with STM32s with F(S)MC but without LCDC - unfortunately, it does not explain this in the intro and does not use the terminology used in AN2790 which is relatively "standard" in the field, i.e. MCU vs. RGB interface (the whole 2.1 Common color LCD interfaces chapter from AN might've found way in an appropriately modified form. This AN is poorer executed than AN2790, and could be reworked for being much better - e.g. again it sais "FSMC on 'F1" which may be deterring; timing info deserving a whole chapter with several diagrams and tables is completely missing; 2.4.1 is a confusing implementation-specific thing which does not belong to ch2. at all, etc. Again this AN is not propagated to the 'F7 product folders. Yeah, I sort of see that you want to sell the LCDC feature, but then why is AN3241 to be found in 'F429's folder? I believe it makes sense; and it then deserves yet another AN, referring to all these (including the LCDC AN), and explaining all the possible ways to interface a display (and interfacing alphanumeric HD44780-compatible displays is a thing, too). Goes to another, "general features overview" dozen.
6. Want a cheap dozen for F(S)MC/LCD? There are several different LCDs on the Discos/Evals, some of them with mcu interface. And there are more on the market, some quite readily available. An emerging and very closely related issue are OLED displays with their controllers. So, write an appnote for each one of them, referring to AN2790, outlining the specific choices of connections for each particular one, and the impact on the software. Details do matter. Some (most?) controllers have an output to suppress "Tearing Effect" that could be discussed. Some (maybe not present on Discos) have waitstate output (e.g. RA8875), that again is something to be talked about. Some controllers have what's effectively a multiplexed data/address bus, that is a thing, too (I personally never used such but noticed there are out there).
7. Again only marginally related, these controllers can be bit-banged, and that can often be optimized too, e.g. using timer-triggered DMA for data using timer outputs for control signals. That may yield another AN or two, which would nicely cross fields (LCD/i.e. external peripheral, DMA, timer, linking to the existing timer-triggered-DMA-to-GPIO AN). A particular example could be the 'F429 Disco, where all three methods of LCD usage (RGB, parallel (albeit bit-banged), SPI) can be demonstrated (another AN or two).

JW

[Tesla DeLorean]

What LCD, some generic 162 LCD ? Surely lots of examples for those.

But those are rather 1990's plenty of nice OLED displays now driven via I2C, using SSD-1306/1309, code examples for those easy enough to locate.

[waclawek.jan]

Ah, HD44780-compatible? It's totally not worth it - F(S)MC probably can't be set slow enough; it's a 6800-style E-latched interface so there's no direct support in F(S)MC without external circuitry; and then it's usually not worth to go for the 8-bit communication which makes the timing even more weird. This is the prime case for timer-driven-GPIO for data and timer outputs for the control signals, as I mentioned above.

JW