Hobbyist: FPGA between MCU and external memory?

[DiTBho]

Umm, also I guess most Spartan6 parts come with DRAM controller, but it wasn’t available on the TQG144 package used for the FPGA on the PapiloPro.
I think it was a further reason for that.

My Automa was similar to this SDRAM tester, which just reads and writes 1 byte.

The difficult part of mine of mine was implementing, debugging, and tuning bursts.

[pcprogrammer]

The Spartan 6 series has integrated DDR memory controller(s), but only for DDR RAM, AFAIR. Not for SDRAM. .......

I think your semantics are a bit off. SDRAM stands for Synchronous Dynamic Random Access Memory, and is what lies at the foundation of most DDRx based memory. I know it is a bit confusing, but you should have written SDR SDRAM is not supported.

The terminology stands for SDR == Single Data Rate and DDR == Double Data Rate. For the unaware, with SDR only one edge of the memory clock is used to pass data, while with DDR on both edges of the clock data is passed.

I just recently dove into this memory stuff to get the Tang Nano 20K up and running with the integrated SDR SDRAM. (MT48LC2M32B2)

[pcprogrammer]

The difficult part of mine of mine was implementing, debugging, and tuning bursts.

That was also something I ran into, the burst handling and the terminating of it. Have not looked to close to DDR, but as it is also command driven with the three control lines I think it is not that much harder than the SDR memory.

[DiTBho]

@NominalAnimal
I don't know the correct term to call tham, I usually call them "STN-LCDs", even "super-twisted nematic" shouldn't refer to the "frame timing" but rather to the "liquid-crystal properties of changing their orientation when exposed to an electric field", which can be used to create images. This change is called the "twisted nematic" field effect, That's from where the TN of STN comes.

Anyway, STN LCDs have also the unique property of being simply, low bandwidth, which made them suitatable for 2000s PDAs, and fpga (even CPLD) small projects.

A dude in my group found the way to hack a couple of 2000s PDAs, and we got access to nice 320x240x4bit LCDs.

They work at 3.3V, can be LED-backlighted and the frame timing, once tuned, it's of a few lines of VHDL.
Which is good, because it's also super simple to create a "working model" for GHDL, so you can simulate the whole project by wrapping a simple pixel(x,y,color) function to a low level X11 primitive.

Some PDA-LCDs also come with resistive touchscreen.

Love them

[Nominal Animal]

@NominalAnimal
I don't know the correct term to call tham, I usually call them "STN-LCDs", even "super-twisted nematic" shouldn't refer to the "frame timing" but rather to the "liquid-crystal properties of changing their orientation when exposed to an electric field", which can be used to create images. This change is called the "twisted nematic" field effect, That's from where the TN of STN comes.

Whenever I use the labels TN, IPS or PVA in relation to TFT displays, I do so to highlight the user-visible result of the technology: TN panels have narrow viewing angles at which the image looks "correct", outside of which it becomes unreadable, sometimes even inverting; IPS and PVA allowing very wide viewing angles (and later versions reduced off-angle glowing).  The small displays I use have an integrated controller of ILI9341/ILI9488/ST7789 or similar type with their internal framebuffers/GRAM, so that I don't need to worry about the low-level details of refreshing the display.

In all these, the power required by the panel is a fraction of what usable backlighting needs –– and I typically run mine at very low intensities, which also tends to make PWM flickering more perceptible, that resulted in my own backlighting adventures.

Anyway, STN LCDs have also the unique property of being simply, low bandwidth, which made them suitatable for 2000s PDAs, and fpga (even CPLD) small projects.

And very low power, too.  I do still have a bunch of unused Nokia 84×48 5110 LCDs for small projects.  I must've bought them ages ago, because they came with the 5110 plastic base!

[SiliconWizard]

The Spartan 6 series has integrated DDR memory controller(s), but only for DDR RAM, AFAIR. Not for SDRAM. .......

I think your semantics are a bit off. SDRAM stands for Synchronous Dynamic Random Access Memory, and is what lies at the foundation of most DDRx based memory. I know it is a bit confusing, but you should have written SDR SDRAM is not supported.

Pedantically speaking, yes, but it's ultra-common to use "SDRAM" as short for what is SDR SDRAM (which is what SDRAM was initially when it got released), and refer to DDR SDRAM as DDR RAM. It's pretty much what almost everyone uses and must have been used hundreds of times on this forum alone. And all context was there in this thread to easily catch the difference. Sorry if that confused you.

So again and to make it ultra-clear, the Spartan 6 (except the lower end apparently) have one or more embedded memory controllers, which only support DDR/DDR2/DDR3/LPDDR RAM and can't be used in any way to control SDR SDRAM. Xilinx have gotten rid of those embedded controllers in the 7 series and they are provided as IPs implemented in non-dedicated logic cells.

A (SDR) SDRAM controller is much easier to implement (ask BrianHG who has implemented a DDR3 controller). HamsterNZ has implemented one years ago and should still be easy to find. It was used by many precisely with Papilio dev boards. That's a starting point for those who are interested. Of course, the devil is in the details and just because you have a basic controller doesn't mean that the memory will be "easy" to use. A good controller will have several channels, FIFOs, a scheduler and various niceties to optimize throughput.

[Berni]

Yeah with these sort of DRAM controllers there is a big difference between one that works and one that works fast.

You can implement the bare minimum to read and write some data to it, but in order to get fast performance you need a smart controller with multiple operations in flight and managing them in a way that minimizes bus idle time. To make things worse the thing that is using the memory also has to access it in blocks and be aware of the latency it takes to get data back.

So because of all of this it is much much easier to use SRAM if you can. For graphics at reasonable resolutions the price of a few MB of SRAM is not that terrible, while saving you a lot of manhours in development.

[pcprogrammer]

Having a highly specialized and optimized memory controller depends totally on the needs within your project.

Sure making a controller that can handle the different blocks available in the used memory is more difficult than making one that only uses a single block at a time, or one that only reads or writes a full 256 byte burst.

In a system where the memory is only used by a single "device" a simple controller will do. That is the case in the project I did with avst. Just a single frame buffer that needs to be written and read. And starting with zero knowledge made it time consuming to get things working, as with every other subject one has no knowledge about. It takes time to learn. More now that I'm older and have concentration issues.

For the project Nominal Animal is looking into, a more sophisticated controller might be needed, but by making use of other resources like blockram it can be somewhat simplified.

Sorry if that confused you.

This it did not, I wrote my post to inform others that might not have understood your intent. (And unintended, maybe to be pedantic)

[SiliconWizard]

So because of all of this it is much much easier to use SRAM if you can. For graphics at reasonable resolutions the price of a few MB of SRAM is not that terrible, while saving you a lot of manhours in development.

It is, but SRAM is still expensive. A few MB of async. SRAM will cost upwards of $10+ (compare that with SDR or DDR SDRAM), and access time will be slow. Fast SRAM is even more expensive, and often synchronous (making it only marginally "easier" to use than SDRAM). PSRAM is relatively cheap but only marginally easier to use than SDRAM IMO as well, if you need to develop the controller yourself.

If cost is a concern, spending a bit more time designing for SDRAM (or PSRAM at worst) will be necessary. And if using a Xilinx FPGA, DDR controllers are provided as IPs for free both on the 6 and 7 series, so using DDR SDRAM makes more sense in this case. There are many dev boards that have a Spartan 6 and 32MB or 256MB of DDR3 for cheap, I had bought a bunch of them for about $15 each, prices have inflated now but still relatively reasonable. Routing your own board with DDR3 is a bit more involved than for SDR SDRAM, but not excessively so either.

[Nominal Animal]

As my limiting factor is really the MCU access latency to the RAM, and not the framebuffer usage of it, you can probably see why I started looking into bank swapping.  Some data would be duplicated, yes, and the triple buffering scheme can confuse anyone not familiar with it (it's common in games, especially older games that did not regenerate the whole display contents for every frame, only updated the differences), but it'd be quite a bit cheaper, and probably easier to implement, too.

However, I do believe a couple of Milk-V Duo's (64M) are waiting for me at the post office.  One 64-bit powerful core for MCUey stuff including high-speed USB 2.0 handling, and the other 64-bit almost as powerful core for my framebuffer shenanigans, with a 40-pin 0.5mm pitch FPC connector that is compatible with several of my displays –– no, I got that mixed with the Tang Nanos! ––, all for paltry 10€ apiece, shipped, makes for a powerful argument to try to do things this way.

I do still intend to use the Tang Nano for FPGA shenanigans, most likely scaling and deinterlacing classic computer video chip outputs to panels or HDMI; but Milk-V Duo just fits my current framebuffer needs (for usb-connected displays for nontechnical humans stuff) best, I think.  Time will tell.

[pcprogrammer]

However, I do believe a couple of Milk-V Duo's (64M) are waiting for me at the post office.  One 64-bit powerful core for MCUey stuff including high-speed USB 2.0 handling, and the other 64-bit almost as powerful core for my framebuffer shenanigans, with a 40-pin 0.5mm pitch FPC connector that is compatible with several of my displays, all for paltry 10€ apiece, shipped, makes for a powerful argument to try to do things this way.

Which Milk-V Duo is that? The ones I have (64MB versions) don't have a display interface.

[SiliconWizard]

Yes, the Duo 64M only has a camera interface, not display out. So it must be at least the 256MB version, which sports a SG2002 instead of a CV1800B.
I hope Nominal didn't expect to have video output via the MIPI interface on the 64MB version, otherwise he'll be in for a disappointment. (And the only option will be to use display modules with embedded GRAM and a SPI interface, I don't think you can even implement a proper "parallel" interface with it.)

[pcprogrammer]

Yes, the Duo 64M only has a camera interface, not display out. So it must be at least the 256MB version, which sports a SG2002 instead of a CV1800B.
I hope Nominal didn't expect to have video output via the MIPI interface on the 64MB version, otherwise he'll be in for a disappointment. (And the only option will be to use display modules with embedded GRAM and a SPI interface, I don't think you can even implement a proper "parallel" interface with it.)

Well the SPI based interfaces with GRAM are what Nominal Animal said to be using, but the 40 pin 0.5mm connector he mentioned is on neither of the Milk-V duo modules I know of. That is why I asked.

The SG2002, according to the block diagram, has support for video output. But in the tech specs they mention a Duo S based on a SG2000 (probably a typo) and the video out connection is only via the GPIO header. In the tech specs they mention MIPI DSI 4 lanes. Maybe it is a pin thing, where the chip on the 64M and 256M boards is a to small version of it.

Edit: Found that it is actually correct, the SG2000. It is a 512MB version of the chip. On Aliexpress the board without eMMC is about the same price as the 256MB version. https://www.aliexpress.com/item/1005006719645936.html

[Nominal Animal]

Which Milk-V Duo is that? The ones I have (64MB versions) don't have a display interface.

Ignore that, I got it confused with the Tang Nanos.  (Whenever I do not verify my post after writing but before posting, I keep making these confusions, dammit.  My excitement shows!)

I'll use the GPIO pins, of which there are just enough for my purposes.

I hope Nominal didn't expect to have video output via the MIPI interface on the 64MB version

Nope.  The display modules I use a 8080-style bus to the GRAM, not synchronized to the display update (but do export the TE pin to indicate when the display refresh is complete).  The second core will compute each output pixel color at update time by combining data from multiple logical planes, only one of which is RGB.

The way I generate the GPIO pin states for that bus-to-GRAM uses yet more lookup tables.  On Cortex-M7 I used the DR_TOGGLE register to allow me to pick any pins in any order within the same bank, but the CV1008B only has a data output, no toggle.  I'll need to investigate which solution (keeping a copy of the value in RAM, or just overwriting the entire bank) yields best results.

[pcprogrammer]

Which Milk-V Duo is that? The ones I have (64MB versions) don't have a display interface.

Ignore that, I got it confused with the Tang Nanos.  (Whenever I do not verify my post after writing but before posting, I keep making these confusions, dammit.  My excitement shows!)

I'll use the GPIO pins, of which there are just enough for my purposes.

Ah that explains my confusion. 

I hope Nominal didn't expect to have video output via the MIPI interface on the 64MB version

Nope.  The display modules I use a 8080-style bus to the GRAM, not synchronized to the display update (but do export the TE pin to indicate when the display refresh is complete).  The second core will compute each output pixel color at update time by combining data from multiple logical planes, only one of which is RGB.

The way I generate the GPIO pin states for that bus-to-GRAM uses yet more lookup tables.  On Cortex-M7 I used the DR_TOGGLE register to allow me to pick any pins in any order within the same bank, but the CV1008B only has a data output, no toggle.  I'll need to investigate which solution (keeping a copy of the value in RAM, or just overwriting the entire bank) yields best results.

A while after making my previous post I realized that you mentioned the GRAM somewhere in this thread, but not the interface you use, which is the 8080 style bus instead of SPI, based on your last post. So my bad on assuming that it was SPI you are using. 

Do these display modules match the Tang Nano 9K connector? Because that one is intended towards RGB interface based panels. There is power provision for the backlight on it, but the current is set a bit low for the 7 inch panels I'm using.

This is why I'm going to make a conversion board for my LCD panels that allow me to connect them to boards that don't have the backlight power too. I'm waiting for parts from Aliexpress to setup a prototype first.

[Nominal Animal]

Tang Nano 9k 40-pin 0.5mm pitch LCD connector pinout has

• Pin 1 = LEDK, pin 2 = LEDA
• Pins 4 and 31 = 3.3V
• Pins 8..12 = Red3 .. Red7
• Pins 15..20 = Green2 .. Green7
• Pins 24..28 = Blue3 .. Blue7
• Pin 30 = Clock
• Pin 32 = HSync
• Pin 33 = VSync
• Pin 34 = Enable
• Pins 37-40 for touchscreen
• Rest are GND

To adjust the backlight peak current, you replace R25 with 0.25/I, where I is the current in amperes.  The default is 13Ω, which sets the current to 19mA.  This shares pins with HDMI, so you cannot use both at the same time.

I do believe BuyDisplay currently offers four IPS panels that are compatible with Tang Nano 40pin 0.5mm pitch FPC connector: 4.3" 480x272 (ER_TFT043A4-3) (15-20mA backlight), 4.3" 800x480 (ER_TFT043A1-7) (35-40mA backlight), 5" 800x480 (ER_TFT050-6) (45-60mA backlight), and 7" 800x480 (ER-TFT070IPS-4) (140-180mA backlight).  The boost LED driver (LP3320) on the Tang Nanos can handle the higher currents if you change the resistor.

Tang Nano 9k also has a small 8-pin 0.5mm pitch connector for SPI LCD modules, with pin 1 to 3.3V via 5.1Ω resistor, pin 2 is GND, pin 3 is RESET, pin 4 is RS (aka C/D), pin 5 is DATA, pin 6 is CLOCK, pin 7 is 3.3V, and pin 8 is CS.  I do believe 0.96" 160x80 (ER-TFT0.96-4), 1.14" 240x135 (ER-TFT1.14-2), and 1.47" 320x172 (ER-TFT1.47A1-1) are compatible with this connector.  I believe one can use the smaller connector at the same time as the other LCD connector or HDMI.

[pcprogrammer]

That is the same as on the Tang Nano 20K, except for the smaller SPI based display connector. It does not have that one.

But what I was wondering about is, if you can connect the 8080 interface display panels you use to the Tang Nano 9K 40 pin connector?

I only have and buy the 50 pin based 7 inch displays because they came up cheaper. I bought the 7 inch 1024*600 you mentioned in the other thread for ~21 euro on Aliexpress to compare it with the 7 inch 1024*600 displays I already have that were a bit cheaper. (~14 euro)

https://nl.aliexpress.com/item/1005008274773124.html
https://nl.aliexpress.com/item/1005005292813240.html

The one from buydisplay seems to be a little bit better, but not by much.

The 40 pin 7 inch one you linked to on buydisplay.com is interesting though, but I already have three 800*480 7 inch displays and 3 1024*600 7 inch displays, so I think that is enough for now. 

Edit: One remark on the Tang Nano 20K 40 pin connector, I found that it connects to the flat cable on both sides, so one can insert it the other way round. Pin one is clearly marked on the board though. Most of these FPC/FCC connectors are one sides.

[Nominal Animal]

But what I was wondering about is, if you can connect the 8080 interface display panels you use to the Tang Nano 9K 40 pin connector?

With suitable a 40-pin to 50-pin 0.5mm pitch FPC adapter, sure, because they also happen to support the RGB+Hsync+Vsync+Clock+DE interface.

Although there are several with compatible pinouts, I'm specifically targeting 2.8" 320×240 (ER-TFT028A2-4) and 3.5" 480×320 (ER-TFT035IPS-6).  There are a few pins (specifically, IMn) that you want to tie on the FPC adapter to either GND or VCC depending on the display, but yes, they are compatible with the Tang Nano 9k, with a mechanical adaptor board.

Moreover, I do believe the Tang Nano 9k could drive them in the GRAM mode also, not just RGB+Hsync+Vsync+Clock+DE mode.  You could even use an 8-bit parallel 8080 bus, repurposing some of the color bits, and make it work at the same time as the HDMI interface.  For 16-bit color at 480×320 70Hz, you then need a ~ 22 MHz parallel bus clock.  ILI4988 can do up to 33 MHz.  320×240 ILI4931 is specced to 15 MHz, but only 11 MHz is really needed; and all the ones I have can sustain at least 18 MHz without any issues at all.  That is for 8-bit parallel bus, mind you; halve the frequency needed if you use a 15/16/18 bit parallel bus.  The write strobe runs at twice that frequency, of course; you need to output a pulse per output word.

As an aside, if you compare that pinout to e.g. 7" 1024x600 (ER-TFT070A2-6) with also a 50-pin 0.5mm pitch FPC, you'll see that while they're not directly compatible, you can definitely do a simple adapter to the 40-pin one as used on the Tang Nanos.  You'll want to tie some pins to VCC or GND depending on the exact display (including L/R and U/D mirroring pins), but no logic or translation is needed.

If I recall correctly, you said you already had some such 40-pin to 50-pin FPC adapter boards designed?  In my opinion, a design that also acts as a carrier for the display module and Tang Nano, with PCB extending beyond the display module with positions for studs and mounting holes to correctly place it with respect to the housing and display hole, would be very useful here.  I've made cardboard stand-ins to determine where to put a slot for the FPC and where to put the connector.  (You'll want a full flat ground plane without any components facing the display module, and use 3M double-sided foam tape strips (the 2-3mm thick kind, and just 4-6mm wide "strips", not a full plane) to adhesive the display to the carrier PCB.)

Edit: One remark on the Tang Nano 20K 40 pin connector, I found that it connects to the flat cable on both sides, so one can insert it the other way round. Pin one is clearly marked on the board though. Most of these FPC/FCC connectors are one sides.

While the pinout is common, not all display modules FPC cables expose the pins on the same side, I believe.  I got dual-sided 40-pin 0.5mm pitch connectors for that exact reason.

[pcprogrammer]

With suitable a 40-pin to 50-pin 0.5mm pitch FPC adapter, sure, because they also happen to support the RGB+Hsync+Vsync+Clock+DE interface.

Although there are several with compatible pinouts, I'm specifically targeting 2.8" 320×240 (ER-TFT028A2-4) and 3.5" 480×320 (ER-TFT035IPS-6).  There are a few pins (specifically, IMn) that you want to tie on the FPC adapter to either GND or VCC depending on the display, but yes, they are compatible with the Tang Nano 9k, with a mechanical adaptor board.

Ok, so you still need an adapter board to connect the displays you are targeting to the 9K. That is what I thought.

Moreover, I do believe the Tang Nano 9k could drive them in the GRAM mode also, not just RGB+Hsync+Vsync+Clock+DE mode.  You could even use an 8-bit parallel 8080 bus, repurposing some of the color bits, and make it work at the same time as the HDMI interface.  For 16-bit color at 480×320 70Hz, you then need a ~ 22 MHz parallel bus clock.  ILI4988 can do up to 33 MHz.  320×240 ILI4931 is specced to 15 MHz, but only 11 MHz is really needed; and all the ones I have can sustain at least 18 MHz without any issues at all.  That is for 8-bit parallel bus, mind you; halve the frequency needed if you use a 15/16/18 bit parallel bus.  The write strobe runs at twice that frequency, of course; you need to output a pulse per output word.

With the FPGA it is simple enough to make up what ever interface you need. The extra external hardware takes a bit of fiddling.

As an aside, if you compare that pinout to e.g. 7" 1024x600 (ER-TFT070A2-6) with also a 50-pin 0.5mm pitch FPC, you'll see that while they're not directly compatible, you can definitely do a simple adapter to the 40-pin one as used on the Tang Nanos.  You'll want to tie some pins to VCC or GND depending on the exact display (including L/R and U/D mirroring pins), but no logic or translation is needed.

No logic, but they do need more voltages to drive the panel, so a boost converter has to be added to make these.

If I recall correctly, you said you already had some such 40-pin to 50-pin FPC adapter boards designed?  In my opinion, a design that also acts as a carrier for the display module and Tang Nano, with PCB extending beyond the display module with positions for studs and mounting holes to correctly place it with respect to the housing and display hole, would be very useful here.  I've made cardboard stand-ins to determine where to put a slot for the FPC and where to put the connector.  (You'll want a full flat ground plane without any components facing the display module, and use 3M double-sided foam tape strips (the 2-3mm thick kind, and just 4-6mm wide "strips", not a full plane) to adhesive the display to the carrier PCB.)

I made a prototype for it. I still have to design an actual board for it. Ordered parts to do some testing for a better backlight drive and control. Have not thought about the mechanical aspects of the board yet, so appreciate your input.

See https://www.eevblog.com/forum/projects/please-recommend-a-vga-to-parallel-lcd-board-or-ic/msg5746485/#msg5746485 for info on my proto board.

Edit: One remark on the Tang Nano 20K 40 pin connector, I found that it connects to the flat cable on both sides, so one can insert it the other way round. Pin one is clearly marked on the board though. Most of these FPC/FCC connectors are one sides.

While the pinout is common, not all display modules FPC cables expose the pins on the same side, I believe.  I got dual-sided 40-pin 0.5mm pitch connectors for that exact reason.

That I have not encountered yet.

[Nominal Animal]

No logic, but they do need more voltages to drive the panel, so a boost converter has to be added to make these.

VCOM=3.0V..3.5V, DVDD=3.0V..3.6V, AVDD=9.4V..9.8V, VGH=17V..19V, VGL=-6.6V..-5.4V, so you're referring to the 9.6VDC AVDD, 18VDC VGH, and -6VDC VGL rails.  Yes, the larger panels need these because the controller chip on the FPC cannot do these internally, unlike for the smaller TFTs.  I forgot about that because I don't normally use these larger ones.  As I understand it, these rails don't draw much current at all, and is generated using charge pumps for the smaller TFTs.

I'm a total newbie when it comes to implementing DC-DC converters; I follow datasheets and what TI Webench suggests, followed by additional simulation if possible.  I've briefly glanced at the 18 or so dedicated ICs for this Mouser has in stock.  Because mine are basically always powered from USB or from 5VDC supply, I'd need a boost to 9.6V, 18V, and -6V, from a +5V single supply; TI TPS65145 seems an obvious candidate.  Any other suggestions you could share on this front?

Ordered parts to do some testing for a better backlight drive and control.

Yeah; the smaller modules have the LEDs in parallel, so the forward voltage is in the 3.0V - 3.3V range, with currents in the 80mA – 120mA range.  Since I absolutely detest any kind of flicker and backlight imbalance, I've looked a lot mixing current-controlled and very high frequency (ultrasonic, 30 kHz+) PWM.  With the LEDs in series in the 9V-20V range, more interesting high-frequency (1 MHz+) boost topologies come into play.  Even though it affects the color balance somewhat at lower currents, I must say I like the current control most.

Edit: One remark on the Tang Nano 20K 40 pin connector, I found that it connects to the flat cable on both sides, so one can insert it the other way round. Pin one is clearly marked on the board though. Most of these FPC/FCC connectors are one sides.

While the pinout is common, not all display modules FPC cables expose the pins on the same side, I believe.  I got dual-sided 40-pin 0.5mm pitch connectors for that exact reason.

That I have not encountered yet.

It's more common in the fewer-pin connector variety, where some FPCs are intended to be soldered directly to a PCB, whereas connector-type often has the pins on the "upper" side relative to the PCB in the intended configuration.

I do need to resort to cardboard-aided-design and strips of paper with pin 1 marked to get the placement right; and remember how "deep" into the connector the FPC/FFC seats in.  Papercraft for the win!  Even though this suggested untested adapter I created for some thread here, and it's as simple as an adapter can be, I'm 100% sure the FFC positioning is far from optimal.  (Ten points if you can tell why one is at 90° angle to the other.)  I even had to draw the cabling idea on the silkscreen, just to remember it myself how I suggested it be used.  EasyEDA is an excellent tool for this kind of suggestions –– which I always put in Public Domain ––, as anyone can examine the schematic and the PCB files directly in their browser with just one click.

[pcprogrammer]

I'm a total newbie when it comes to implementing DC-DC converters; I follow datasheets and what TI Webench suggests, followed by additional simulation if possible.  I've briefly glanced at the 18 or so dedicated ICs for this Mouser has in stock.  Because mine are basically always powered from USB or from 5VDC supply, I'd need a boost to 9.6V, 18V, and -6V, from a +5V single supply; TI TPS65145 seems an obvious candidate.  Any other suggestions you could share on this front?

I'm no expert myself, but I'm going to do it with the TPS61040. I "stole" this design from the FNIRSI-1013D, where a plus and minus 15V is created with the boost converter setup, and zenerdiodes are used to make the other voltages. https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/blob/main/Schematics/1013D/Scope_Power_Supply.png

On my prototype I used a module with a XL6007 boost converter that gives me the +/-15V. The other voltages are made with the zenerdiodes and works very well.

Yeah; the smaller modules have the LEDs in parallel, so the forward voltage is in the 3.0V - 3.3V range, with currents in the 80mA – 120mA range.  Since I absolutely detest any kind of flicker and backlight imbalance, I've looked a lot mixing current-controlled and very high frequency (ultrasonic, 30 kHz+) PWM.  With the LEDs in series in the 9V-20V range, more interesting high-frequency (1 MHz+) boost topologies come into play.  Even though it affects the color balance somewhat at lower currents, I must say I like the current control most.

I'm not to sensitive to flicker, but the low frequency noise is what bothers me. The FNIRSI-1013D uses ~800Hz PWM to dim the display, and that is very audible, so when I use that scope the brightness is on full.

The PT4103 datasheet gives other options that indeed control the current without turning the boost converter on and off. That is also something I'm going to test first before making a board.

I do need to resort to cardboard-aided-design and strips of paper with pin 1 marked to get the placement right; and remember how "deep" into the connector the FPC/FFC seats in.  Papercraft for the win!  Even though this suggested untested adapter I created for some thread here, and it's as simple as an adapter can be, I'm 100% sure the FFC positioning is far from optimal.  (Ten points if you can tell why one is at 90° angle to the other.)  I even had to draw the cabling idea on the silkscreen, just to remember it myself how I suggested it be used.  EasyEDA is an excellent tool for this kind of suggestions –– which I always put in Public Domain ––, as anyone can examine the schematic and the PCB files directly in their browser with just one click.

I work rather similar. I guess that your reason for the 90 degree angle is that it is easier to get the cable in. To have it facing in the opposite direction so that the cable enters at one end and goes out at the other end would have needed you to cross all the traces on the board to get it routed. Having them inline with both cables in the same direction would eliminate this crossing, but would make it harder to insert the second cable.

Another way to cope with this is to make use of the different type of cables or connectors. For the cables there are A-A and A-B types or Forward and Reverse direction. For the connectors there is top or bottom also referred to as forward or reverse, but also both sides. In searching for these it is not always clear what type it is, at least on Aliexpress.

https://www.aliexpress.com/item/1005006274520167.html

It does make designing complicated though. 

Edit: I looked at your design again and noticed that the cables are going in on at one and and the other on the other end, so my guess is wrong. Still think it has to do something with the orientation of the pinning and the simplified routing.

[Nominal Animal]

Edit: I looked at your design again and noticed that the cables are going in on at one and and the other on the other end, so my guess is wrong. Still think it has to do something with the orientation of the pinning and the simplified routing.

The pin order is reversed, but both cables need pin 1 to be on the same side for the standard display orientation to work; and this board will be sandwiched between the display and the original board, so the stacking order and directions of the two cables is important.  IIRC, I made a cardboard model with paper strips acting like FFCs, and then worked out a way to make standard length FFCs work with the FPC on this particular display.

The one trick is to have just the right amount of extra length when going through slots or bends, so the FFC fits nicely without binding or having annoying floppy loops of it where you don't need it.  Papercraft CAD makes that easy.

[RoGeorge]

What is GRAM?

Asking out of curiosity.  Never met the term before.  DuckDuckGo doesn't know it either.  By the context it seems to be video RAM, though, I didn't read the entire thread.  Is GRAM the same as VRAM?

[Nominal Animal]

Asking out of curiosity.  Never met the term before.  DuckDuckGo doesn't know it either.  By the context it seems to be video RAM, though, I didn't read the entire thread.  Is GRAM the same as VRAM?

Yes.  It is the term the display controllers like ILI9341 use for the (typically) 18-bit graphics buffer they contain.  It does not really act like "normal" RAM, in the sense that if you use narrower writes (say, 15-bit RGB555 or 16-bit RGB565) the data is expanded to 18-bit on write by duplicating the high bits.  Also, reads from this memory are exceedingly slow compared to writes.  For ILI9341 (320×240, exactly 240×320×18 bits), write strobe can be repeated every 66ns (up to 15 MHz), but read cycles are limited to 450ns (2.2 MHz or less).  Bulk writes are not limited to a sequential block of GRAM either; you can set up a 2D rectangular window and update direction within that window your writes will modify.  (Unfortunately, no blitting or skipping of pixels, so no transparency support.)

[cunningfellow]

I don't think it is the same as VRAM (dual port RAM with the 2nd port being serial access only) as VRAM was known in the 80s and 90s.

These days the young kids call any RAM used for video VRAM.

Which is how I think the term GRAM is being used.  Graphics RAM.  I don't think there is anything fancy about it.