Driving parallel-interfaced LCD display via DMA - approach?

[wb0gaz]

I wish to drive (write output data streams) to a parallel-interfaced LCD display. There would be 8-32 bits of parallel data (tied to MCU GPIO output lines) and a strobe or clock line (also tied to MCU GPIO output line) to cause those bits to be transferred to the display. Whether there is a "ready" indication (from display to MCU) isnt known yet, somewhat dependent on whether there would be such a requirement, and how the MCU could go about honoring the requirement.

I'm looking for guidance on whether I can do the data transfer via DMA, so that the MCU doesn't need to (under programmed operation) write individual bytes/words to GPIO and toggle the clock/strobe line for each (8-16-32 bit) word transferred. Ideally, I'd like to set a start address for the source data (which would be in ram or flash on the MCU) and have the data transfer cause an interrupt only when complete (rather than for each byte/word transferred.)

My question at this point isn't specific to a given target device/part number, however, if there are target device types or capabilities that are more (or less) appropriate for this capability, I'd like to know what to look for.

I've seen mention of "Fast toggle" (example, cited once in RM0091), but no further explanation of what the term applies to.

Thanks for any advice or pointers, and happy to provide any clarifications that could help narrow the request.

[Tesla DeLorean]

GPIO banks are only 16-bit wide.

Not really a clean ready, request type input for the DMA

Using FMC might be more practical, especially for 32-bit

The FMC NAND does have the potential for a READY signal.

Perhaps gate via a CPLD

[wb0gaz]

16-bits is no problem (the display I have in mind can do (1..4)*8 width.)

I had in mind something like "pulse port x.y when writing do GPIO z, but I hadn't seen anything like that in the GPIO peripheral definition, nor a way of terminating a DMA transfer in a GPIO port, so I was checking here to see if I had missed something fundamental.

I presume FMC would constrain to STM32H7 family?

I was hoping to find some path forward without adding any external logic.

If this doesn't work out easily enough, I can wrap the display in something to mimic SPI (yes, some external logic).

[Tesla DeLorean]

Depending on the system you'd need a DMA that can do Mem-to-Mem

You have the pattern buffer in memory,and move to &GPIOA->ODR (16-bit), or &GPIOA->BSRR (32-bit wide, but sub-set of 16-bit changes)

[wb0gaz]

I would have the pattern buffer in memory.

Your idea of using memory-to-memory transfer is really helpful idea and I think solves part of the problem (getting bulk data transferred to the GPIO pins under DMA) - I hadn't thought about using memory-to-memory targeting the GPIO ODR. That's the first forward progress on this problem!

Any thought on how I could effect a strobe/pulse on a GPIO output after each such transfer? Could I devise a second DMA transfer from two adjacent addresses ("copy-from" containing a 0 and a 1) to another GPIO pin ("copy-to"), and make that repeat after each of the main data transfers above that you describe? It seems like timers can be used to trigger DMA transfers, so could I arrange a pair of timers to trigger alternating (data then strobe) transfers like this, and continue repeating that until an interrupt when copy is complete?

[Tesla DeLorean]

Or different channels on the same TIM

If using less than 16-bits, you can use other bits

The FMC/FSMC are present on many of the STM32 (F1,F2,F4,F7,H7.for sure)

[GLASS]

Hi. You need to consider max Frequency of display signals. May be it will exclude mem to mem dma targeting gpio​...

If fmc timing​ are display compatible it will be the more efficient.

Otherwise i'm agree with tesla delorean that using timer dma from ram to gpio register​s can do the job...

[wb0gaz]

Given the suggestions so far, I'm curious about possibility to use a timer as the generator of the strobe signal and a trigger for the next DMA memory-to-memory (memory-to-memory-mapped-GPIO) transfer, which would let me fix the repetition rate (as GLASS points out, a simple DMA memory-to-memory transfer would certainly go by too quickly for the display which would have limitations in this respect.)

I have used timers to generate PWM before, but that is open-ended pulse train. Can I configure a (any type of) timer to generate a finite number of pulses (at some given repetition rate, so that I can accommodate the data intake limits of the display)? I'm envisioning something like a count-down or count-up that does not repeat, is sourced by system clock through a prescaler to set repetition rate, and output the pulse to a pin on the MCU (like PWM.) If I can generate a finite-length (number of transfers), finite-rate (transfer interval) pulse train from a timer, then could I use that pulse train (either internally linked or via connection between two MCU pins) as a signal to tell the DMA to proceed with the next transfer (of 8- or 16-bits) that would be required to complete the data transfer, following TeslaDelorean's notion of memory-to-GPIO ODR transfer?

To make this a (slightly more) concrete example, suppose I want to transfer 480 16-bit words (one row of the LCD display). After telling the LCD panel to expect this transfer, configure a timer to emit 480 pulses to an MCU pin and configure the DMA controller to transfer (upon a trigger) 16-bit value from the source data memory (autoincrementing one word for each such transfer) to the GPIO ODR register (not auto-incrementing). Once started, the timer would assert the pulse output (thereby providing the trailing edge of the data transfer strobe - there would be race and phase conditions to address), and that would tell the DMA controller to transfer the next word to GPIO. At some subsequent point, the timer would de-assert the pulse output (providing the leading edge of the data transfer strobe, which the LCD panel would use to accept the 16 bits on the GPIO pins), and then the process would fall dormant until the next timer period. The process would be complete (generating an interrupt to the MCU) after 480 such transfers.

I realize I could (should) research the various device and register properties, however, I would prefer if possible to get some guidance as to practicality first, as I am still at (MCU) device selection phase (which is further complicated by availability issues, but I'm flexible) so there are many unknowns, and having a going-in concept would greatly reduce selection risk and time expenditure.

Thanks again!

[waclawek.jan]

> I realize I could (should) research the various device and register properties

Yes you should. Take a Nucleo and perform dozens of simple experiments. Come back with concrete questions.

> Can I configure a (any type of) timer to generate a finite number of pulses

Some timers (usually the Advanced) have Repetition counter register, TIMx_RCR, which together with the One-Pulse Mode does what you describe.

JW

[wb0gaz]

Thanks for your input - my goal has to get help narrowing and characterizing my question - in this case I believe my line of questioning is more efficient than casting around somewhat in the dark (which I have done extensively, and have discovery and nucleo modules here for that purpose, but this requirement didn't provide me with any clear getting-started direction, which has thankfully been made available here.

In any event, your mention of _RCR register is helpful, however, I still need to understand whether a DMA could be triggered from this sort of event.

Dave

[wb0gaz]

Returning to this topic after a long time as implementation is now necessary - I did a search yesterday on the terms "stm32 parallel display gpio". One of the initial results was this document (dated January 2016) from ST Microsystems:

AN4666
Application note
Parallel synchronous transmission using GPIO and DMA

This covers precisely the subject of the original post, and provides a roadmap to implementing the needed solution without FSMC (as I'm using 64-pin device, FSMC/FMC - which would be preferable - is not available.)

Thank you for the informative contributions to my then-speculative query from 2022, which yielded the two candidate directions (FSMC and Timer+DMA).

I wish there was an index (web page, listing, PDF, etc.) of ST Microsystems app notes covering STM32 - evidently there is considerable resource there!

 

 

[waclawek.jan]

> I wish there was an index (web page, listing, PDF, etc.) of ST Microsystems app notes covering STM32 -

https://www.st.com/en/microcontrollers-microprocessors/stm32-high-performance-mcus/documentation.html for 'F2/'F4/'F7/'H7; for other super-families, "Documentation" tab for that super-family.

> evidently there is considerable resource there!

Unfortunately, ST decided not to invest into decent appnotes anymore. Lately, more info is posted here as articles by ST staff; but since migration to Khoros, they are not easily filtered.

JW