stm32 and 8bit parallel bus

[exe]

Hi!

I want to connect my lcd module to an stm32 controller via, say, an 8bit bus. How I see it in theory: I choose, say, port A and configure first 8 pins as output. Then I can write to all 8 pins with just single instruction (write to the corresponding register).

There are two problems:

1) Even devices with 48 pins don't have enough pins from one port: say, STM32F373 in tqfp48 has PA0-PA6 outputs, but not PA7. So, perhaps, I need to use one pin from another ports and do manual bit shifting and masking?

2) Often pins from the same port are scattered on different sides of IC making routing complicated.

What am I doing wrong? Is it really that cumbersome to make a parallel bus on stm32 or I missed something?

PS In reality I want an 16 bit port to drive a 480x320 LCD, I used an 8bit example for clarity.

PPS I have development board with an LCD based on stm32f429. AFAIK, they use 3x6bit outputs to make a 16bit bus.

[Berni]

Yes the pinouts of the STM32 chips are indeed horrible.

It can get better with high pin count chips, but you still sometimes get some peripherals with many pins just scattered all over.

EDIT: Oh and for what you are doing you might want a STM32 with a display controller or if its a memory bus based display use the external memory controller in the STM32 to get wide buses without extra CPU overhead.

[exe]

Thanks, Berni.

Perhaps, I need to invest some time into STM32 with a display controller. But I already have many stm32 devices in my lab, which I'd like to utilize... Also not sure how to use TFT-LCD controller.  I wanted to use either arduino port, or ChibiOS, both seems don't have support for any TFT-LCD drivers... CubeMX looks like a mess to me...

[Berni]

Well you can still write your own driver for those. To get good performance on such a high resolution display you will most likely need to delve into the details of how this works rather than just blindly using a Arduino library.

And CubeMX is actually pretty good once you figure it out, its just the code it generates and the HAL drivers it uses are quite a mess.

[newbrain]

PS In reality I want an 16 bit port to drive a 480x320 LCD, I used an 8bit example for clarity.
PPS I have development board with an LCD based on stm32f429. AFAIK, they use 3x6bit outputs to make a 16bit bus.

What kind of display is that?

I have used a 480x320 with an iLI9481 controller, and managed to get about 33 mega pixel per second writing random sized rectangles (crappy video link, on the right px/s, on the left rect/s).
That was on a F4 Discovery (STM32F407), and using the FSMC configured for a 16 bit static memory with only one address line: the display was accessed through two pointers, one for commands and one for data:

Code: [Select]

void FillRect( uint16_t x1, uint16_t y1, uint16_t x2, uint16_t y2 )
{
  if( x1 > x2 ) SWAP( x1, x2 );
  if( y1 > y2 ) SWAP( y1, y2 );
  uint32_t area = (x2 - x1 + 1)*(y2 - y1 + 1);
  WindowLCD( x1, y1, x2, y2 );
  *pCmd = ILI_RAMWRITE;
  for( uint32_t i = 0; i < area; i++ ) *pData = lcd.colFG;
}


If the STM32F429 board is a Discovery too, it's driving the (iLI9341) display through the integrated TFT controller  (a raster interface) and uses 18bit (6x3) colour, SPI is also possible.

So, your options depend very much on the display controller and whether it has been hardwired for a specific bus, and on the availability of the FSMC and LTDC peripherals on your STM32 of choice.

If you need to resort to GPIO bit wrangling, performance will probably be worse and you'll have to fight the odd pinout...

And CubeMX is actually pretty good once you figure it out, its just the code it generates and the HAL drivers it uses are quite a mess.

Yes, they are, but I found them not worse and actually less bugged than other vendors libs, e.g. TI and NXP.

[exe]

I have three displays based on HX8357B and HX8357C (all 480x320). Are they any good?

[newbrain]

I have three displays based on HX8357B and HX8357C (all 480x320). Are they any good?

To eat? Definitely not!

I imagine you've got them on eBay/AliExpress?
Maybe something like this one, but with 8357 controllers?

These display are (AFAIK, mine was) hard-wired for 16bit parallel bus operation, and the HX8357x controllers are very, very similar to the ILI9841, so you should have no problems in driving them from the FSMC, if you have it available.

As for the speed, sorry  : the video I linked is for a different display, on a different board!
On the 9841 display I only managed to get about 7Mpx/s 

BTW: should this be moved to MCU/FPGA sub-forum?

[exe]

Yep, the display you showed looks quite similar. I also have one slightly bigger and with a touch screen.

Okay, let me ask straight . Is there an easy way to marry an lcd with an inexpensive stm32 controller (speed is not important, I'm doing UI for a power supply)? By saying easy I mean firmware is already written by someone. So far I can't really find anything related. I was only able to find https://github.com/Bodmer/TFT_HX8357 which was written for arduino.

Concerning FSMC, I wasn't able to find many MCUs supporting it. All I found were expensive ICs (e.g. stm32L152 series) in big packages. Looks complete overkill to my task (although time is more expensive than almost any IC).

As of now the simplest option I see is just to use an arduino-supported MCU.

[newbrain]

Yes, FSMC is only available in high pin count packages (>=90/100), as one could reasonably expect.

And no, I don't have any ready made code to point out...apart from the Arduino stuff you've already found.

But, if speed is not paramount, the marriage is not that hard, even if you use GPIOs on a 48 pin MCU: just some bit shuffling, assuming you have enough IOs left for your purposes.
One could even think to hang a couple of 74HC595 from SPI for D0-D15 and use GPIO for the control signals: no bit shuffling here!

Regardless of the interface, writing a command or data on the bus can be isolated in a short function (or even static inline/macro); the hardest thing is having the right initialization and command sequences for the needed operations, but you can derive those from e.g. Bodmer's library and the datasheet.