Port manipulation – LCD 8bit parallel

wizarcl Thu Aug 06, 2015 11:51 pm

Hi everyone.
I’m trying to port Adafruit_TFTLCD library (for 8bit parallel LCD) and inside in library, control lines is controlled by macros, using port manipulation, but STM32 has a different method to make this. Using AVR, library make control using DDRA and PORTA, for example, to control port direction and values. How can I make this manipulations? Using GPIOA_BASE.CRL, GPIOA_BASE.CRH, GPIOA_BASE.IDR and GPIOA_BASE.ODR?

Follow a piece of code in pin_magic.h:

#define write8inline(d) { \ PORTD = (PORTD & B00000011) | ((d) & B11111100); \ PORTB = (PORTB & B11111100) | ((d) & B00000011); \ WR_STROBE; } #define read8inline(result) { \ RD_ACTIVE; \ DELAY7; \ result = (PIND & B11111100) | (PINB & B00000011); \ RD_IDLE; } #define setWriteDirInline() { DDRD |= B11111100; DDRB |= B00000011; } #define setReadDirInline() { DDRD &= ~B11111100; DDRB &= ~B00000011; }

Replies

DavidJ Mon Jun 20, 2016 2:29 pm

I am looking for an ADAfruit libary for the STM32F108 to interface an 8bit ILI9325.
This code looks promising but I get the error: stm32f10x_gpio.h: No such file or directory
I tried copying that file everywhere, but no luck.
Help would be very much appreciated.

zmemw16 Mon Jun 20, 2016 7:55 pm

trying a search for stm32f108 on stm’s site, no such thing

simple google for ili9325 gives 2nd link as
https://www.adafruit.com/product/335
and the 3rd link as
http://tronixstuff.com/2013/04/26/tutor … d-modules/

stephen

martinayotte Mon Jun 20, 2016 8:48 pm

The F108 is actually a F103 with the mouth closed … :lol:

RogerClark Mon Jun 20, 2016 9:54 pm

Googling for that file, shows that its part of STMs old CMSIS.

The libmaple core does not use the CMSIS because of historical licensing issues.

You will need to comment out that include, and then see what functions are called, and them change the library to use the libmaple equivalent functions, or possibly manipulate the hardware directly.

zmemw16 Mon Jun 20, 2016 11:59 pm

martinayotte wrote:The F108 is actually a F103 with the mouth closed … :lol:

RogerClark Tue Jun 21, 2016 12:20 am

I’m not sure if this helps (I’d need to test it)

But I’ve been working on the HAL as a library.

I’m not sure if one library can include another library, but this may be a way to port some code based on the CMSIS albeit as long as that code is compatible with the CMSIS that is generated by the STM Cube

mrburnette Tue Jun 21, 2016 12:18 pm

RogerClark wrote:
<…>
I’m not sure if one library can include another library<…>

RogerClark Tue Jun 21, 2016 10:47 pm

Thanks Ray.

The HAl library, isnt really a library, its just a way to get the IDE to compile and link the STM HAL files, and read in all the headers, so that the HAL functions can be called inside the sketch.

The HAL is written in C, and seems to just be a load of disparate files, each with a grouped set of functions in them.

But its a lot of files, I have not counted them, but it looks like 100’ish, and takes up several megabytes.

Anyway, its rather experimental at the moment, but may be useful to some people.

mrburnette Wed Jun 22, 2016 12:47 pm

RogerClark wrote:
<…>
The HAl library, isnt really a library, its just a way to get the IDE to compile and link the STM HAL files, and read in all the headers, so that the HAL functions can be called inside the sketch.
<…>
But its a lot of files, I have not counted them, but it looks like 100’ish, and takes up several megabytes.
<….

RogerClark Wed Jun 22, 2016 9:41 pm

Hi Ray,

This confusion is my fault.

I am playing fast and loose with the Arduino Library paradigm with this.

I bent the rules a bit with the Libraries system, in the past, by making an empty library, just to put our examples in; so they can be acccessed via the menu system.

But in this case, the header does actually include some files, and the IDE does have to compile a whole loadmof files, but none of them, AFIK, are classes.

I may even remove the dummy HAL class I made, as it may not be needed at all, depending on whether any initialisation code needed to be run – and at the moment, it looks like running the default HAL_init() function screws things up, as it either messes up the clock PLLs or possibly does something strange to systick, ( I have not had time to investigate precislely what its affecting, so I am not calling HAL_init() from the library at the moment)

iwalpola Sat Jul 02, 2016 3:12 pm

Working library

With your help of martinayotte, werefcat and diger67’s posts in http://www.stm32duino.com/viewtopic.php?f=9&t=474 I managed to port the SPI version of ILI9341 library to work with 8 bit parallel.

viewtopic.php?f=44&t=637&p=15438#p15438

github:
https://github.com/iwalpola/Adafruit_ILI9341_8bit_STM/
demo:
https://www.youtube.com/watch?v=MAkMaZyZMWM

RogerClark Sat Jul 02, 2016 9:33 pm

Do you have the milliseconds timing debug output from the adafruit graphics demo, in your youtube video, so we can compare the speed with SPI?

martinayotte Sun Jul 03, 2016 1:55 am

Great work, @iwalpola !

In my case with Netduino2Plus pinouts as uint8_t DPINS[] = {PC7, PC6, PA3, PA2, PB12, PB8, PB9, PA1, PA0, PA6};, I don’t think I could get much speed optimisation doing direct register access …

iwalpola Sun Jul 03, 2016 3:25 am

RogerClark wrote:Do you have the milliseconds timing debug output from the adafruit graphics demo, in your youtube video, so we can compare the speed with SPI?

mrburnette Sun Jul 03, 2016 2:39 pm

iwalpola wrote:
I’m also curious to know the performance as compared to SPI.

iwalpola Sun Jul 03, 2016 5:16 pm

New benchmark after replacing regs->ODR with regs->BSRR and regs->BRR

Benchmark Time (microseconds) Screen fill 1478774 Text 43997 Lines 376454 Horiz/Vert Lines 101883 Rectangles (outline) 65100 Rectangles (filled) 3070377 Circles (filled) 419900 Circles (outline) 285285 Triangles (outline) 90139 Triangles (filled) 713698 Rounded rects (outline) 131807 Rounded rects (filled) 3324904 Done!

ahull Sun Jul 03, 2016 7:54 pm

iwalpola wrote:New benchmark after replacing regs->ODR with regs->BSRR and regs->BRR

martinayotte Sun Jul 03, 2016 8:10 pm

Andy, even if LCD is parallel, if code has to assign GPIOs one by one, especially in the case of a shield with D2-D9, where those GPIOs are not consecutive (especially on Netduino2Plus), I/O performance is hard to achieve.

iwalpola Sun Jul 03, 2016 8:36 pm

@Andy, Kurt’s library seems quite fast in some operations, and I’m curious to see why. I’ll git diff and report back.
@Martin Perhaps it comes down to the GFX library functions?
Very curious indeed

ahull Sun Jul 03, 2016 8:51 pm

martinayotte wrote:Andy, even if LCD is parallel, if code has to assign GPIOs one by one, especially in the case of a shield with D2-D9, where those GPIOs are not consecutive (especially on Netduino2Plus), I/O performance is hard to achieve.